IEEE Software - The Pragmatic Designer: Garbage Collect Your Technical Debt
This column will be published in IEEE Software, The Pragmatic Designer column, September-October 2021, Vol 38, number 5.
ABSTRACT: The iterative process that a team follows is a bit like a garbage collection algorithm, and we can compare software development processes like we can any algorithm. A process can help developers do two things: clean up tech debt after it exists, or avoid creating it. When an iterative process does neither, tech debt buildup will lead to bankruptcy, so it is only suitable for projects with a short lifespan. A process that does both has the best chance at minimizing tech debt over a long lifespan. In particular, focusing on the system’s design will keep tech debt low.
There is a kind of design distortion that happens when a team chooses to build iteratively instead of looking at all the requirements at once. Ward Cunningham coined the term technical debt to describe those design distortions. By understanding the causes of tech debt and connecting them back to a team’s actions (or inactions), it’s possible to minimize the buildup of tech debt and keep a system healthy, indefinitely. The way to minimize tech debt is to view a software development process as an algorithm, consider several algorithms, and choose the right one for the circumstances.
However, most developers don’t think about their process as an algorithm, so let’s ease into the idea by looking at garbage collection algorithms. Watching tech debt build up on a project is a bit like watching a program allocate memory.
… to be posted in full once published …