“Technical Debt” has been a topic of discussion within the software industry for several years. However, recent events such as the Southwest airlines debacle and the FAA outage has brought “Technical Debt” and its consequences into the main stream, even garnering mention on the front page of the New York Times.
“Technical Debt”, as defined by Ward Cunningham, is the difference between the optimal cost of changing a product and the actual cost of changing a product. All products have some form of technical debt. While there are different types of technical debt[1] – deliberate vs. unintentional, reckless vs. prudent – there is no way to avoid the technical debt.
The reason that you can’t avoid technical debt is a result of a fundamental aspect of the human condition – we can’t predict the future. There are always going to be decisions made in designing, developing, testing, and implementing products that, while the correct decision at the time, are suboptimal for the product in the long-term. Who hasn’t asked the question, “Why did we build this way?” at some point in maintaining a product.
So, the issue isn’t how to avoid technical debt – you can’t. The only thing that you can do is to be aware of it, make regular payments against it and keep it manageable. Under Scrum, the responsibility to pay off technical debt ultimately falls to the Product Owner. Because the Product Owner is responsible for maximizing the value of the product and technical debt limits and/ or decreases that value over time, the Product Owner needs to ensure that the amount of technical debt remains reasonable.
The Developers, of course, are the ones that make the payment. They do so by regularly refactoring, using design techniques like Test Driven Development, and practicing continuous integration to quickly determine the impact of recent changes on the product.
The Scrum Master’s role is to ensure that the Product Owner and Developers are both educated about technical debt, the need for its regular repayment and methods for doing so.
While the full post-mortem on both the Southwest Airlines and FAA incidents have yet to be written, I guarantee that when done both will be shown to be the result of unpaid technical debt. Debt that was likely well-known to those that worked on and maintained the impacted products. Debt that these professionals escalated to leadership only to be told, “We’ll fix it later” or “I know, but we just don’t have time right now”. Technical debt is having its moment. If you want to ensure that that moment doesn’t extend to your organization – ensure that you make regular payments.
Are you interested in learning more about Technical Debt and how to pay it off? Please check out our upcoming Scrum Certification classes: https://www.agilityirl.com/scrum/
[1] See Martin Fowler, “Technical Debt Quadrant” for more: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html