We are concerned that future features might be hard to implement. Therefore we do extra work now to save time later. We may be able to go faster by doing less. Modeling the cost and return of anticipation shows that it may not be as valuable as we think.

In Extreme Programming, we do not design our objects to support more than the feature we are currently working on. We call this principle “do the simplest thing that could possibly work”.

A common concern with this notion is that it might be easy to design the objects more robustly, in case they need to be improved later, and it might otherwise be hard to improve them later, if the need we foresee arises. In this section I present a simple model of the cost of implementing with and without “anticipatory design”.

Now don’t get me wrong, I don’t think this model is the final word on the subject, but it is rather suggestive. If you would care to put together a similar model with similar or different conclusions, I’ll be happy to post it on my web site.

Let’s assume that we’re implementing N features that we know are requirements. For each one, we see that if we do a little extra “anticipatory” design, the object will be better-suited for some addition that we can foresee might be needed.

Suppose the cost of each original feature is 1, for a basic system cost of N.

Suppose the cost of the anticipatory design for each feature is D. We suppose that D will be less than 1. Then the cost of the basic system with anticipatory design will be N + DN, or N(1+D).

Suppose the cost of each needed anticipated feature will also be 1 with anticipatory design, and R without anticipatory design. We assume R > 1.

Now it turns out that we actually need some percentage P of the features we anticipated. Then the total system cost is:

With Anticipation N + D*N + P*N
Without Anticipation N + P*R*N
Benefit of Design, i.e. Without - With N + P*R*N - N - D*N - P*N, orN*(1 + P*R - 1 - D - P), or N*(P*R - P - D), or (P*R - P - D) (per feature)

For a few different values of D (the cost of design), here are tables showing the comparative costs per feature of the completed systems, over a range of P (percentage of anticipated features actually needed) and R (cost multiplier of feature not designed for in advance).

Here are the results if D, anticipatory design, costs 1.0. <table border="1">

1 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 5.50 0.00 (1.00) (1.00) (1.00) (1.00) (1.00) (1.00) (1.00) (1.00) (1.00) (1.00) 0.10 (1.00) (0.95) (0.90) (0.85) (0.80) (0.75) (0.70) (0.65) (0.60) (0.55) 0.20 (1.00) (0.90) (0.80) (0.70) (0.60) (0.50) (0.40) (0.30) (0.20) (0.10) 0.30 (1.00) (0.85) (0.70) (0.55) (0.40) (0.25) (0.10) 0.05 0.20 0.35 0.40 (1.00) (0.80) (0.60) (0.40) (0.20) 0.00 0.20 0.40 0.60 0.80 0.50 (1.00) (0.75) (0.50) (0.25) 0.00 0.25 0.50 0.75 1.00 1.25 0.60 (1.00) (0.70) (0.40) (0.10) 0.20 0.50 0.80 1.10 1.40 1.70 0.70 (1.00) (0.65) (0.30) 0.05 0.40 0.75 1.10 1.45 1.80 2.15 0.80 (1.00) (0.60) (0.20) 0.20 0.60 1.00 1.40 1.80 2.20 2.60 0.90 (1.00) (0.55) (0.10) 0.35 0.80 1.25 1.70 2.15 2.60 3.05 1.00 (1.00) (0.50) 0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50

</table> Here are the results if anticipatory design costs 0.5. <table border="1">

0.5 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 5.50 0.00 (0.50) (0.50) (0.50) (0.50) (0.50) (0.50) (0.50) (0.50) (0.50) (0.50) 0.10 (0.50) (0.45) (0.40) (0.35) (0.30) (0.25) (0.20) (0.15) (0.10) (0.05) 0.20 (0.50) (0.40) (0.30) (0.20) (0.10) 0.00 0.10 0.20 0.30 0.40 0.30 (0.50) (0.35) (0.20) (0.05) 0.10 0.25 0.40 0.55 0.70 0.85 0.40 (0.50) (0.30) (0.10) 0.10 0.30 0.50 0.70 0.90 1.10 1.30 0.50 (0.50) (0.25) 0.00 0.25 0.50 0.75 1.00 1.25 1.50 1.75 0.60 (0.50) (0.20) 0.10 0.40 0.70 1.00 1.30 1.60 1.90 2.20 0.70 (0.50) (0.15) 0.20 0.55 0.90 1.25 1.60 1.95 2.30 2.65 0.80 (0.50) (0.10) 0.30 0.70 1.10 1.50 1.90 2.30 2.70 3.10 0.90 (0.50) (0.05) 0.40 0.85 1.30 1.75 2.20 2.65 3.10 3.55 1.00 (0.50) 0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00

</table> Here anticipatory design costs 0.2. <table border="1">

0.2 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 5.50 0.00 (0.20) (0.20) (0.20) (0.20) (0.20) (0.20) (0.20) (0.20) (0.20) (0.20) 0.10 (0.20) (0.15) (0.10) (0.05) 0.00 0.05 0.10 0.15 0.20 0.25 0.20 (0.20) (0.10) 0.00 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.30 (0.20) (0.05) 0.10 0.25 0.40 0.55 0.70 0.85 1.00 1.15 0.40 (0.20) 0.00 0.20 0.40 0.60 0.80 1.00 1.20 1.40 1.60 0.50 (0.20) 0.05 0.30 0.55 0.80 1.05 1.30 1.55 1.80 2.05 0.60 (0.20) 0.10 0.40 0.70 1.00 1.30 1.60 1.90 2.20 2.50 0.70 (0.20) 0.15 0.50 0.85 1.20 1.55 1.90 2.25 2.60 2.95 0.80 (0.20) 0.20 0.60 1.00 1.40 1.80 2.20 2.60 3.00 3.40 0.90 (0.20) 0.25 0.70 1.15 1.60 2.05 2.50 2.95 3.40 3.85 1.00 (0.20) 0.30 0.80 1.30 1.80 2.30 2.80 3.30 3.80 4.30

</table> The red areas of the tables above are the areas where, according to this simple model, anticipatory design does not pay off. There’s an interesting cell in the table immediately above, at P = 0.4 and R = 1.5. I’ve colored it blue.

This cell says: if the extra design only costs 20 percent more, and you need 40 percent of the features you anticipated you might need, and it costs 1.5 times as much to implement without anticipatory design, you will still break even if you skip the anticipatory design.

What this all suggests is that unless it costs a whole lot more to put in new features without extra up front design, and unless you’re really excellent at foreseeing what you will need, you’re better off building software in the simplest most straightforward way, and keeping it well-factored. Please let me know your opinion - and send me a different model if you work one up!