Much has been written about how a lowered cost of change curve is a benefit. And it certainly is a benefit.
However, change is still costly, in terms of both time and money, even with this lowered cost of change. In fact, even with a fairly flat cost of change, change is expensive.
As an example, although in the software world it might be hard to find examples of “completely” flat curves, it is reasonable to find this in the physical world, so we’ll start off with an “ideally” flat curve and then work up to higher sloped curves more indicative of software.
So let assume, I want to paint my house and it will cost $1000. However I can change my mind and paint it however many colors I’d like to.
Each additional paint job also costs only $1000. (An ideally flat curve).
Now let’s say I change my mind 3x after painting it the first time. Total cost is $4000. If I had gotten it right the first time? A mere $1000.
Now let’s take a different example. Each subsequent painting costs 2x the first one, but they stay at 2x for each additional painting (still a very ideally flat graph).
If I change my mind 3x after painting it the first time, a whopping $7000. 7 TIMES the cost of getting it right the first time, even though only 3 changes were made and we used an exteremely ideal (read cheap) cost of change curve.
Now here’s a more interesting experiment. Let’s assume that the first painting is 1x, the second is 2x, the third is 3x and the fourth is 4x.
Now the cost of 3 changes is $4000+$3000+$2000+$1000 = $10,000.
What does that tell us? It tells us even with an exponential cost of change curve, we still would have done the project for only $1000 if we had gotten the color right the first time.
Now let’s say to get the color right the first time we had to do a little planning — maybe get some paint chips — have a meeting with the family etc. Let’s say that’s $500. The cost savings more than pay for it.
So what are some takeaways?
1) “Agile” methods that overly encourage change and de-emphasize planning can prove extremely costly regardless of what their claimed cost of change curve may be
2) Planning is as important (or more so) than ever. Although change happens, change can be minimized through analysis, design, communication, white boarding, etc.
Abdicating planning in favor of an ad hoc process can prove extremely costly
3) No matter how expensive or cheap the “cost of change” curve may be, the fewer changes that are made the cheaper and faster the result will be. No matter the methodology planning and minimizing unnecessary change is essential.
4) Planning is not a four letter word. Planning is responsible, as shown above. Sure, change happens, but stability happens too. Not everything is going to change, and one can plan for the parts that might change. A little planning goes a long long way.
5) Even with the highest possible cost of change curves, the better the planning the cheaper the project. This is what enabled, and enables “waterfallish” projects to actually succeed despite a lot of rhetoric to the contrary.
If someone hits me with a 500 page specification, I might decide it makes sense to say maybe that’s a little too much planning.
But I rarely see that in the modern world. Today it’s all too common to get a specification that is less than 3 pages, with no wireframes.
Most projects I see need more planning; not less.
They need a more cohesive vision and not weekly changes of direction in an ad hoc fashion.
I think adding planning to your practices will not only save you time and money, it will greatly reduce the bugs in your codebase, reduce the number of refactorings necessary, increase the morale of your team, and allow you to deliver more value in a shorter time frame.