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 in software engineering has the following characteristics:

2. Agenda for the Series

3. Measuring Cost of Change

An empirical approach was suggested to measure the cost of change in software engineering projects 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:

  • Number of impacted artifacts: The number of artifacts that must be modified per change directly impacts the cost of change. As the number goes up, so does the cost of change.
  • Size of change: Naturally, the size of the change will directly impact its associated cost.
  • Type of change: Design issues requiring major reworks will attract a higher cost as it will involve more people (architects, engineers, testers), modules, and features.
  • SDLC stage in which the change request is launched: Change requests coming in late in the project will have a significantly larger impact than those requested during the analysis or design phases.

4. 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:

Cost(\Delta) = f(Analysis + Coding)

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:

Cost(\Delta) = f(Analysis + Coding + Waste)

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:

Cost(\Delta) = f(Analysis + Coding + Waste) \times Tech_{Debt}

5. How Can We Measure Waste in Software Development?

The definition we normally use for waste is “any activity that does not generate business value and, therefore, does not impact the final shape of the product“. In this sense, waste is the overhead incurred for the smallest code change.

To measure the waste or overhead incurred by a change request to the development team, use the following recipe:

  • Step 1: Create a change where the analysis and coding are trivial (a one-line code change can do).
  • Step 2: 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; it is all waste.
  • Step 3: To determine an upper boundary on the cost of change, ensure you include all the effort accrued by running all test suites, updating any documentation such as release notes or user guides, and build and deployment pipelines associated with a significant change.

6. 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:

Lean_{Ratio} = \dfrac{value}{Cost(\Delta)}

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:

7. Final Words

In an industry where business requirement volatility is a constant, keeping the cost of change low enough is probably the most vital characteristic of a profitable software product.

We hope this article has succeeded in explaining the cost of change in software development, how it can be measured, and what remedies can be used to keep it acceptable.

Leave a Reply

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