Software Design/Change amplification

Change amplification is defined by John Ousterhout in A Philosophy of Software Design as a symptom of complexity which is that a seemingly simple change requires code modifications in many different places.

As a code quality, change amplification (or repetitiveness) may be defined as the expected (or the average) number of places and volume of code in the codebase that needs to be modified in a logically atomic change to the software.

Relations to other qualities

Note that the definition of complexity as a high-level quality in A Philosophy of Software Design differs from the definition of complexity as a primary quality in the Software Design project. Change amplification has little to do with complexity as a primary quality. Rather, it is related to the following qualities:

• Easiness of change: modifying more code takes more effort.
• How much navigation is needed while working with code: to modify code in different places, the developer should first navigate to those places.
• Code robustness: often, there are no compile-time checks that guarantee that all places in the codebase that should be modified as part of the change are actually modified. In this situation, it's easy to forget to modify some of the places and thus introduce defects.

Relevant practices

• Don't repeat yourself

Code smells:

• Object access chain: both exposing and hiding object access chains may contribute to change amplification in different circumstances.

See also

Other symptoms of complexity, according to A Philosophy of Software Design:

• Cognitive load
• Unknown unknowns