Technical Debt

In my life, I worked in different companies, different projects, like e-learning, e-commerce, basic administrative systems, landing pages, … And in every project I had worked, as a developer, team leader or manager, I had to deal with technical debt, because even if anyone wants to talk about it and assume that your project has technical debts, all projects have it. The only way to not have any technical debt is to not have any code written in your codebase, that's the truth.

Ok, all projects have it, but how to deal with it? And how to find it in your codebase? After we made the first step that is assume you have some technical debts in your code, answer those two questions are the next step to deal with it in a good way. But first, to help the understanding, let's define a little more on what is a technical debt.

Bad code

Technical debt can be a bad code that some developer, or even you, wrote in your codebase, and even if we think to never do that, I can think at least in two reasonable scenarios where it can happen:

• The developer did not have the knowledge to write a better code
• The developer did not have enough time to write a better code

As a team leader or even as a more experienced developer, you can help in those two scenarios. For example, in the first one you can define a code review process to avoid the code reach the master branch and use the code review to teach and help the developer to develop his skills, you can improve your onboard to improve developer skills before he start to work on your teams and you can create training sessions to keep your team evolving its skills always.

The same way, you can think about processes and practices that you can add to your team or change in your company, for the second scenario.

Changes in the scenario

But technical debt isn't always caused by bad code, sometimes even if you had written the best code any developer could do, the scenarios of the company, the product, or the customers can change and make your code not good to it anymore. For example, you can write a code that is able to send 10 thousand emails per minute, and that is a very good performance for email sending. But with the company scale and got more clients, sometime you may discover that you now need to send 30 thousand emails per minute, and it is not possible with the code you had written in the past to send 10 thousand per minute. That is a technical debt too.

How to deal with it?

Recently, I read this post from Eric Higgins and I think that his analogy of technical debt with tetris is perfect. You have to be always dealing with technical debt, you need to always be solving some technical debt, because you and your team are always developing new technical debts, that can be discovered some months or some years in the future. Having technical debt in your code is not a problem, the issue is when you do not know what technical debt you have, how big it is and when you have to deal with it.

So, what we are trying to do here at Zygo and I think that can be a good way to deal with it, is to accept that you and your team will be building new technical debts, but keep noted about all debt you already know you have, and keep an eye to discover new debts as soon as possible. The goal is not to solve all technical debts as soon as possible, but have a clear understand of when and how you will solve each one. Using another analogy, to deal with technical debt is like a mountain climb, you will not be able to climb the biggest mountain for the first time, you have to start climbing a smaller one, and even in this smaller one, you need to have a strategy and do it step by step, one part at a time.