What is it?
Tech Debt, Technical Debt, or Technical Debt is a concept in software development that reflects the cost of redoing things caused by choosing a solution that is believed to be "easier" or "faster" instead of solving problems using the best solution that we can implement at that time.
It is also called Debt because it works in the same way as financial debt, in the sense that it can be helpful to buy a house that you cannot buy with cash, but that purchase earns interest. Many interests can ruin your economy and make you lose the same house. Debts can be used in our favor if we pay interest correctly.
Some tips following the analogy:
- Do not acquire debts that you cannot pay.
- Pay your debts early and continuously.
- Do not go into debt for unnecessary things.
How is it created?
There are many ways to accumulate Technical Debt. Here are some common examples:
- "There is no time" to do something the right way.
- “We don't have the resources” to do something the right way.
- We don't have the knowledge to do something the right way.
- We don't want to do something the right way.
- We don't have the authority to do something the right way.
- Previous technical debt makes it more difficult to do something the right way.
- Situations beyond our control.
Let's look at the above points one by one.
"There is no time" to do something the right way.
This is false 99% of the time. We don't know how long it would take to make the feature well done, and we randomly assume it should take longer than a badly done feature. In my experience, I could say that in most cases, a senior developer can make a feature well done in half the time or less than a junior developer, even when the junior developer does it poorly (and no, I'm not implying that a junior developer will necessarily write bad code, it's just an example).
“We don't have the resources” to do something the right way.
If the resources refer to time, then the previous paragraph applies. If the resources refer to money, it could be an understandable reason. You may not have enough resources to hire experienced people and stick with the skills of the people you manage to hire. Here technical debt can be mitigated in various ways, such as by training people, motivating them to learn new things, getting mentors, hiring a few experienced people to help others grow professionally, etc.
We don't have the knowledge to do something the right way.
This is understandable in the present, but in the same way, we should all look for how to train ourselves to learn the things we do not know today.
We don't want to do something the right way.
This is inexcusable. People who think and work this way should not be part of any technology company, much less Beek.
We don't have the authority to do something the right way.
We must try to explain to people with authority the importance of reducing and/or not generating technical debt. Most likely, if we know how to explain ourselves, they will help us to do things well. In case we do not succeed, we must try and keep trying. If, in the end, there is no way for the people in the leadership to understand that this is a problem and they have no valid reason not to attack the technical debt, maybe it is time to look for another company because the leadership is broken and it is part of the problem.
Previous technical debt makes it more difficult to do something the right way.
This can be avoided if we generate as little technical debt as possible and if we pay the existing technical debt little by little.
Situations beyond our control
There are few times when even doing everything right, we will have to pay the technical debt. Some library we use no longer receives maintenance, and we must migrate to another. A new version of the framework we use came out, and it has breaking changes, etc. The important thing here is not to let it accumulate.
Does technical debt mean I have a bad product?
Contrary to what it might seem, these things are unrelated, which is why all the problems, such as hasty deadlines, the acceptance of unnecessary technical debt, etc., are born.
Bad code might be lucky enough to produce a good product, one that does what it's meant to do today (even if it doesn't scale tomorrow), and good code might implement a bad product vision and get nowhere.
So why worry about technical debt?
Well, because it makes us slower and less productive over time. Attacking and preventing technical debt is the logical response if you are interested in spending less and generating more value faster as a company.
Technical Debt vs Money
Technical Debt vs Time
Oh, and as if that weren't enough to be slower and lose money, how does losing talent sound?
Oh, and let's remember that many companies have gone bankrupt due to too much technical debt, and only a few have managed to survive (with the help of a lot of money). Twitter and LinkedIn suffered greatly from accumulated technical debt and had to rewrite part of their codebase.
Does the company called Tio Networks ring a bell (if it doesn't ring a bell, that's exactly the point)? A company that had some technical debt problems? And that they suspended activities and never resumed them again?