Software Rot

Mindset of software as limits to end users and management. Use software expiration dates (use feature flags to force it if you want). I have asked for this many times before in other places and in summary the idea is the same as any physical product. Wood rots, iron rusts, software degrades (https://en.wikipedia.org/wiki/Software_rot#Active_rot) so much faster when you think about dependencies (which all new software has) so we stamp a guarantee of some time limit on each release and after that it is written off and we build new or charge for extended support and mark it as obsolete.

This mindset gets people to think and plan in an informed and proactive way that they can no longer out infinite sand castle of software will remain there for you to build on. Long Term Support or LTS in Open Source projects like nodejs/.net core are what I am thinking of here.

Venice is sinking on its rotten wood pillars and while we can have the wonderful cathedral of Piazza San Marco, everyone who goes knows it is temporary wonder that floats and will be gone soon. Adopting this strategy encourages rewrites or configurations to be leaner and cleaner as requirements are constantly re – evaluated and expressed.

Stock trader software is also rewritten about every 2 years as well another example to give to executives. We don’t want to be dependent on COBOL code like banks are because they stopped trying or like New Jersey COBOL government code fiasco last year in 2020.

Expansion on my previous post of code rot

Code rot

Code rots as soon as you write it. Code rots faster than wood and doesn’t preserve its shape like a rusting metal like iron. People think that it is static and preserved because the text the wrote isn’t changing, but that is wrong and misleading because everything around it is

Empty SpaceRobin Michael