Have you ever heard technical debt? It is a buzzword in the IT, and something tech companies like Google or Microsoft love to talk about. You should really try to understand it because if you do you will create better software. So, in this post, we will explain exactly what is technical debt and why it matters when creating an application.
What is Technical Debt?
Maybe you are not familiar with technical debt, but you know what debt is. You borrow money and repay them in the future. You get some money now, so your present purchasing power increases, but you will have to return them later.
Thus, you are not really borrowing from a bank: you are borrowing from your future self. In fact, by taking a debt you will have now more money to spend than you actually make. Yet, in the future, you will have less money to spend than you actually make (because you have to use some of your income to repay the debt).
Technical debt is just like any other type of debt, except it doesn’t involve money. Not directly at least. Instead, it involves work.
With technical debt, you borrow work from your future self. You have to do less work now, but you will have to do more work later.
Yes, in case you are wondering, it sounds a lot like procrastination, and to some extent it is. And, yes, technical debt is a bad thing to have.
How is Technical Debt made?
We are not talking about simple procrastination. In fact, with simple procrastination, you simply avoid doing something to do that eventually. So, not only you do less now, but you also get fewer results now.
Imagine you have to create a calendar widget, the ones that allow you to pick up a date on a website instead of writing it. If you decide to not do it just yet, that’s procrastination. You have to do less work now because you use only a text field, but you also get fewer results (you don’t get the widget).
That’s not technical debt, because it does not create more work in the future. The work is just the same (creating the widget), you just postponed it. That’s keeping things simple which is the best thing to do most of the time.
Technical debt happens when you try to cheat the game, try to get ahead of yourself. It happens when you still develop that widget, but you do it too fast and skip important parts.
For, example, you could try to get to the results faster by:
- Not writing documentation
- Writing the code as is, and then not spending time to review it
- Not writing tests
- Jumping right into the code, without making architectural considerations first
All of those are bad things to do! They generate technical debt because they create more work in the future. In fact, if you create bad software now, you will have to modify that eventually. When you have to do that, it will be extremely painful. And that’s not only because you may have a hard time finding the exact place where you have to do the changes. That’s because any change may break everything.
Why All of This Matters?
All of this matters because technical debt can grow over time. It can pile up and be quite nasty. If you don’t manage your technical debt properly, you will have too much of it eventually.
What does it mean to have too much technical debt? It means you are virtually unable to modify your application, or even add new features. It simply takes too much time, and the risk of breaking everything is so high that you don’t want to touch it anymore. You have lost, game over. At this point, the best thing to do is start again from scratch.
However, when you do realize it is time to start over, you have to throw away all the code you have written up to that point. That’s what banks call default on a debt. You are unable to repay anymore, so you have to give up the little you were left with.
Now, technical debt is not necessarily so bad as long as you manage it properly. You must fix it quickly, reduce it and avoid it piles up. A good approach to do that is by working in Agile Sprints, and before closing each sprint you ensure you haven’t left any loose ends (e.g. you still need to write the docs).
With this approach, you can benefit from little technical debt, for example for testing things straight away, without risking too much.
In case you want to go down this road, let me pave it for you with a few resources:
- A key concept of Agile: What is a User Story?
- How to use a Kanban board to better plan your work
- A Tutorial on Kanban best practices
- How to apply Agile with DevOps in your software project
The Most Precious Piece of Advice
Now you grasp the idea, and you even get why it matters. Now, maybe not today, maybe not tomorrow, but one day you will think:
But I will never have to touch this code again in my life…
Don’t. Don’t make that mistake. You will have to touch that code again, even if you don’t realize that now. So do not get technical debt because you think you will outsmart the system. Most probably, you won’t, and you will blame your past self.
Instead, be a purist, like a Zen Monk. Write good and reliable code all the time, even when nobody is watching.
