AoAD2 Chapter: Design (introduction)

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.


Software typically becomes more expensive to change over time.

I’m not aware of any good studies on this,1 but I think it’s something every programmer has experienced. When starting a new codebase, we’re incredibly productive, but as time goes on, changes become more and more difficult. I’ve illustrated my experience with these costs in figure “Cost of Change Curves”.

1The most commonly quoted source is Barry Boehm, who has a chart showing exponential cost increases, but that chart is about the cost of fixing defects by phase, not the costs of change over time. And, as it turns out, that chart doesn’t accurately reflect the underlying data. Laurent Bossavit does an excellent job of chasing down the data in [Bossavit 2013] (chapter 10 and appendix B).

That’s a problem for Agile. If change becomes more significantly more expensive over time, the Agile model doesn’t make sense. Instead, the smart thing to do would be to make as many decisions as possible up-front, when they’re the least expensive. In fact, that’s exactly what pre-Agile methods tried to do.

In order for Agile to work, the cost of change must be relatively flat, or even decreasing over time. Kent Beck discussed this in the first Extreme Programming (XP) book:

[A flat cost of change curve] is one of the premises of XP. It is the technical premise of XP... If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible. If change is ruinously expensive, you would be crazy to charge ahead without careful forethought. But if change stays cheap, the additional value and reduced risk of early concrete feedback outweighs the cost of early change. [Beck 2000] (pp. 23-24)

Extreme Programming Explained, 1st ed.

But—as we’ve all experienced—the cost of change isn’t flat. It does increase over time. Does that mean that Agile teams are doomed to collapse under the weight of unmaintainable code?

Without evolutionary design, Agile teams are doomed to collapse under the weight of unmaintainable code.

The brilliance of XP was that it included practices to proactively reduce the cost of change. The central technique was called “evolutionary design.” XP remains the only mainstream Agile method to include it. That’s a shame, because without evolutionary design, Agile teams do collapse under the weight of unmaintainable code.

I first heard about evolutionary design in 2000. It sounded ridiculous, but I respected the people recommending it, so I tried an experiment. My team was just about to start a new project. We started with a traditional up-front design, then applied evolutionary design from that point forward.

It worked. It worked incredibly well. Evolutionary design resulted in steady improvement, giving us a design that was cleaner, clearer, and easier to change than the up-front design we started with.

I’ve been pushing the boundaries of evolutionary design ever since. As with traditional design, I’m not aware of any good studies on this, but my experience is that it does decrease the cost of change over time.

I’ve illustrated my experience in figure “Cost of Change Curves”. Changes are more expensive at first, because you take time establishing tests and good design abstractions, but then the cost of change drops as the design becomes easier and easier to work with. In traditional design, progress is fast at first, but changes become more difficult as design errors accumulate. The curves seem to cross at about the 4-6 week mark—in other words, after about 4-6 weeks of development, the XP approach is cheaper than the traditional approach.

A graph with two axes. The x-axis is labelled “Number of changes,” and increases to the right. The y-axis is labelled “Cost of each change,” and increases upward. The graph has two lines. The first is labelled “Traditional software development,” and it starts with very low cost, but increases asymptotically. The second is is labelled “Extreme Programming,” and it starts with much higher cost, but then decreases asymptotically. The point where the two curves cross is labelled “4-6 weeks.”

Figure 1. Cost of change curves

The clearest example of this reduction come from a screencast I produced from 2012-2018.2 In that screencast, I livecoded a multi-user drawing application using evolutionary design and other XP practices. Each episode was about 15 minutes long and I produced over 600 episodes. The result is 150 hours of meticulously-documented evolutionary design.

2The screencast is available at The networking example can be found in episodes 473-498 of the Live channel.

You can see the impact of evolutionary design in the screencast’s implementation of live networking. First, I networked the user’s mouse pointer. That took 12 hours. Then line-drawing: 6½ hours. Then clearing the screen: 2¾ hours. Then two tricky polish features: ¾ hour and ½ hour. If you graph it out, the decreasing cost of change shows up, plain as day. See figure “Real-World Evolutionary Design”.

A graph with two axes. It’s similar to the “cost of change curves” figure, in that it has an x-axis labelled “cost of change” and a y-axis labelled “cost of each change.” The graph has a curve showing an asymptotic decline, and five data points, each representing a change. From left to right, they’re labelled “Pointer (12 hours),” “Lines (6.5 hours),” “Clear button (2.75 hours),” “Disappearing pointer (0.75 hours),” and “Touch pointer (0.5 hours).”

Figure 2. Real-world evolutionary design

Evolutionary design is essential to long-term success with Agile. It’s revolutionary. And barely anyone knows about it.

This chapter has three practices for evolutionary design:

  • “Incremental Design” on p.XX builds design simultaneously with customer value.

  • “Simple Design” on p.XX allows your team to create designs that are easy to modify and maintain.

  • “Reflective Design” on p.XX improves the design of existing code.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.