Why "collapse" (not "rot") is the way to think about software problems

For decades, programmers have talked about the tendency of software to become less reliable over time as "rot," but Konrad Hinsen makes a compelling case that the right metaphor is "collapse," because the reason software degrades is that the ground underneath it (hardware, operating systems, libraries, programming languages) has shifted, like the earth moving under your house.

Building on this metaphor, Hinsen identifies strategies we use to keep our houses standing: building only on stable ground; building in reinforcements to counteract the expected degree of shaking; fixing the house after every quake, or giving up and rebuilding the house every time it falls down.

These strategies are of limited use to software developers, though: building in a risk-free environment means using systems that don't change, which severely limits your options (some large fraction of ATM transactions today loop through a system running COBOL!); we don't really know how to make software that remains reliable when its underlying substrates change; and rebuilding software from scratch over and over again only works for very trivial code.

Which really leaves us with only option 3: constant repairs.

I love this analysis but I wonder where "technology debt" fits in (the idea that you shave a corner or ignore a problem, then have to devote ever-larger amounts of resources to shoring up this weak spot, until, eventually, the amount of work needed to keep the thing running exceeds all available resources and it collapses).

As a first step, consider the time scale of change in your own project.