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.
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.
Source: Technical Debt Is like a Tetris Game, Jonathan Boccara, https://www.fluentcpp.com/2020/01/17/technical-debt-is-like-a-tetris-game/