We all know what debt is. You probably have some debt of your own, but tech debt is a little bit different, and AwesomeAPI is here to explain everything. What is tech debt and how do you avoid it? We’ve got some tips to provide and some knowledge to drop. Keep reading. It’s going to be awesome.
What is Tech Debt?
Tech debt is the extra cost (both in time and money) incurred when you have to rework your platform because you used an easy solution that may not do everything you need in the final product.
To use a metaphor, imagine you are building a house, and you have to see what the first floor will look like before you are comfortable continuing with the project. Instead of pouring the foundation, you might build a temporary foundation instead. Now, this might never happen in reality, but in software, it happens all the time.
Tech debt even accumulates interest just like normal debt. Ignoring changes that need to be made will make your project more unwieldy the longer you wait, and ultimately making the change will also become harder as more and more dependencies build up in your code base.
Is Tech Debt Inevitable?
Unfortunately, tech debt is inevitable for any tech project of scale. When you are prototyping or building out, you are going to use quick, easy, and cheap solutions to get up and running so you can test your own tech.
On top of that, when you start a tech project, you don’t always know where that project is going to end up. AwesomeAPI itself has shifted in focus, and you might too. We went from being a custom solution to a unified platform. You can bet that this transition led to our own fair share of tech debt.
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”Ward Cunningham, Developer of the First Wiki
Tips For Minimizing Tech Debt
Remember, tech debt isn’t always a bad thing. Sometimes it’s necessary to get going fast so you can iterate or bring a simplified version of your product to market. Just like with business debt, you often have to incur tech debt to stay afloat. Regardless, there are things you can do to minimize tech debt:
- Remove Tech Debt Early—Even when you are working towards your minimum viable product, you should be thinking about that tech debt. Go back to the house metaphor. Are you about to add a new floor to the house? Then perhaps you should revisit the foundation first. It’s only going to be harder once you have that extra floor on.
- Build it Yourself—Some problems you will have to solve yourself, but it can be tempting to go with a quick off-the-shelf solution to get to market. When you can, build it yourself. When you can’t, pick a solution that aligns with where you want to be and not just with where you are.
- Weigh Your Options—It’s easy to go with the easiest or cheapest solution, but instead, you should focus on the best. Write forward-thinking code and pick a forward-thinking solution. Even if you have to be fast, ensure that you are still being smart too.
- Avoid Foundational Tech Debt—Unlike most business debt, which tends to be front-loaded, the best tech debt comes later. Instead of comprising the foundation of your tech, it enhances functionality, or in the case of AwesomeAPI, lets you communicate with other systems. Some foundational debt may be necessary or even ideal when prototyping, but root it out sooner rather than later.
- Define Your Platform—Many projects start with unclear goals or definitions. Ensure that your project is as defined as possible before you start. This can often mean having developers work on other projects until things are properly planned and designed.
- Document—You can think of proper documentation as incurring a lower interest rate on your tech debt. Lack of documentation is a debt on its own especially if you plan to scale your software team with your project.
Read More: Best Practices for API Documentation