In a technology organization, terms like technical debt, refactoring, or a hack are quite common to use. Knowing what technical debt is helps you work productively with software engineers. This post explains what technical debt is and how to manage it efficiently.

What is Technical Debt

Technical debt is similar to credit card debt. You can spend some extra money now with a credit card. If you won’t pay it back shortly, you’ll be charged interest. If you don’t pay it off for a long time, the amount you owe increases drastically. This decreases your credit score which is hard to recover from.

Taking on technical debt in software product development is very similar to it. In order to accomplish a certain feature faster in the short term, a developer can apply a hack. If the hack is not replaced with a well-made out solution, the code around it decays over time. In addition to it, the software is built on top of other software. We all use libraries and operating systems. Technologies change and the system needs maintenance updates as time goes by, even if there are no new features being developed. If maintenance updates are not addressed, it also increases your technical debt.

Why Taking on More Technical Debt Slows You Down

As you apply more hacks, your future development gets slower, you have more bugs in the product, and you get closer to the point when you need to start over. I’ve seen several companies in the past abandoning and rewriting their entire application from scratch since they were not able to make meaningful progress anymore.

How to Manage Technical Debt

Get on the same page with engineers and stakeholders

It’s crucially important for everyone on your engineering team and for stakeholders to understand the implications of endlessly taking on technical debt. Set up and maintain high code standards and high test coverage on your engineering team. Make sure that stakeholders understand the technical debt concept and how it affects the speed and quality of the product. Aligning everyone’s expectations goes a long way.

Pay it off right after you introduced it

Every system has technical debt. Sometimes we need to focus on short-term goals. In this case, it's ok to introduce technical debt if and only if you can pay it off right after you introduced it. The companies that ignore this important fact and continue to what seems like “moving quickly” will eventually slow down to a halt.

Revisit your architecture regularly

What worked several months ago will not necessarily work now. Especially in startups where businesses grow and change fast, it’s important to revisit decisions made in the past. Take your time to refactor (or better yet, delete) code that no longer makes sense in order to accomplish the needs of today. Bring it up with your team as a part of your retrospectives and make action items to make sure it gets done.

Pay off big debt incrementally

When dealing with legacy systems, it may be too big of a task for one engineer to refactor it. In this case, make a plan on how you want it to look and change it one piece at a time. It’s important to maintain the vision of what you want this legacy system to be at the end.

Leave the codebase in a better place than when you started

All that matters is if everyone makes incremental progress towards making the codebase better. It’s impractical to stop feature development to get rid of all technical debt. Maintaining the right balance between feature delivery and paying off technical debt is key.

Conclusion

Every system out there has technical debt. Managing it effectively is a skill that can be learned. Technical debt is a risk. It's best to avoid risk and sometimes you have to take it. As long as the team is disciplined about paying it off, it's ok. At the end of the day, we all want to ship quality product, and managing technical debt is a part of it.

Photos are provided by p_valdivieso _and_ smemon

Originally posted on alextamoykin.com