alkaline9

Some years back, I was a senior software engineer and I was becoming less productive, because I was afraid I might produce code that wasn't judged as senior-software-engineer quality. My manager started to get a little concerned. One day I realized that If I just got stuff done that mattered, the judgment of other people about my code quality really wouldn't matter. Ever since then, I have just written the code I thought needed to be written, without a care about how anyone might look down on it, regardless of whether they are a higher or lower level than me. I have gotten consistently good ratings with this approach.

Later I learned about an experiment that compared different groups of photography students, and the ones that were instructed to produce more pictures without regard to quality actually produced better pictures in the end than groups who were told to produce 1 perfect picture. Produce a lot and the quality will naturally come! https://jamesclear.com/repetitions

Perhaps I should amend my statement: "such that they would fall apart as soon as we stop putting energy into maintaining hardware and software dependencies"

Software assumes that there exists specific hardware, operating systems, and services underlying it to keep operating. If you try to turn on a 5-year old android phone, you will find that your apps probably don't work (because of service changes for example), but also can't be upgraded because the latest versions don't work with your old version of android, and your android can't be upgraded because the latest versions don't have device drivers for your phone hardware. You're SOL.

So, to have a 100-year software, you need commodity components from the top down, that continue to be maintained for the same length of time. And it all probably needs to be 100% open source. Otherwise, you have perishable software.

No, it is asking people to design and test systems for the long-term. It would require establishing strong interfaces between components that will hold up when subcomponents are swapped out.

I think of it like a car where parts can be replaced if those parts have an issue, but the designs of the connectors stays the same, and replacements are available. A 100-year car isn't one that requires no maintenance for 100 years; it is one that can be maintained, and replacement parts can be acquired, and it will still continue working.

If a car depends on a remote server, such that the car stops operating when the remote server is shut down, then that car is perishable.

Perishable software is a huge problem - things keep operating only in dynamic equilibrium, such that they would fall apart as soon as we stop putting energy into fixing flaws.

I have been thinking for years that as a society, we need 100-year products. It would be a global good to counteract the local incentives for producing perishable software.

However, over time I have realized that there are legitimately unforeseen circumstances that come up - for example, the general realization of the need for stricter security around logins (e.g. two-factor authentication). Maybe a 10 year time window is realistic for now.

In the meantime, requiring expiration days would go a long way towards calling out how perishable our devices and software are.