Legacy Technical Debt Management

Technical debt (also known as design debt or code debt) describes what happens when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it's the result of prioritizing speedy delivery over quality of code delivered.

This can come about through a number of reasons, for example: deliberate decisions to choose an easy and quick solution instead of using a better approach that would take longer or cost more, through accidental design flaws that do not properly future-proof the application, ageing/expanding code/functions that become too complex to replace overtime etc.

While there is no simple-one-size-fits-all cause, Product Owners will find there are different ways that might help us identify, communicate and address technical debt. It's important to remember here that some debt is expected, and that’s fine—what you need to understand is what you’re compromising in any decision, and for how long that is reasonable.

One way to accumulate technical debt is when product slowly evolves into unnecessary complexity through lots of incremental changes over time, often exacerbated when worked upon by several third party suppliers or multiple developers who might not have been properly introduced to the original architecture or design of the product. To avoid this its best to schedule code reviews before handing over products from one supplier to another, part of the on-boarding process for new suppliers, to help them understand the architecture design of the product before they work on it. Any bad code that might come up during the code review, should be tracked in your product backlog, prioritised, incrementally improved and cleaned up along the way in upcoming products iterations.

Another way would be to know the difference between the right way and the quick way to build something. You’ll find in some cases, especially when the team is up against tight deadlines they will intentionally do something “the wrong way” because they need to quickly deliver their product to meet organizational deadlines. In this case, it’s best to ensure Product Owners are aware of what this shortcut might cost them in the long run - what deliberate debt is being taken on and the pros and cons to the decisions made.

You could also address legacy technical debt by scheduling time in your roadmap to refactor on a regular basis. As products evolve, teams and requirements change over time, you might come to realize that your architecture is flawed, or that new functionality has become difficult and slow to implement. Product Owners usually address this by aiming to schedule a two-weeks maintenance sprint every three two-weeks support or development sprint - so once every six weeks. This ongoing approach to tackle technical debt helps you avoid hitting a wall at some point in your product roadmap.

You could also carry out regular reviews of the systems in place and try to identify any problem areas, such as duplication of functionality, platforms that are soon to become defunct, upcoming projects that may cause duplication etc. This can then influence the roadmap and make clear some of the connections between projects and systems.

Another important factor is having KPIs around your development velocity, product performance or security could help you reduce your chances in accumulating technical debt. Monitoring velocity closely ensure you don’t ask too much of our developers in too short a timeframe. Also, before launching any digital products best practice recommend carrying out performance and security testing, this way the code is always improving at the same time as value is being generated for the product and its users.

Involving the right people at key stages in a project can also help enormously in the avoidance of technical debt. For example, when teams within an organisation procure systems without talking to IT or doing so too late, there are often missed opportunities for synergy and integration. This is a key element of the agile approach, where all areas of the project team are involved in key stages, such as engaging developers during discovery and testers during product planning and release.

Taking a modular approach to architecture and or development helps reduce technical debt in that you can approach complex systems in a more simplified way. Creating small reusable components allows you to continuously improve smaller parts of the larger system and reduce the overall weight of technical debt.

In summary, it’s important to Marie Kondo your product backlog and codebase clutter and reflect it in your strategy and roadmap. You can do this by ensuring your decision-making regarding upcoming priorities takes into account future technical debt as you develop only the functionality that sparks true user value and drives better results.