Terminology: Technical Debt
Photo by Anton Bielousovt
I realize that the idea of technical debt is already a metaphor, but I’ve found that it often comes with a stigma that bad decisions were made in the past, which is not always the case. And people sometimes don’t understand the severity of the technical debt that is accumulating in their systems. It's not just developers who should care about technical debt.
As another way of explaining technical debt, I’ve been thinking about the game Twister. In each turn of the game, the player has to make a decision about how to place his hands or feet on the colored dot that the spinner has indicated. Similarly, developers decide the architecture/design to use as they implement features. Early on in the game and in a new software project, these decisions are relatively simple. You tell the player to put his right-hand on red, and he can do this fairly easily.
But as the game continues, the decisions become more difficult. The player is contorted on the board, making his position more difficult to move from. His previous decisions were not necessarily bad, but it is challenging to make the next move. Similarly in software, the architecture and designs used were not necessarily wrong, but they do not enable delivery of future features. For that reason, the player/developers must “refactor” the state they are in.
And if the position that the player finds himself in does not get refactored to a more stable state, then he eventually falls down and loses. Game over. We do not want this for our software systems either—it is the point where we declare technical bankruptcy. Pay off technical debt early.
