As Judge Marilyn Milian says on The People’s Court—the cheap comes out expensive. This is an easy way to describe the problem of technical debt. Code gets deployed because it provides a quick fix for little effort at the time, but it is not designed to scale to the level that the project needs. If that code is not replaced in a timely fashion, then the cost of replacing it once it becomes a problem will shoot up exponentially. In an article for Scrum Alliance, Saumya Srivastava describes how to stay on top of technical debt in an agile setting.
Cut the Cost
Risks resulting from technical debt include software quality loss, damage to brand value, deterioration of customer trust, and of course the cost of refactoring. As for how technical debt accumulates in the first place, it can happen for many reasons: market or budgetary pressures, inadequate analysis of what is really required to address a problem, or general recklessness. The point is that technical debt is insidious and easy to miss.
Srivastava ultimately shares six steps to cutting down on technical debt:
- Educate the product owner on the overall cost of technical debt.
- Ensure that stakeholders understand that architecture growth is akin to any application growth.
- Modularize your architecture as components that can be used in other applications.
- Write regular unit test cases and conduct peer code reviews for modules.
- Automate test cases.
- Allow for some designated technical debt to exist and be serviced during sprints.
For some additional elaboration on the second step, Srivastava says this:
For any new features that we add to an application, we should have an equal extension in architecture in the initial phases of a sprint. This practice has been well described in the SAFe framework as having an architectural runway that is parallel to the application runway. This can be planned based on the requirements of the application. This way, we’ll reduce technical debt by following proper engineering processes.
Technical debt will often exist in an environment that demands speed, and that is okay. What matters is that you have a conscious and ongoing plan for how to manage it. You can view the original article, with some examples of the damage that technical debt has incurred, here: https://www.scrumalliance.org/community/articles/2017/july/technical-debt-and-agile