3 ms·

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works o

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more magical or even just more different than other code at the company, which makes it harder for new maintainers to step in. Add to this that not all code has all the test coverage and monitoring it should... It shouldn't be too surprising there's always some incentives to kill, change, or otherwise stop supporting what we shipped 5 years ago.

codeflo 1y ago
That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.
- BobaFloutist 1y ago
  If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essential and less painful to get wrong than your average bridge or bus.
  - tracker1 1y ago
    It's like the difference between building a Bird house, Dog house, people house, mansion, large building and a sky scraper... it's different levels of planning, preparation and logistics involved. A lot of software can (or at least should) be done at the bird or dog house level... pretty easy to replace.
- dgoldstein0 1y ago
  But why are those teams incentivized to exist? For roads, brushes, wastewater, sewer, electricity - it's because these things are public utilities and ultimately there is accountability - from local government at least - that some of these things need to happen, and money is set aside specifically for it. An engineer can inspect a bridge and find cracks. They can inspect a water pipe and find rust or leaks. It's much harder to see software showing lines of wear and tear, because most software problems are hard to observe and buried in the realities of Turing completeness making it hard to actually guarantee there aren't bugs; software is often easy to dismiss as good enough until it starts completely failing us. A bridge is done when all the parts are in place and connected together. Much software is never really done because - it's rare to pay until we have nothing more to refactor - the software can only be as done as the requirements are detailed; if new details come to light or worse, change entirely, the software that previously looked done may not be. That would be insane for a bridge or road.
vdupras 1y ago
Maybe it's a documentation problem? It seems to me that for a piece of software to be considered good, one has to be able to grok how it works internally without having written it.
- croemer 1y ago
  Not per Naur, in his seminal "Programming as Theory Building" he claims that documentation doesn't replace the mental model that he original authors had developed: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

codeflo 1y ago

That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.

BobaFloutist 1y ago
If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essential and less painful to get wrong than your average bridge or bus.
- tracker1 1y ago
  It's like the difference between building a Bird house, Dog house, people house, mansion, large building and a sky scraper... it's different levels of planning, preparation and logistics involved. A lot of software can (or at least should) be done at the bird or dog house level... pretty easy to replace.
dgoldstein0 1y ago
But why are those teams incentivized to exist? For roads, brushes, wastewater, sewer, electricity - it's because these things are public utilities and ultimately there is accountability - from local government at least - that some of these things need to happen, and money is set aside specifically for it. An engineer can inspect a bridge and find cracks. They can inspect a water pipe and find rust or leaks. It's much harder to see software showing lines of wear and tear, because most software problems are hard to observe and buried in the realities of Turing completeness making it hard to actually guarantee there aren't bugs; software is often easy to dismiss as good enough until it starts completely failing us. A bridge is done when all the parts are in place and connected together. Much software is never really done because - it's rare to pay until we have nothing more to refactor - the software can only be as done as the requirements are detailed; if new details come to light or worse, change entirely, the software that previously looked done may not be. That would be insane for a bridge or road.

vdupras 1y ago

Maybe it's a documentation problem? It seems to me that for a piece of software to be considered good, one has to be able to grok how it works internally without having written it.

croemer 1y ago
Not per Naur, in his seminal "Programming as Theory Building" he claims that documentation doesn't replace the mental model that he original authors had developed: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf