An Introduction to the Cost of Change and Technical Debt
Problems seldom get better by letting them fester, whether it is tidying a cluttered room or fixing a rusty car. In software projects, the costs associated with fixing defects typically increase the longer we leave them, following a cost of change curve as shown below:
The curve shows that the longer a defect is left unaddressed, the more expensive it will be to fix. There are a number of reasons why the cost of fixing a problem increases over time, but two of the key factors are:
Over time, more work will have been built on top of the error or problem, so that more work will need to be undone to fix it and then redone again.
The later in the development cycle, the more stakeholders will be impacted by the defect. Fixing an error when it is just a specification might just take a minute; when it has been coded, tested and rolled out to thousands of users, the cost of a fix and redeployment can be very expensive.
In the early days of agile, people argued agile methods resulted in flat (or flatter) cost-of-change curves. This argument has largely been dropped now; instead, it is agreed that agile approaches help drive teams lower and more to the left on the curve. Agile methods focus on frequent verification and validation--both through active stakeholder participation (such as modeling, demonstrations and reviews) and through XP-inspired development practices (
Please log in or sign up below to read the rest of the article.