4 ms·

What does rot even mean, in terms of software? As far as I can tell, he means "Why is complex software hard to change" which is a reasonable, though fairly eas

What does rot even mean, in terms of software? As far as I can tell, he means "Why is complex software hard to change" which is a reasonable, though fairly easy to answer, question. Software doesn't rot. New features or refactors screw it up. New needs or technologies may make it obsolete. But it doesn't rot, and people who talk that way are often busy-body rewriters who want to pitch the existing implementations, with all their Chesterton Fences[1], and begin anew. [1] http://www.chesterton.org/taking-a-fence-down/ http://www.chesterton.org/taking-a-fence-down/

nbouscal 10y ago
It rots in the sense that it becomes harder to change (or fix) over time, even if the code stays the same. This happens via loss of institutional knowledge as people forget how it works, loss of knowledge of the technologies used as they're replaced, etc. It's not just the complexity. Old code is usually harder to change than new code, even if they're equally complex.
- carsongross 10y ago
  That isn't rot. The metaphor doesn't make any sense. Software literally does not change. Except for the occasional cosmic ray, I can think of few things less appropriate to apply the term "rot" to.
  - jussaskin 10y ago
    Software doesn't exist in isolation. It interacts with its host OS, shared libraries, other programs, protocols, file formats and external systems. If it can't keep up then it effectively rots even though not a single byte of it has changed.
  - beat 10y ago
    It's a metaphor, not an equivalence. It doesn't even have to be in the same field, as long as the meaning is conveyed. Bit rot is an excellent metaphor, even though it's nothing like physical rot if you get pedantic about it.
  - nbouscal 10y ago
    You're the first person I've heard say that the metaphor doesn't make any sense; meanwhile, a lot of people regularly use it, which implies that it makes sense to them. You're welcome to not like the metaphor, but you don't really get to declare that it's objectively wrong… it's a metaphor.
cbd1984 10y ago
Changes in the environment screw it up, too. As an obvious case, if your software is screen-scraping a website and the website's layout changes, your software's just rotted even though your code hasn't changed one bit. Another example is software which interfaces with hardware: Swapping one specific piece of hardware out for "the same" hardware made by a different manufacturer can cause rot, because "the same" hardware isn't necessarily the same in every respect. If your software tickles it the right way, it can expose differences which can cause your software to fail in new and exciting ways. Nothing changed, yet everything's different. As you expand the universe of things your code has to interact with, this kind of change becomes inevitable. As always, the more points of attachment, the more potential for future pain.
ourmandave 10y ago
The American Chesterton Society logo had to be the inspiration for Buzz Killington. http://familyguy.wikia.com/wiki/Buzz_Killington http://familyguy.wikia.com/wiki/Buzz_Killington
wvenable 10y ago
> Software doesn't rot. On the face it, that's true. But the reality is that the environment that software runs in is constantly evolving and software that doesn't also change slowly starts working worse until it stops working entirely. We have plenty of software at my work that hasn't changed fundamentally in 10 years and can no longer be used. Lots of really old software requires equally unchanged old environments and old hardware and that hardware slowly rots too.
- johannes1234321 10y ago
  ... add to this that user expectations change. Applications not matching that feel rotted. Just look at websites from 10 years back to get an idea only on very surface levels.
akkartik 10y ago
I think you're taking the phrasing too literally. When we say software rots, we're not just talking about the bits that make up a program, but also its interface with its environment, and the knowledge about it in people's brains. Both those connections are indeed subject to drift/evaporation/entropy. The two failure modes you mentioned are symptoms of that underlying evaporation. I spend a lot of time thinking about this (http://akkartik.name/about http://akkartik.name/about), but lately I try to steer clear of metaphors, because they're so often clear in my mind but utterly opaque to someone else's. So, I don't care what we call it, as long as more people try to fix the problem.

nbouscal 10y ago

It rots in the sense that it becomes harder to change (or fix) over time, even if the code stays the same. This happens via loss of institutional knowledge as people forget how it works, loss of knowledge of the technologies used as they're replaced, etc. It's not just the complexity. Old code is usually harder to change than new code, even if they're equally complex.

carsongross 10y ago
That isn't rot. The metaphor doesn't make any sense. Software literally does not change. Except for the occasional cosmic ray, I can think of few things less appropriate to apply the term "rot" to.
- jussaskin 10y ago
  Software doesn't exist in isolation. It interacts with its host OS, shared libraries, other programs, protocols, file formats and external systems. If it can't keep up then it effectively rots even though not a single byte of it has changed.
- beat 10y ago
  It's a metaphor, not an equivalence. It doesn't even have to be in the same field, as long as the meaning is conveyed. Bit rot is an excellent metaphor, even though it's nothing like physical rot if you get pedantic about it.
- nbouscal 10y ago
  You're the first person I've heard say that the metaphor doesn't make any sense; meanwhile, a lot of people regularly use it, which implies that it makes sense to them. You're welcome to not like the metaphor, but you don't really get to declare that it's objectively wrong… it's a metaphor.

cbd1984 10y ago

Changes in the environment screw it up, too. As an obvious case, if your software is screen-scraping a website and the website's layout changes, your software's just rotted even though your code hasn't changed one bit. Another example is software which interfaces with hardware: Swapping one specific piece of hardware out for "the same" hardware made by a different manufacturer can cause rot, because "the same" hardware isn't necessarily the same in every respect. If your software tickles it the right way, it can expose differences which can cause your software to fail in new and exciting ways. Nothing changed, yet everything's different. As you expand the universe of things your code has to interact with, this kind of change becomes inevitable. As always, the more points of attachment, the more potential for future pain.

ourmandave 10y ago

The American Chesterton Society logo had to be the inspiration for Buzz Killington. http://familyguy.wikia.com/wiki/Buzz_Killington http://familyguy.wikia.com/wiki/Buzz_Killington

wvenable 10y ago

> Software doesn't rot. On the face it, that's true. But the reality is that the environment that software runs in is constantly evolving and software that doesn't also change slowly starts working worse until it stops working entirely. We have plenty of software at my work that hasn't changed fundamentally in 10 years and can no longer be used. Lots of really old software requires equally unchanged old environments and old hardware and that hardware slowly rots too.

johannes1234321 10y ago
... add to this that user expectations change. Applications not matching that feel rotted. Just look at websites from 10 years back to get an idea only on very surface levels.

akkartik 10y ago

I think you're taking the phrasing too literally. When we say software rots, we're not just talking about the bits that make up a program, but also its interface with its environment, and the knowledge about it in people's brains. Both those connections are indeed subject to drift/evaporation/entropy. The two failure modes you mentioned are symptoms of that underlying evaporation. I spend a lot of time thinking about this (http://akkartik.name/about http://akkartik.name/about), but lately I try to steer clear of metaphors, because they're so often clear in my mind but utterly opaque to someone else's. So, I don't care what we call it, as long as more people try to fix the problem.