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.


About Jordan Bortz

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. Pingback: The High Cost of Emergent Design/Subsequent Refactorings « Jordan Bortz’s Software Architecture Blog

  2. 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/


      for more information on these topics

      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.

  3. Pingback: My recently “disappeared” comments regarding PMI and Scrum | Jordan Bortz's Software Architecture Blog

  4. 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 =).

  5. 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.

  6. Neil Killick says:

    You are right to point out that Agile projects can become very costly if the changes that emerge throughout are not traded-off for lower value scope by the product owner. However the situation you present is not a good example of why this is the case. I can easily present the situation you’re describing differently and demonstrate that a Waterfall approach would be more costly. What if you kept changing your mind about the colour “up front” for a month, thus the paint job is delayed one month until you have “signed off” your requirement (finally made up your mind), and when you finally make up your mind you settle for the colour you originally wanted? With a phased approach, the cost of your project is higher (by one month) because the painting cannot start until you’ve signed off your colour choice. With Agile we would have started straight away with your original choice, thus delivering more quickly and cheaply. If you insisted, say after a week, that your colour choice was wrong then we would only have to repaint what we’d completed, not the whole house. Or better we could paint other walls with the new colour (I’ll come onto this).

    Your example is simple rather than simplisitic, and I have no problem with that. However in such a situation where the outcome is simply a painted house and the method to get there is simply to paint the house, whether you use an Agile or Waterfall-based approach is probably neither here nor there. In both cases, if the customer decides to change their mind once the outcome is delivered (their house is painted) then the cost of change will be the same regardless of method.

    Agile welcomes change throughout the delivery of the project because it recognises that there is uncertainty about what the customer wants at the beginning (even if they say they want green they might change their mind later). This is not the same as allowing adhoc changes to the actual outcome required. But in this situation the actual outcome is the colour of the painted walls. Assuming you want all your walls the same colour (which may not be valid – I’ll come onto that), I would want you to tell me what colour you want before I start painting, Agile or otherwise. Then when the house is painted, the “project” is now delivered. The change of mind is method agnostic. Your argument about upfront planning doesn’t wash in this case because planning is done throughout an Agile project and the customer’s desired outcome is iteratively put at the forefront. In this simple example, the iteration planning and upfront analysis are most likely the same thing.

    We all know that the benefits of Agile become apparent when there is higher uncertainty or more unknowns about the project because it allows for emergent discovery. In simple situations like the painting of a house, just do your planning (pick your colour) and get on with it!

    Although I will say that even if the cost of change is higher by taking an Agile approach (and, yes, it will be for some projects, and cheaper for others) at least the customer will end up with what they want at the end, not what they originally thought they wanted. And theoretically, as I hinted at earlier, we could paint different walls with each of your different colour choices as you change your mind iteratively, perhaps helping along your final decision, and when you do decide on the colour for all the walls we have at least one wall already done.

    Or you may decide you like having the different coloured walls!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s