Much like financial debt, technical debt is helpful when managed responsibly, but like real debt, tech debt can also stop growth and innovation in its tracks.

My colleague Bryan Ross has a piece out on tech debt with five ways to address is.

Here’s a summary of it.

Think of technical debt as the accumulation of compromises on development quality to save time. Some examples of these choices are postponing unit tests, running outdated software, or focusing on end-user features at the expense of internal processes. When you don’t address these your process will eventually slow down each release cycle.

For example: testing new features will be more difficult because of dependencies on untested code, so when you’ll have to release untested code…or go back and fix those tests, which will take longer because you’ve forgotten how the code works, and will keep uncovering more and more untested code.

To address technical debt, organizations should adopt a low-risk, gradual approach. Over ten or so years, VMware Tanzu Labs has done just that with the Swift method. It involves selecting a non-critical application, but customer facing application to modernize. By working on this small app, you learn the Swift method, you discover changes that need to be made in your organization, and also build up one success case. This systematic approach helps businesses discover, experiment, and learn how to tackle their technical debt.

Too much tech debt comes from unhealthy habits. So you need to change those too. Here’s five steps to health:

1. Map your end-to-end process - one of the hidden types of tech debt it lack of knowledge and coordination about how your software goes from idea, to code, to production. Figure that out.
2. Be serious about automate testing: Implement automated testing to catch problems early and introduce a metric for software quality.
3. Agree on better coding practices: encourage standardized approaches, pair programming, and peer reviews to reduce defects and improve collaboration.
4. Plan for the future: Adopt microservices architecture to make applications more modular and adaptable. We don’t talk about this part of microservices a much as we used to. Perhaps the best mearware part of microservices is how they can decouple different groups. Here, this means making it easier to change parts of your code without having to change other parts.
5. Standardize the environment: rtegularly rebuild the development environment using automated tools to prevent temporary fixes from becoming permanent.

You’ve got to address technical debt or you’ll end up stifling innovation and quickly slow down the business.

Check out his overview for more details.