Evolutionary Design

Description

http://www.sdmagazine.com/documents/s=7928/sdmsdw3d/sdmsdw3d.html

Here are some evolutionary design practices, as described by JoshuaKerievsky and RussRufer?:

• Rapid Return on Investment
• Risk Reduction
• Backtracking
• Selective Automation
• Team Intelligence
• Walkthrough
• Spanning System
• Small Iterations
• Multiplicity & Selection
• Dead Reckoning

We've included Evolutionary Design as one of the core practices of Industrial XP, and have taught several tutorials on the topic. Unfortunately, we haven't written an article just yet.. so, I'll try to summarize it for you..

First, Test-Driven Development (TDD) has a flaw. It is directed toward making you efficient with your time and write code that does what you want it to do. However, if you are familiar with the works of Tom DeMarco? (Slack), you might have come across the phrase - "Efficiency is the enemy of effectiveness". How do you ensure that the code you create with TDD is effective? You could be efficiently building software that has no bugs, but it does not really give the biggest bang for the buck.

Second, the basics of risk-management direct you to identify the critical path of your system. What is the part of the system which has to be built, without which, the system would not function and be considered a failure? We've seen teams spend so much time on building parts out of their own fancy and paying a huge price later.

To account for these issues, we practice Story Test-Driven Development (which I can describe if there is interest) and Evolutionary Design.

Evolutionary Design involves identifying a Horizontal_Thin_Slice of the system. Think of it in terms of embryonic development. In the womb, a foetus initially develops the most important organs very early on - the heart, kidney, .. Thereafter, as foetus develops, these organs get stronger while also getting other new "features". You want to identify the most critical parts of your system, and implement them in iterations starting with the most rudimentary version. Starting with the first iteration, you want to have an end-to-end system that delivers business value.

The challenge is in identifying the most rudimentary version that delivers real business value. e.g. on a project I was coaching, the task was to do some number-crunching on raw data, and put it into a data warehouse. This involved getting the raw data from the mainframe, partially processing it using java code, and doing some more processing using data tools and finally loading it. An end-to-end system involved doing just enough work to load one simple table, where the data would have to pass through the major components - mainframe, java and the data tool.

SomikRaha

Rapid Return on Investment - "Develop only what needs to be done at the moment, leaving the rest as stubs to be filled in later."

Risk Reduction - "Striving for design simplicity is another useful factor for reducing risk."

Backtracking - "Stepping back reveals another, simpler solution to the problem. Backtracking not only helps you to consider other alternatives, it allows you to rewrite, aggressively refactor and prune any dead code."

Selective Automation - "quantity bows to quality: It's not about writing tests; it's about writing good tests"

Team Intelligence - "Developers should devote maximum attention to improving the code."

Walkthrough - "Studying, living and breathing code is at the heart of evolutionary design"

Spanning System - "Evolving the code from a rudimentary system that, though primitive, provides end-to-end functionality. This simple working application is a thin, horizontal slice of the project that offers insight into both essential and unnecessary features.

Small Iterations - To implement a hotel reservation system, you might first implement a program that reserves just one room before developing the whole system. These small iterations can be viewed as embryonic versions of the system, and can be taken to the customer for feedback...this is the antithesis of RAD—instead of throwing your code away, you evolve it.

Multiplicity & Selection - Consider a multiplicity of design and selection, like the photographer who takes 10 rolls of film to find the perfect shot.

Dead Reckoning - Navigating without explicit instructions by heading in roughly the right direction and using feedback to make adjustments and to motivate backtracking.

KeithRay?

XP's style of design has been called incremental, iterative, evolutionary, and (as in the recent HackNot? flap) emergent design. I'm just as guilty--I've got a paper with an unwieldy title that includes the term "evolutionary design."

I think these names have it all wrong. Incremental implies we add on to the design bit by bit. Iterative implies that we go over it over and over. Evolutionary and emergent imply that the design just magically appears.

None of these correctly describe what we actually do. XP design, as exemplified by Kent's "write test, write code, refactor" mantra, is not layering, rework, or magic. It's a continual evaluation and improvement of the design of our program. It appears as small renames and big restructurings. We don't just throw these things in: we think about them! Big improvements can percolate for weeks before we act. When we do this well -- and it just takes time and care, not super-brains -- our code becomes cheaper to maintain over time.

"Our code becomes cheaper to maintain over time." That's an amazing statement. Can any other approach claim that? Maintenance costs usually climb to the point that the software is scrapped and re-written.

Something this amazing doesn't deserve to be saddled with a lousy name. We're designing continuously: let's say it.

JimShore?

• being storytest-driven, unittest-driven and domain-driven
• refactoring and integrating continuously

Evolutionary design goes hand-in-hand with Evolutionary Delivery (a Tom Gilb term), which we call Frequent Releases. Quickly evolve something useful and deliver it. Repeat.

JoshuaKerievsky

I've always liked "evolutionary," but I think I see why the term doesn't communicate to the business owners that we talk daily.

I would have to disagree with your suggestion that "evolutionary" suggests "magical." And it's not about the controversy/baggage that the term carries, either. I know plenty of business people who use the term while talking about business. There's often lots of words like "killing," "squashing," "consuming"...

I think "evolutionary" describes what we do pretty well, but I think most people--even the highly educated, intelligent, sane customers--misinterpret the term. "Evolutionary design" does not imply that the design is going to get better over time. If it did, then the customer would be justified in asking "So why not get it right the first time?"

Sure, if we tackle a legacy project, buttress it with tests, and refactor mercilessly, the design will indeed improve. Why are we doing that "if it ain't broke..."? Well, it IS broke. In fact, it's stalled on the highway. We have to fix what ain't broke before (and after) we add a feature.

But what about that greenfield XP project? What's happening there? ("Something wonderful!" - 2010)

There's often an assumption that biological evolution is about improvement. This is an anthropocentric fallacy: That we, as intelligent homo sapiens, are at the very tip-top of the evolutionary tree, and that all others are somehow inferior. Yet many of those forks along the evolutionary road were not dead-ends. Every creature alive today is at the tip of its branch (I'm hopping from metaphor to metaphor, I know), and continues to evolve. Evolution is about adapting to environmental pressures, and filling niches, not competing for and winning some godlike goal of perfection.

My point is this: We strive to keep the design of the code nearly perfect for what it needs to do today. As new requirements come in (dynamically, unpredictably, and prioritized based on the owners' current evaluation of ROI), we must adapt. The team reacts (red), adapts (green), and settles into a new design (refactor).

Aside: In evolutionary terms, "refactoring debt" is like cancer: Diagnose early and often, and you'll be okay. Fight it off like a tiger, and you'll be scarred and exhausted, but you'll survive. Ignore it, and you'll perish.

For me, the word "evolution" captured the "why" and the "how" of what we're doing. We're responding to environmental pressures: Our stories.

Okay, now that I've had my say about how "evolutionary" was the perfect word, I'm going to let it go. The misinterpretations exist, and are too costly. (I'm sure it's hard enough for scientists to examine their own anthropocentrism. But our teams?! They have their own concerns.) I will always do the simple translation from "continual" to "evolutionary" in my head, but "continual" is a much simpler, much more digestible word.

RobMyers?

Evolution and natural selection are not synonymous. Natural selection is only one process by which evolution occurs. Although it's wise not to take the metaphor too literally, I like the "evolutionary" metaphor and related terminology. I suspect that evolutionary design is more related to memetic evolution than biological. I also don't see any contradiction with the terms "continual" and "evolution".

SteveBate?

I think of Evolutionary Design as being the big umbrella for the following design practices:

• Story Test-Driven Development (STDD)
• Test-Driven Development
• Refactoring
• Domain-Driven Design (DDD)

Our practice of DDD flows out of our continuous practice of STDD and TDD, since many of our storytests and unitests are focused on proving that pure business logic executes as expected.

DDD also influences our language, for we endeavor to speak with our project community using a Ubiquitous Language.

DDD also influences our choice to keep domain logic code totally free of non-domain-specific code, such as database, networking or ui code.

JoshuaKerievsky

See SimpleDesign