Change Happens—So Make it Cheaper

Change on software projects is expensive; it leads to wasteful rework.

Change is risk. We can deal with risk one of two ways. We can reduce the likelihood of the negative event occurring. Or we can reduce the impact of the negative event when it does occur. (Of course, the two can often be combined.)

The traditional approach says, “Let’s put more effort and thought in up-front and avoid that expensive change.” (That is, let’s prevent the negative event from occurring.) The problem, as decades of experience have shown, is we still can’t seem to avoid change. Here’s why: the kinds of change that plague software development can’t be eliminated by thinking harder up front.

There are two main sources of change we see on software projects:

1. The customer/PO/stakeholder sees what gets built and decides she actually wants something different.
2. Something changes outside the project that requires the project to change.

Neither of these could have been eliminated by better planning.

Given an unpreventable risk, the logical approach is to work to reduce the impact. This is where agile goes. If change is going to happen and if it’s expensive, let’s make it cheaper.

A few ways to make change cheaper:

1. Plan with different levels of detail for different time horizons. You can have a big vision for months and years in the future, but only plan the details for the next few hours or days (with appropriate increments in between).
2. Build just enough software to solve the problems you know about rather than trying to build grand solutions that will address future needs. Grow general solutions by refactoring from specific solutions to real problems.
3. Pay attention to quality from the beginning and continuously (e.g., good design, automated tests, etc.) so that code is easy and safe to change.
4. Defer decisions as long as you responsibly can so that you have time to gather more information.
5. Get feedback early and often—and structure your work to provoke useful, early feedback—so you make small adjustments rather than big, disruptive changes.

What else have you done to reduce the cost of change?