What is technical debt
There is a theory that says that the code becomes a legacy with the first commit. You can agree with it or disagree. But the fact is that the more code we have, the bigger the probability that we will have to deal with the technical debt.
What is the technical debt? It’s called like this for two reasons.
It’s a debt
A debt that we take consciously — like a bank loan. We borrow money, use it and then have to give it back with interests. Otherwise, the debt grows with time. The longer we have the debt, the bigger it will be at the end and still, we will have to pay it. And by us, I don’t mean only developers. Sometimes it’s the client because work takes longer, sometimes it’s the users that need to use the product. The payment comes in different ways but it always comes.
It’s technical
Not technological as it’s not connected only with technology. Technical debt is connected with the process, the people, the company that is part of the technology as well. It also refers to the way we write code, how we approach the development of the product. What I mean is that the existence of the technical debt is not only developers’ fault, it’s also project manager’s fault and the fault of the entire company.
Now that we know that we are all to blame, let’s take a look at which negligence is especially friendly to technical debt. The list is long.
- Bad quality code — no style guides
- Lack of automated tests
- Lack of manual tests
- Procrastination
- Imprecise requirements
- Wrong technology, not well adjusted to the requirements
- Passive perfectionism — improving the code to the extent that it is never ready.
Three types of technical debt
There are three types of technical debt. The division is purely theoretical but it helps to identify the debt and fight it. Probably looking at some of your past projects you will see that the debt comes in threes and probably you will be able to identify all three types in a single project.
Native technical debt
This one is caused by chaos in the code, chaos in the team, incompetency, choosing the cheapest solutions and bad engineering practices.
How to deal with native technical debt?
The more we learn the bigger the possibility that the debt will not happen. Solid processes, internal style guides, code reviews and everything else that helps us build a good quality code and a good quality craftsmanship.
Inevitable technical debt
Even though we do everything as we are supposed to do, sometimes we will face things we were not able to predict. A graceful example would be the changes in the requirements at the end of the project, which may cause rewriting, overwriting, changing parts of the already prepared code.
How to deal with inevitable technical debt?
We can’t. It’s unpredictable. But we can work with it when it happens. For example, if the project architecture needs to be changed because of a serious change of the requirements, it needs to be thought through and well planned.
Strategic technical debt
The worst of them all because it is taken consciously. We know that the decisions we make will have very serious consequences, but we still find a good reason to make them. Shortcuts force adjustments which (added one to the other) create the technical debt in the project. Choosing temporary solutions, lack of proper testing and saving on technologies are only a couple of examples that can cause very serious problems.
Why is strategic debt so dangerous? It’s because it causes many, many problems later on. It can work at the moment that you implement the solution, but you have a 100% certainty that later on there will be long-term consequences such as longer development time for new features or more expensive solutions. Unfortunately, strategic debt is what clients might underestimate very often and simply be unaware of the future consequences.
How to deal with strategic technical debt?
One of the ways is to add a by the book solution to the backlog the moment we take the shortcut and implement it as planned. It requires strength and good negotiation skills from the project manager but is definitely worth the effort. Another way is to constantly educate the client about the consequences and cost (in money) of the strategic debt. Believe me — money speaks to a lot of minds.
Summary
Long story short, you need to always be aware of the technical debt, never underestimate it and deal with it as soon as you become aware of it. Taking care of the technical debt takes a lot of courage from all sides but it definitely pays off in the future.
