Flattening the Cost of Change Curve: Theory vs. Practice

Modern languages combined with the engineering practices derived from eXtreme Programming (Test Driven Development, constant refactoring, continuous integration…) make it possible to flatten out the pessimistic exponential “cost of change curve” we learned in the early days.

The ability to *do* this involves learning skills and habits your team may not have yet.

There are a few areas no one’s learned how to flatten the cost of change curve completely, especially post release.

Examples of things Danube has found harder to change (especially post-release):

  1. database schemas
  2. APIs others have started depending on
  3. UIs your users have become accustomed to
  4. application servers (JBoss, WebSphere, etc.)
  5. programming languages

These things can (and often should) be changed in the future, but the cost will be higher than a design change in a well-written object oriented program that has automated tests. Perhaps this
shows limitations of our skills as an industry.

(The word ScrumMaster itself is another example. Many of us wish we’d chosen a term like Scrum coach or Scrum facilitator to more clearly convey the ScrumMaster isn’t the team’s boss. But changing the term now would only increase confusion.)

This isn’t an excuse to dwell forever on future-proofing things like the database schema. There’s a reasonable balance point between due diligence and analysis paralysis. You can release a migrator with your next version. Sure there’s some rework, but rework is cheaper than no work.

–mj

Download the PDF version: Flattening the Cost of Change Curve blog

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
5 comments on “Flattening the Cost of Change Curve: Theory vs. Practice
  1. Michael James says:

    Some common sense from XP luminary Kent Beck about cost of change.

    –mj

  2. Niels says:

    I’m curious about the “hardness” of changing database schemas. Would the use of “public synonyms” help?

    Another thing hard to change would be negative perceptions (eg about software development projects), positive perceptions however may be changed quite easily 🙂

    Anyway I like the philosophical viewpoint of this posting and I enjoyed the course you gave in Amsterdam last week.

    Niels

  3. Michael James says:

    A friend of mine in Seattle also wrote to me about this. There’s things we can do to mitigate this — it’s not an unsolvable problem or even a particularly hard one. But no matter what, it’s going to have a greater cost than a simple code refactoring that doesn’t touch the persistence layer, and there may be times we wish we’d chosen “correctly” in the first place.

    With databases, the cost of change is a little higher still if we’ve deployed or released a previous version with active data we’ve promised to preserve. We probably need to write some kind of migration (either explicit in one step, or implicit) which may itself have bugs or be misused by customers (ahem…).

    Probably any promise we’ve made in the past increases the cost of change. In the case of user interface, people may get attached to our old UI. One way or another this will increase the cost of switching to a better UI. With an API, we may be obliged to support the deprecated one years after we come up with a better one; this constrains our options.

    Database persistence can be seen as a special case of API that involves our past selves talking to our future selves.

    Thanks for the kind words, Niels. Amsterdam was a great course with a positive group of participants.

    –mj

  4. dlefebvre says:

    In your post you state:

    The word ScrumMaster itself is another example. Many of us wish we’d chosen a term like Scrum coach or Scrum facilitator to more clearly convey the ScrumMaster isn’t the team’s boss. But changing the term now would only increase confusion.)

    What I do with my teams is spend a few minutes relaying a post I once read from Bryan Stallings:

    When I work with those new to Scrum I explain this subject as follows…

    I ask them to tell me what a Master-of-Ceremonies does. They tell me about events such as the Oscars and explain that an individual with this role is responsible to ensure that the event progresses as planned, that they facilitate the transition from one phase of the event to another, and that they step in should anything unplanned occur.

    I then ask that they describe to me the responsibilities of a Quartermaster in the military. They explain that a Quartermaster provides the troops with all that is required for their success and comfort, and sets-up suitable circumstances.

    I of course agree with them and then I proceed to explain that like a Master-of-Ceremonies, a ScrumMaster is responsible to ensure that the Scrum process progresses effectively from event to event, that a ScrumMaster also steps in should an obstacle to success be encountered. Additionally, I explain that like a Quartermaster, a ScrumMaster shoulders the responsibility to provide the team with all that is necessary to ensure their success, comfort, and suitable circumstances.

    So this change in perspective helps clear up the confusion and gives them a better understanding of the ScrumMasters responsibilities.

    Regards,

    Dan

  5. Michael James says:

    Dan, I wish more people, including some “ScrumMasters” understood this the way you do.

    –mj

Leave a Reply

Your email address will not be published. Required fields are marked *

*