Comment by dvfjsdhgfv
7 years ago
I think your comment reflects well the mindset difference between programmers working for startups and the rest of the world. When you're working on a system that's supposed to last for decades, you think in a completely different way.
>When you're working on a system that's supposed to last for decades, you think in a completely different way.
Some of the worst systems I've seen were those designed to "last for decades".
https://en.wikipedia.org/wiki/Second-system_effect
I was thinking about the other end of the spectrum like Voyager probes.
That takes a whole other approach yes.
But that's also not the same as "to last decades". A lot of the old space code was used and dismissed after a few years / missions.
The key difference is not "future-proofing" but "proofing" in general: the code had to be absolutely robust.
https://www.fastcompany.com/28121/they-write-right-stuff
Code written on/for a space probe is certain the 0.01% in terms of safety and robustness required.
Do general purpose line of business programs last for decades though? I suspect that the ones that have lasted have gone through enough iterations to the point of being unrecognizable to original authors...
Not just LoB, also EDA software, specialized industrial and automotive testing / HiL software and general equipment control software where you can never start from clean slate because there's existing hardware in old production lines with a 10 year support contract.
I.e. basically everything non-web/non-mobile has a higher lifetime.
Someone on HN said recently that business software is like another employee. You wouldn't fire a senior with lots of domain experience, on whom critical processes are dependent, just because it's time to freshen things up.
Even if it lasts for 5 years, that is still a long time to maintain and so the advice in the book is solid. As a business, you may want or need it to last longer.