3 ms·

It's actually the assumptions around longevity that need to be examined. Software is not like etching perfect museum-pieces. It is the union of the world that

by platz 7y ago

It's actually the assumptions around longevity that need to be examined. 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

dwohnitmok 7y ago
I believe this is the most coherent counterargument to the article's point. Given how often software is rewritten and requirements evolve, how much does it make sense to target longevity? And when I say rewritten I don't just mean big-bang rewrites-from-scratch, I also include Ship of Theseus rewrites where over time everything gets rewritten one piece at a time. 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.
- hejeii9 7y ago
  It doesn’t and the only reason we’ve done it this way is because software distribution at scale had to be on physical medium of one sort or another. 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
ryl00 7y ago
It depends on what you're working on. I'm in the simulation area at an engineering company, and we've got plenty of Fortran code that dates back to the '70s that's still just fine. A little maintenance to work on removing deprecated syntax, a little work to replace common blocks with a more decoupled design, and we're probably good for decades more use. And if we can't get to that maintenance work right now, the strong backwards-compatibility of Fortran will have our back until the next opportunity. :)
- safety-third 7y ago
  Same here. We are stuck in Watcom F77 right now due to using some old extensions. We are in the middle of eliminating control characters from format statements so we can finally upgrade to new compiler.

by platz 7y ago

dwohnitmok 7y ago

I believe this is the most coherent counterargument to the article's point. Given how often software is rewritten and requirements evolve, how much does it make sense to target longevity? And when I say rewritten I don't just mean big-bang rewrites-from-scratch, I also include Ship of Theseus rewrites where over time everything gets rewritten one piece at a time. 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.

hejeii9 7y ago
It doesn’t and the only reason we’ve done it this way is because software distribution at scale had to be on physical medium of one sort or another. 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

ryl00 7y ago

It depends on what you're working on. I'm in the simulation area at an engineering company, and we've got plenty of Fortran code that dates back to the '70s that's still just fine. A little maintenance to work on removing deprecated syntax, a little work to replace common blocks with a more decoupled design, and we're probably good for decades more use. And if we can't get to that maintenance work right now, the strong backwards-compatibility of Fortran will have our back until the next opportunity. :)

safety-third 7y ago
Same here. We are stuck in Watcom F77 right now due to using some old extensions. We are in the middle of eliminating control characters from format statements so we can finally upgrade to new compiler.