Technical Debt Is like a Tetris Game
Technical debt, legacy code… if you’re a professional software developer you must have come across those terms, and even across some code that embodies them.
But as a professional software developer, you also have to interact with people that don’t know your code. And sometimes, you have to convince these people that you need to invest in refactoring in order to improve the quality of a piece of code in order to keep working with it.
Those people include your PO or whatever business people make the requirements, your project manager, your boss, and so on.
Here is an analogy that pretty much everyone can relate to: a Tetris game!
The only reference I could find of this analogy is on Colin O’Dell’s blog. Colin’s post is interesting and focuses on the point of view of a developer, to approach a codebase. I think that what makes this analogy so great is also that anyone can understand it. This is on this aspect that we’re going to focus here.
Technical debt
Before getting into the analogy of technical debt with a Tetris game, let’s agree on what we call technical debt.
Technical debt consists in performing a fix or development in a quick and dirty way because it takes less time, even though it will make the code harder to work with in the long term. A cleaner solution would take longer to perform right now, but would have eased future developments.
This is called “debt” because it is comparable to financial debt: if you want to keep working with the concerned code, one day or the other you will need to pay it back by developing the clean solution. And the later you pay it back, the harder it will be, because the code will have grown in complexity in the meantime. This strengthens the analogy with financial debt, that builds up in time with interest.
Technical debt is not a bad thing in itself, as long as it is under control. If you have a good reason to save time on a development (for example to ship a minimal viable product), and if you have a plan to pay it back, technical debt can be beneficial. This aspect is also comparable to financial debt.
But technical debt becomes a problem when it gets out of control. Accumulating technical debt consists in piling up hacks on a piece of code, making it harder and harder to maintain. Every incremental change requires an intense reflexion and is more and more likely to cause regressions.
With too much technical debt, at some point the code can’t evolve any more. And if you really need to make the code evolve, for business reasons for example… then you have a problem.
To back out from such a situation, one way is to invest in refactoring, to undo the hacks and get a clean structure back into the code. This allows to make the code manageable again. But refactoring can take time.
From a developer’s perspective, all this sounds very logical. But from the perspective of someone that doesn’t know the state of the code, and doesn’t realize the need for refactoring, the situation might not be so simple to understand.
And if that someone has the power to grant you the time and budget resources to make your refactoring, then they have to understand.
This is when you can talk to them about Tetris.
The Tetris analogy
At the beginning of a Tetris game, you start with an empty game. It’s like the very beginning of a coding project when there is nothing yet.
Then blocks start to fall down. The way you position each block has an impact on the rest of the game. If you place blocks around without much reflexion, letting holes slip in, you’re making life harder for the rest of the game. And if you manage to build a clean, compact structure, then it will be more manageable later in the game.
The analogy with technical debt is that each new fix or development is like a new block coming in, which you need to integrate with the existing code. If you hack it in a quick and dirty way, it’s like leaving holes in the Tetris structure: you’re making life more difficult down the line.
And if you take the time to design a clean solution to integrate the fix or development, it’s like making sure you leave few holes in the Tetris game. This is less easy to achieve but it pays off in the long run.
The goal of a Tetris game is not to always have a flat structure though. It’s ok if it builds up a bit, as long as you have a plan to reduce it later. Like leaving the space for a vertical bar to slide in and clear out four rows at a time, with such a pleasant feeling:
Even if you leave a few holes in, it’s ok if you manage to have compact rows above them that will clear out and allow to fill the holes later. This is similar to technical debt, that is ok to build up if it’s under control and you have a plan to pay it back later.
How the Tetris analogy can help
What makes the Tetris analogy interesting is that anyone can relate to it, even people that are not developers or that don’t realize the state of the code.
If you’re asked to make a fix that will compromise the quality of your code, you can explain that it’s like placing a Tetris block at the wrong position. You can do it, and if you’re not too far into the game you won’t lose right now.
But blocks sticking out will make your life more difficult whenever you have to deal with that code again. This means that future developments will take more time, and are more likely to cause regressions.
After piling up hacks on the same piece of code, at some point it becomes unmanageable. And when someone asks you do keep adding features to this piece of code, you can explain to them that it is like a Tetris game filled up to the top. Because of the badly handled debt in the past, you can’t make any new block fit in.
At this point the only way to move forward is to go back in time (which you can’t do in a real Tetris game) to simplify the code with a refactoring.
I’ve tested the Tetris analogy with my PO at work, and he found it pretty clear to understand. If you try this at work too, let me know in a comment how your non-tech people reacted to The Tetris analogy, and if it helped you!
Don't want to miss out ? Follow:
Share this post!
