How To Avoid Technical Debt

Introduction

In product development, there’s the easy way, the hard way and the right way. Oftentimes, teams choose to take the easy way when it comes to building products. One of the major consequences is technical debt. Technical debt, just like any other type of debt, if not managed correctly, can lead to major problems for multiple stakeholders. According to Accenture, 70% of C-suite executives say technical debt is hindering their ability to innovate, 72% mentioned that it limits their ability to migrate to new technologies and 69% added that it makes their IT function much less responsive to changes in the market.

What is technical debt? 

Technical debt is a term used in software development to describe the cost of taking on an easier solution or process knowing the longer and/or tougher solution will cost more in terms of time or money. Monetary debt is a perfect analogy for technical debt. The more debt you accrue, the harder larger the interest rate which makes it harder to get out of debt. It’s the same with technical debt, the more you accrue, the harder it becomes to get out of debt. If technical debt is not managed correctly, it can lead to technical bankruptcy.

Technical bankruptcy occurs when an individual or an entity has defaulted on debt payments but has yet to officially declare bankruptcy before a court. When you’re building a system or writing code, you need to be able to measure your technical debt. If the amount of work needed to fix the current code would cost more than it would implement a new system, then you’re on the brink of technical bankruptcy. Just as in financial bankruptcy, when you declare bankruptcy, there are consequences like losing control of your company or possessions and having less credit available to unlock future opportunities.

 

10 ways to tell if you have technical debt

1. Are your engineers advising you to decrease feature development velocity to refactor code from previous releases? You might have technical debt. 
2. Are you behind on versions to the point your application is losing compatibility with others in the industry? You might have technical debt.
3. You don’t have documentation available for anyone jumping on to the engineering team. 
4. There’s no testing suite set up 
5. If you create more bugs than you close per cycle, you might have technical debt. 
6. If simple changes to the codebase take longer than they should, you might have technical debt. 
7. If you start to see attrition on your team at a rapid rate, you might have technical debt. 
8. If information from your retrospective/sprint planning meetings ends up on a subreddit called /products gone wrong, you might have technical debt.
9. If your customers start to complain about user experiences that aren’t intuitive because you had engineers designing in the codebase instead of dedicating a UX professional to the whole flow, you might have technical debt and design debt. 
10.  If you have smelly code like dead (or undead) code, spaghetti code or duplicate code, you might have technical debt.

What can you do to get out of debt? 

Just like monetary debt, it will take extra effort to get out of technical debt. The question becomes, what behaviour will yield the most impact? If we’ve accrued so much debt, is it worthwhile to declare bankruptcy and start fresh? Can we put a plan in place for refactoring, expanding test coverage, adding documentation? Refactoring and cleaning up your code can take a long time, but is much less work than writing from scratch. Regardless of what you decide, you’ll have to forego development velocity focused on new features. Taking on less work helps you to get more done over the long haul. Teams should try to prevent getting into another technical debt while addressing and paying off the current one.

There’s no good time to fix technical debt than now even though it might frustrate business stakeholders who might see a disruption in the roadmap plan. It should be a high priority for teams. The longer you hold on to technical debt, the more expensive it becomes. This is why it’s crucial to take some time up front to make thoughtful decisions about your code structure and implementation when you’re starting a new project. If you take on too much at once, it will make things harder down the road. After you’ve released your app on the market, don’t completely rip out the old code just because you’ve discovered there are bugs in it. Starting a brand new project from scratch isn’t the right solution, because it won’t allow you to fix bugs and make improvements.

 

How do you make sure you don’t get into Technical debt again?

You don’t want the debt collector to come knocking at your door again so how do you ensure that? Well, follow these steps:

1. Pay as you go: Refuse to go into debt and only spend what you can afford.
2. Use proper conventions when building product: Write technical specification, estimates and time frames needed for implementation during the software development process. You need to plan and communicate clearly. Also, practice the rules of clean code to improve the quality of your code. The rules include:

• Code coverage on automated testing: Code coverage tells you how much of your code has been tested. This is a great metric for getting all the bugs out of your code before you release it. Apart from catching bugs in new features, it also guards against regressions and ensures that older, unchanging parts of the code also work as expected.
• Proper commenting: The comments should explain why you’re making a change to a code. They should be brief and relevant, and used generously, but not too much. 
• Naming conventions: Use descriptive and unambiguous variable names, function names and class names for maintenance purposes. If you’re working in a team, it is important to create standards for naming conventions. To create quality software, always think about what your code will look like a year from now. What will they need to know about the functions and classes that you’re writing down? How will they be able to easily make changes or modifications to your code? Preferably they should be able to answer these questions just by simply looking at the code.
• Documentation: Insufficient and outdated documentation is one of the biggest causes of technical debt. It’s advisable to update your documentation as you refactor and add it to your code. Write unit tests and follow the “once and only once” rule while at it. It makes the code understandable and brings visibility.

3. Plan technical debt payments into the roadmap: Teams should plan to have 15-20% of their time focused on paying back debt. Product and Engineering managers need to factor in tasks like documentation, refactoring, and testing into their cycle planning.