In a recent article entitled “Continued Delivery of High Values as Systems Age”, Chris Sterling discusses the concept of Software Debt – “Software debt accumulates when focus remains on immediate completion while neglecting changeability of the system over time.”
Software debt goes beyond what is typically referred to as technical debt -
He identifies the four components of software debt as:
- Technical Debt: those things that you choose not to do now and will impede future development if left undone
- Quality Debt: diminishing ability to verify functional and technical quality of entire system
- Configuration Management Debt: integration and release management become more risky, complex, and error-prone
- Design Debt: cost of adding average sized features is increasing to more than writing from scratch
- Platform Experience Debt: availability and cost of people to work on system features are becoming limited
He discusses how software debt creeps into projects, and provides a view of how projects accumulate debt over time, often for the best motivation and a desire to maintain the pace of delivery in the face of increasing complexity.
In a similar vein Bill Curtis discusses the impact of Muda (“Muda” is the Japanese word for waste) on software projects – the most common source of waste on software projects is rework, the result of software debt:
The few available studies of rework report that it accounts for between 30% and 50% of project effort in most organizations that have not undertaken successful process improvement. Rework numbers are painful, not only in the collecting, but also in the fessing up. Few executives want to admit they are flushing away an average 40% of their investment in applications.
Sterling suggests ways to manage and reduce software debt:
- Maintain one list of work
- Emphasize quality
- Evolve tools and infrastructure continually
- Always improve system design
- Share knowledge across the organization
- And most importantly, hire the right people to work on your software!
In the article he provides advice on how to address each of these points.
He concludes the article with the following comments:
As systems age they can become more difficult to work with. Software assets become liabilities when software debt creeps into systems through technical debt, quality debt, configuration management debt, design debt, and platform experience debt.
Applying the six principles in this article will lead to small changes that over time will add up to significant positive change for teams and organizations. The goal of managing software debt is to optimize the value of software assets for our business and increase the satisfaction of our customers in the resulting software they use.
How do organisations reduce software debt and protect their investment in software systems?