Principles of Technical Debt
Three leading experts from the Software Engineering Institute introduce integrated, empirically developed principles and practices that any software professional can use to gain control of technical debt in any software system.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
There is still much friction in the process of crafting complex software; the goal of creating quality software in a repeatable and sustainable manner remains elusive to many organizations, especially those who are driven to develop in Internet time.
—Grady Booch
Is the productivity of your software organization going down? Is your code base harder and harder to evolve every week? Is the morale of your team declining? As with many other successful software endeavors, you are probably suffering from the inability to manage friction in your software development and may have a pervasive case of technical debt.
Why should you care about technical debt? How does it manifest itself? How is it different from software quality? In this chapter, we introduce the metaphor of technical debt and present typical situations where it exists.
The Promise of Managing Technical Debt
Understanding and managing technical debt is an attractive goal for many organizations. Proactively managing technical debt promises to give organizations the ability to control the cost of change in a way that integrates technical decision making and software economics seamlessly with software engineering delivery.
The term technical debt is not new. Ward Cunningham introduced it in 1992 to communicate the delicate balance between speed and rework in pursuit of delivering functioning quality software. And the concepts it encompasses are not new either. Ever since we started creating software products, we have been grappling with this issue under other names: software maintenance, software evolution, software aging, software decay, software system reengineering, and so on.
You can think of technical debt as an analogy with friction in mechanical devices; the more friction a device experiences due to wear and tear, lack of lubrication, or bad design, the harder it is to move the device, and the more energy you have to apply to get the original effect. At the same time, friction is a necessary condition of mechanical parts working together. You cannot eliminate it completely; you can only reduce its impact.
Slowly, over the past ten years, many large companies whose livelihoods depend on software have realized that technical debt, under this or any other name, is very real and crippling their ability to satisfy customer desires. Technical debt has started to translate into financial impact. At some point in the past, companies may have made a trade-off to take on technical debt to deliver quickly or scale quickly, threw more people at the problem when the debt mounted, and never reduced or managed the debt. It is not a proper debt, from an accounting perspective, but the specter of huge costs somewhere on the path ahead will negatively affect the company’s financial bottom line. Government organizations that are large buyers of software also now realize that focusing only on initial development cost obscures the full cost of the software; they have begun to demand justification of all lifecycle costs from the software industry.
Technical debt is pervasive: It affects all aspects of software engineering, from requirements handling to design, code writing, the tools used for analyzing and modifying code, and deployment to the user base. The friction caused by technical debt is even apparent in the management of software development organizations, in the social aspect of software engineering. Technical debt is the mirror image of software technical sustainability; Becker and colleagues (2015) described technical debt as “the longevity of information, systems, and infrastructure and their adequate evolution with changing surrounding conditions. It includes maintenance, innovation, obsolescence, data integrity, etc.” And it relates to the wider concern of sustainability in the software industry—not only in the environmental sense but also in the social and technical senses.
Progress on managing technical debt has been piecewise, and the workforce tends to devalue this type of debt. So it remains a problem. Why do we think that understanding and managing the problem as technical debt will have a different outcome? Software engineering as a discipline is at a unique point at which several subdisciplines have matured to be part of the answer to the technical debt question. For example, program analysis techniques, although not new, have recently become sophisticated enough to be useful in industrial development environments. So, they’re positioned to play a role in identifying technical debt in a way they weren’t a few years ago. DevOps tooling environments that incorporate operations and development further allow developers to analyze their code, locate issues before they become debt, and implement a faster development lifecycle. Developers also now have the vocabulary to talk about technical debt as part of their software development process and practices.
The technical debt concept resonates well with developers, as they look for a well-defined approach to help understand the complex dependencies between software artifacts, development teams, and decision makers and how to balance short-term needs to keep the software product running with long-term changes to keep the product viable for decades. In this way, technical debt can also be seen as a kind of strategic investment and a way to mitigate risk.