Technical debt is present in every software product as the scope changes and technologies move forward. Even the state of technical knowledge is changing, often leaving the product’s code as legacy.
Dealing with technical debt can be challenging as many teams adopt long term plan to leapfrog technical debt by rewriting products from scratch one day, leaving technical debt is unmanaged for a long time. Problem is, unmanaged technical debt makes the team slower to build new features as it is harder and harder to understand how to manage parts of deprecated code. Worse still there is never a business pressure to rewrite the legacy code and even if – this comes at a significant risk of introducing new bugs with the new code.
Many other teams adopt mid term solutions to deal with technical debt by carefully reporting and planning a technical debt backlog. Issue is, the backlog is just a careful documentation of existing technical debt. As much as it helps with dealing with legacy issues when time allows, it doesn’t solve the problem of when to find enough time to deal with technical debt backlog in the first place. As a result, business pressure to implement new features often leave the technical backlog ever growing. In worst case scenarios, even issues along with proposed solutions in technical backlog can become a technical debt on its own when proposed solutions go out of scope by technical or business means.
The only viable way of tackling technical debt is to deal with it as part of ongoing effort during continual rework of code to match the current practice and standards. Teams adopting strategy of continual improvement usually get the best result as they include dealing with technical debt with scope of every work item at hand. Dealing with artefacts of technical debt as you progress with implementing change requests and business requirements make the most sense, because it does not need allocating any extra resources, technical backlog planning. Equally important, it does not introduce any spikes of risk as the very code affected by change request is affected by refactoring as well.
The practice of change and upgrade plays well with engineering culture. You cannot have the benefits of single standard if you deliberately divide all your programming efforts into two categories. Writing new code should not be conducted using different standards than maintaining old code. Putting technical debt aside into a different backlog for future development is nothing different than swiping dirt under the rug. We all know many components lag current standard. If there is no need to touch the legacy code that is already working in production, don’t fix it just because you can. If you do have a genuine reason to work with legacy code, make sure the class, module or component is upgraded as part of your bug fixing or change request effort, because it will be equally prone to errors and needed for testing anyway.
- Author
Maciej Zagozda
Company founder, and director of engineering.
- Comments
- Leave a Comment