Food For Thought: Technical Debt is For Ever

By Benito V.

Have you ever heard of the term Technical Debt? Did you ever place a solution into production which was built as a Proof of Concept (POC) on a platform that was not finalized yet? In both situations you’ll end up with a solution that is not officially done and ready, but is built with technical debt.

Building something with technical debt is not a problem as long as it is removed, or improved, at a later moment in time. Well, to be honest, resolving technical debt rarely happens, resulting that your technical debt stays forever.

Let’s dive into what technical debt actually is. Wikipedia’s defines it as:

“The implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”

Technical debt blocks you from of quickly adding functionality in a robust, scalable, and flexible way. When implementing a POC or a Minimum Valuable Product (MVP) there is no shame in taking shortcuts. Technical debt is not necessarily a bad thing in order to get projects moving.

Bringing MVPs live earlier with technical debt can help determine the product/market fit sooner. Also it helps to quickly receive feedback and you are able to meet the customer requirements faster. This technical debt is also called planned technical debt. In the end, if the solution has technical debt, but delivers the main requirement of the consumer, the consumer is happy!

Next to this, there is also the version of inadvertent technical debt, which occurs when engineers don’t fully understand the requirements, and even by lack of code review and management steering the code is brought live. This type of debt is a bigger problem since the main requirements are not delivered and the consumer is not happy. Above all, since it was not expected, there is no time planned in the near future to solve that debt, unless other priorities are replanned or even skipped.?

In both cases of technical debt, planned or inadvertent, the pain of technical debt comes afterwards. Experience shows us that once technical debt is brought live, focus on improving the technical debt is gone. At this moment other implementations will be prioritized instead of taking time to remove the technical debt.

In case of teams with ongoing development, there is an increasing cost of “paying off the debt” in the future. The longer you wait, the more it will cost. If you wait too long the technical debt will pile up and causes projects to miss deadlines. It will become increasingly harder to?properly estimate how much effort is needed to pay off the debt. In some cases, the solution with a large amount of technical debt was not the POC or MVP, but the solution running in production. As long as the solution does not give an error and is running fine, the technical debt will never be paid off and stays forever.

Although there can be many reasons for introducing technical debt, it is more interesting to know how to address and cope with technical debt in your teams and solutions.

You sometimes see a dedicated technical debt team working on improving the current solutions, but most of the time you’ll see solutioning teams that remove their own debt, especially in smaller organizations. For this, make sure to have senior engineers that have great coding skills, knowledge of the business domain, and the current solution, so that they can improve the code. It is essential to have strong communication between the teams and engineers to keep the right requirements aligned.

In case solutioning teams remove their own debt, it is key to schedule dedicated time in the team to pick up this work. While working scrum, this can be a full sprint per certain period, or a dedicated number of scrum points per sprint. In both ways, you’ll make sure to always pick up and improve the technical debt, instead of letting it be as is. By encouraging your team to pick up technical debt every sprint, your team gets used to implement improvements more often. They will become better in code refactoring and eventually are able to prevent technical debt being created in new projects.?

Having technical debt in your solution is something that we all will encounter. At first thought, it is not that bad. However, you need to make it a habit to pay of technical debt. Otherwise, technical debt will remain forever and thereby possibly degrading your awesome software.

Make sure to improve your team and solution continuously and schedule dedicated time for solving the technical debt. Although it does not add any business value at that moment, it will save you from problems afterwards. It sounds simple, but it is hard sometimes, trust me!

Let us know what you think of this! Share, Like & Respond!