Cost of Change — The Hidden Driver Behind Our Software Delivery Choices

1. What Is Cost of Change

Cost of change refers to the dollar value a project incurs if a business requirement is modified before delivery. Naturally, we want the cost of change to be as small as possible.

Cost of change has the following characteristics:

• It is a direct outcome of requirement volatility, a concept that software development professionals accepted as far back as the Agile manifesto in 2001.
• It cannot be eliminated, regardless of methodology, but it can be kept within acceptable boundaries, as we shall see later (full discussion on the cost of change as a comparison measure between Agile, Waterfall, and DevOps).
• It provides a basis on which software delivery methodologies can be compared, lower meaning better.

2. Measuring Cost of Change

An empirical approach was suggested to measure the cost of change in a paper published in 2012 titled “Measuring the Impact of Changing Requirements on Software Project Cost: An Empirical Investigation”. The approach provides a conceptual framework founded on two ideas:

• The number of artifacts that must be modified per change directly impacts the cost of change.
• With sufficient data, a regression model was created that included other parameters such as priority, the stage of the SDLC in which the change request is launched, and the size of the proposed change.

3. Drivers of Cost of Change

To better understand the cost of change, we need to examine the drivers behind it. Implementing a new feature requires, at the minimum, some analysis and coding. Business value is created at this stage, and the customer is happy to cover the costs.

Ideally, the cost of change can be modelled as:

As pointed out by Winston Royce in his famous paper in 1970, analysis and coding are hardly enough to deliver new functionality; software design, validation and verification, documentation, and operations effort must be invested. In lean terminology, this is referred to as waste. Our new formula for cost of change is now:

The picture is, however, not yet complete since we have not accounted for technical debt, which decreases productivity across the board. Fragile software architecture, legacy code, and poor documentation make every delivery stage harder. A more realistic equation would be:

4. How Can We Measure Waste in Software Development?

To measure waste, use the following recipe:

• Create a change where the analysis and coding are trivial (a one-line code change can do).
• Then, calculate the time spent from locking the requirement to coding, testing, building, packaging, and deployment; that would set a lower boundary on the cost of change. In this example, the value generated is nil, while the rest is waste.
• To determine an upper boundary on the cost of change, ensure you include all the effort accrued by running all test suites, documentation tasks, and build and deployment pipelines associated with a significant change.

5. How Lean Are We?

We can determine how lean our production processes are by calculating the following ratio of business value generated divided by the cost of change for the feature in question:

Explaining a low lean ratio to senior management is one of the more difficult tasks developers have to do.

While this ratio can be easily justified in some cases, it becomes ever more challenging as its value dwindles. Typical remedies to drive the cost of change down can be:

• Refactoring bad code
• Modularizing software architecture
• Automating builds and test executions
• Targetted testing through impact analysis
• Fast CI/CD pipelines