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

mostlysignssomeportents:

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).

https://boingboing.net/2019/05/08/tech-debt-shear.html