Food For Thought | Technical Debt is Forever

Have you ever heard of the term Technical Debt? As a team have you ever placed 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.

What is 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. To be honest.., it rarely happens and remains forever. Let’s dive into what technical debt is. Wikipedia 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 and how it affects your team and solution
Technical Debt and how it affects your team and solution

Technical Debt blocks you and your team from quickly adding new functionality. 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 to get projects moving.

Bringing MVPs live earlier with Technical Debt can help determine the product/market fit sooner. It also helps to quickly receive feedback and you can meet the customer requirements faster. This is called Planned Technical Debt. In the end, if the solution delivers the main requirement, the customer is happy!

Next to this, there is also the concept of Inadvertent Technical Debt, which occurs when code is brought into production while engineers don’t fully understand the requirements, code review did not happen, or management is pushing. This  is a bigger problem since the main requirements are not delivered and the customer is not happy. Secondly, as it was not expected, there is no time planned soon to solve it.

"Although it does not add any business value at that moment, it will save you from problems afterwards."

In both cases of Technical Debt, planned or inadvertent, the pain comes afterwards. Experience teaches us that once it is brought into production, the focus on resolving it is gone. At that moment other requirements will be prioritized.

*for more information on types of technical debt see [1], [2], [3]

your team and technical debt?

In the 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 your team. 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 large amounts 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, it will never be paid off and remains forever.

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

Sometimes a dedicated team continuously improves the existing solutions. However, most of the time you’ll see solutioning teams that pay off their own debt. This is normal in smaller organizations. Make sure to have senior engineers structurally improve the codebase as they have extensive knowledge of the business domain and the current solution.

It is essential to have strong communication between the teams to keep everything aligned.

"It is essential to have strong communication between the teams to keep everything aligned."

In case solutioning teams remove their own debt, it is key to allocate dedicated time within 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.

By encouraging your team to pick up Technical Debt every sprint, your team gets used to implementing improvements more often. They will become better in code refactoring and eventually can prevent it from entering into new projects. 

"You'll make sure to always pick up and improve the technical debt, instead of letting it be as is."

Conclusion

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 resolve it. Otherwise, it will remain forever and possibly degrade your awesome software.

Make sure to improve your team and solution continuously by allocating dedicated time for solving your Technical Debt. Although it does not add any business value directly, it will save you from problems in the future. It sounds simple, but it is hard sometimes, trust me!

Do you want to prevent Technical Debt? make sure you adhere to proper architectural guidelines

Let us know what you think of this!

Reach out to us: info@foodforanalytics.com

Or join us: workatffa.com

about the author

Benito van Breugel
Senior Data & Analytics Consultant

“Understanding the business is key”

Benito van Breugel is a pragmatic and business focused Data and Analytics consultant. Benito is great in explaining complex technical matters in an understandable manner to business and vice versa. Benito has a strong background in econometrics and in building core end-to-end Microsoft Data solutions. Over the past few years he excelled in roles as a data-engineer, solutions-architect and is currently driving various cloud initiatives within Food For Analytics. 

By sharing his experience and passion on everything data, Benito will always be challenging the business-teams within your organization to become even more data-minded.