## A Flattened Cost of Change Curve: An economic analysis

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.

C#, WPF, Android, Architect, Developer, Consultant, Project Manager available for remote/telecommute assignments
This entry was posted in .net, agile, c#, scrum, software architecture, xp and tagged , , , , , , , , , . Bookmark the permalink.

### 7 Responses to A Flattened Cost of Change Curve: An economic analysis

1. Jason says:

I think your analogy is over simplistic. Choosing a colour of paint is not the same as developing a software system. Developing a software system requires countless numbers of decisions in an environment of constant change. Choosing a paint colour is one decision in an environment of no change. Furthermore, the impact of choosing the wrong colour is inconsequential when compared to making the wrong decision of what to build on a software project.

It is for this reason that agile methods promote short feedback loops. Working incrementally in small iterations allows your stakeholders to actually see how the software works and to change direction as a result of learning more about the problem domain. Traditional development on the other hand seeks to restrict change as much as possible. This is good if it’s your job to build software, but really bad if you’re the customer and can’t change your mind when your situation changes!

I’m a little confused about your comment that agile methods de-emphasise planning. My experience is that agile methods promote constant planning, whereas traditional methods promote working to a plan that is constant.

• Jordan says:

Hi Jason

1) It’s correct that I chose a simple idea (painting a house) but that is a practical example of a “completely flat” cost of change.

That was done on purpose — to show that even in the mythical “completely flat” case it is still expensive to have change.

Later examples in my post that use higher multipliers are more typical of what is typically found in software/etc development. It doesn’t matter what the task is it only matters what the cost of change is.

If you don’t like the word “painting” feel free to substitute whatever task you prefer; it doesn’t change the numbers

2) How often should the customers change their minds? Sure they will change their minds about some things but not all things.

Preparing for change makes sense, but refusing to put any pressure on the Product Owner to do their job and plan appropriately, gather requirements as appropriately, etc, just for the sake of acquiescing to constant change due to lack of due diligence makes no sense

3) Traditional methods do not work to a plan that is “constant.” That is a straw man.

Feel free to read my posts https://jordanbortz.wordpress.com/2011/03/31/the-high-cost-of-emergent-designsubsequent-refactorings/

https://jordanbortz.wordpress.com/2008/05/26/agile-waterfall-are-two-sides-of-the-exact-same-coin/

4) My post has math to back up my statements. Can you provide math showing that allowing constant change is more cost effective in the long term? My math seems to indicate that getting things right sooner has huge payoffs, even significant enough payoffs to pay for the occasional change. Please substantiate the economic analysis of your viewpoint.

5) While I’m on the subject, perhaps this is a good reason to NOT provide “shippable” software at every iteration. If early iterations were merely mocks that provide the ability to change their mind quickly, with very little cost (due to essentially no real code but mere “live wireframes”), and change was shaken out early, we might have a more “agile” front end with more customer interaction, and having shaken out most of their design, reduce their input and number of changes once the coding starts.
Regards,
Jordan

2. Ruben Fragoso says:

I sincerely love the 2 posts that you wrote, this one and the Rhetorical Anti-Patterns. It makes so sense that i could not have written better myself =).

3. Stefan Iancu says:

Agile has many planning layers, like the onion / Ogre :-). Unfortunately, most of the agile practitioners take the simplistic view of only planning one iteration ahead or even worse, only during the daily meetings. One should not overlook the importance of a strong product vision, product roadmap and release planning. Without these you will quickly go far off target and overrun the budgets, even worse then in a waterfall project which is usually over-planned.

4. Neil Killick says: