Software is not like etching perfect museum-pieces.
It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate
Software is not like etching perfect museum-pieces.
It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate
I don't have a good intuition for this. I think everyone has anecdotes of both sides; projects that were supposed to be throw-away code that lived on for decades and everyone is familiar with changing scope and requirements requiring changes to otherwise perfectly fine code.
Put another way, the longevity of code is only important to the extent that it still fulfills the needs of its users. Otherwise, as always if you can get away with it, the best code is no code.
Shipping updates used to mean literally shipping new hardware to be installed.
We’ve treated software like a literal thing to meet boxed software business sales expectations. Back in the day people sold things.
There are a number of different ways to build and distribute software that achieve the same level of results. We’ve just stuck to using the ones that traditional business models are willing to fund.
Apparently curve fitting for ephemeral finance growth is achieving literal economic gains. Or something. The epistemology of economics has diverged from the ontology, become less about material goods, more about information organization which is harder to value given as we say here, we curve away too fast and have to rewrite it, no one knows