4 ms·

The examples don't seem to illustrate software rot at all. Rather, I'd say they illustrate software ossification. Over time, each example became more rigid and

The examples don't seem to illustrate software rot at all. Rather, I'd say they illustrate software ossification. Over time, each example became more rigid and hard to change because things that should have been modularized and isolated in one place instead became idioms pervading the entire codebase. (The "should have" is arguable, I know. There's a broader point about idioms vs. modules that deserves its own blog post.) Rot would be when a program works less and less over time because its external dependencies vanish or change and the program itself stops adapting. Software that is merely rotten can often be saved, with varying levels of effort and skill. Software that is ossified often needs to be replaced.

meschi 8y ago
Can you provide an example of rotten software?
- notacoward 8y ago
  The extreme case is programs for which the entire platform has been abandoned - e.g. DOS (including TSRs), old Windows, old MacOS (including desk accessories). There's a whole "abandonware" community devoted to preserving games that have rotted this way, usually relying on emulation to keep them from being forgotten entirely. There are various file compression/encryption/annotation utilities that have become unusable because they relied on deprecated Windows APIs. Various sound/video hacks on Linux have died as those subsystems remain in constant flux. In my own work as a Gluster maintainer, several pieces such as Java/Python or monitoring APIs have rotted away as those APIs changed. It usually takes a long time for a large program to rot away completely, but individual pieces can become non-functional long before then.
- Raidion 8y ago
  I think the point OP is making is that there is plenty of bad software out there that (as a result of a combination of incompetence, scope creep, bad decisions, and short timelines) just isn't resilient, testable, and single use anymore. As long as the code is isolated enough, it's fairly easy from a technical standpoint to replace/refactor. Ossified code is code that isn't isolated, but tightly bound to several other components. This means that you can't swap it out without making the exact same architectural mistakes. This means you basically need to start over from scratch, which is a much harder and broader problem.
  - convolvatron 8y ago
    there is an alternate path for your ossified code, but its really costly. idk if it has a cute name. if there aren't system/integration tests - write system tests. you have to be pretty thorough. have a long and involved discussion about what the new thing is going to be. go through all the frustrations with the current code base. convince yourself at the end that its going to be worth it, because the cost is going to be high. ideally the new version will open up new capabilities that just weren't possible before. find a cut in the dependency graph. you're going to rewrite the code on one side and leave the other side untouched. ideally that cut will be small-ish and contain some particularly broken stuff that you'd like to get rid of as soon as possible. unfortunately there may not be a small cut that makes sense :-( build a shim between the old model and the new model across the cut. this shim is only going to last as long as the old code on the other side. this shim might be involved and a total waste of effort. suck it up or look for a different cut. replace the code on the new side and test against your suite. if its not really that exhaustive, expect a rash of bug reports. run through some kind of soft deployment. if its a request/response kind of thing consider forking your production traffic and comparing the results against the old code base. repeat until golden brown. this overall process also can fail. often because of poor test coverage, and more likely because you haven't adequately communicated the scope of the undertaking and its absolute necessity to the rest of the engineering organization and the business as a whole. however, if you make it through, you've avoided the giant speed bump that comes at the end of the rewrite, and you've been able to fold in new feature and bugfix work along the way.
    - rzzzt 8y ago
      Cute name is "strangler": https://www.martinfowler.com/bliki/StranglerApplication.html https://www.martinfowler.com/bliki/StranglerApplication.html
- cm2187 8y ago
  Skype
- norfolk2 8y ago
  Everything written in python2 after 2020 is going to start to rot - within a few years, various library dependencies are going to fail, etc.
tobiasSoftware 8y ago
While I agree this article isn't about rot, the definition of rot I'm used to is more about how knowledge of a product becomes lost over time without any active developers, so it becomes harder and harder to switch back to active development.
- Izkata 8y ago
  The one I'm used to is related to that one, but only barely: the software becoming less and less stable and/or harder to change as features are added. The cause can be loss of knowledge or ever-increasing technical debt.
stcredzero 8y ago
The examples don't seem to illustrate software rot at all. Rather, I'd say they illustrate software ossification. I was about to come here to say that there's really no such thing as software rot. If all of the environmental variables remain the same, software doesn't really rot. It's actually the environmental variables which change. Over time, each example became more rigid and hard to change because things that should have been modularized and isolated in one place instead became idioms pervading the entire codebase. I can deal with idioms. If 1) the idioms are very consistent and 2) you have a reliable syntax driven code rewrite tool, you can drive idioms into a library and/or otherwise translate them. I've been paid to do both. Rot would be when a program works less and less over time because its external dependencies vanish or change and the program itself stops adapting. But what stops a program from adapting? It becomes "ossified." Because the code organization isn't up to the challenge, it becomes too hard to add and change features without introducing bugs. There is no software "rot." It's all different kinds of ossification.
- mixedCase 8y ago
  > If all of the environmental variables remain the same, software doesn't really rot. It's actually the environmental variables which change. Then it sounds like "rot" is a very aptly used word. I'll put on the jerk hat and quote the Oxford dictionary: rot (verb) 1 (chiefly of animal or vegetable matter) decay or cause to decay by the action of bacteria and fungi; decompose.
  - TeMPOraL 8y ago
    Is it? My reading of that definition leads to exactly opposite conclusion. Rot is when something breaks down while environment remains the same. What happens with software is the opposite: it forever remains in pristine condition; it's the environment that changes. (Compare also with description of evolution. A species does not "rot". It dies off when its niche changes so much its no longer adapted to survive in it.)
    - stcredzero 8y ago
      What happens with software is the opposite: it forever remains in pristine condition; it's the environment that changes. Exactly. If you replicate the old environment in an emulator, the old code runs just fine.

meschi 8y ago

Can you provide an example of rotten software?

notacoward 8y ago
The extreme case is programs for which the entire platform has been abandoned - e.g. DOS (including TSRs), old Windows, old MacOS (including desk accessories). There's a whole "abandonware" community devoted to preserving games that have rotted this way, usually relying on emulation to keep them from being forgotten entirely. There are various file compression/encryption/annotation utilities that have become unusable because they relied on deprecated Windows APIs. Various sound/video hacks on Linux have died as those subsystems remain in constant flux. In my own work as a Gluster maintainer, several pieces such as Java/Python or monitoring APIs have rotted away as those APIs changed. It usually takes a long time for a large program to rot away completely, but individual pieces can become non-functional long before then.
Raidion 8y ago
I think the point OP is making is that there is plenty of bad software out there that (as a result of a combination of incompetence, scope creep, bad decisions, and short timelines) just isn't resilient, testable, and single use anymore. As long as the code is isolated enough, it's fairly easy from a technical standpoint to replace/refactor. Ossified code is code that isn't isolated, but tightly bound to several other components. This means that you can't swap it out without making the exact same architectural mistakes. This means you basically need to start over from scratch, which is a much harder and broader problem.
- convolvatron 8y ago
  there is an alternate path for your ossified code, but its really costly. idk if it has a cute name. if there aren't system/integration tests - write system tests. you have to be pretty thorough. have a long and involved discussion about what the new thing is going to be. go through all the frustrations with the current code base. convince yourself at the end that its going to be worth it, because the cost is going to be high. ideally the new version will open up new capabilities that just weren't possible before. find a cut in the dependency graph. you're going to rewrite the code on one side and leave the other side untouched. ideally that cut will be small-ish and contain some particularly broken stuff that you'd like to get rid of as soon as possible. unfortunately there may not be a small cut that makes sense :-( build a shim between the old model and the new model across the cut. this shim is only going to last as long as the old code on the other side. this shim might be involved and a total waste of effort. suck it up or look for a different cut. replace the code on the new side and test against your suite. if its not really that exhaustive, expect a rash of bug reports. run through some kind of soft deployment. if its a request/response kind of thing consider forking your production traffic and comparing the results against the old code base. repeat until golden brown. this overall process also can fail. often because of poor test coverage, and more likely because you haven't adequately communicated the scope of the undertaking and its absolute necessity to the rest of the engineering organization and the business as a whole. however, if you make it through, you've avoided the giant speed bump that comes at the end of the rewrite, and you've been able to fold in new feature and bugfix work along the way.
  - rzzzt 8y ago
    Cute name is "strangler": https://www.martinfowler.com/bliki/StranglerApplication.html https://www.martinfowler.com/bliki/StranglerApplication.html
cm2187 8y ago
Skype
norfolk2 8y ago
Everything written in python2 after 2020 is going to start to rot - within a few years, various library dependencies are going to fail, etc.

tobiasSoftware 8y ago

While I agree this article isn't about rot, the definition of rot I'm used to is more about how knowledge of a product becomes lost over time without any active developers, so it becomes harder and harder to switch back to active development.

Izkata 8y ago
The one I'm used to is related to that one, but only barely: the software becoming less and less stable and/or harder to change as features are added. The cause can be loss of knowledge or ever-increasing technical debt.

stcredzero 8y ago

The examples don't seem to illustrate software rot at all. Rather, I'd say they illustrate software ossification. I was about to come here to say that there's really no such thing as software rot. If all of the environmental variables remain the same, software doesn't really rot. It's actually the environmental variables which change. Over time, each example became more rigid and hard to change because things that should have been modularized and isolated in one place instead became idioms pervading the entire codebase. I can deal with idioms. If 1) the idioms are very consistent and 2) you have a reliable syntax driven code rewrite tool, you can drive idioms into a library and/or otherwise translate them. I've been paid to do both. Rot would be when a program works less and less over time because its external dependencies vanish or change and the program itself stops adapting. But what stops a program from adapting? It becomes "ossified." Because the code organization isn't up to the challenge, it becomes too hard to add and change features without introducing bugs. There is no software "rot." It's all different kinds of ossification.

mixedCase 8y ago
> If all of the environmental variables remain the same, software doesn't really rot. It's actually the environmental variables which change. Then it sounds like "rot" is a very aptly used word. I'll put on the jerk hat and quote the Oxford dictionary: rot (verb) 1 (chiefly of animal or vegetable matter) decay or cause to decay by the action of bacteria and fungi; decompose.
- TeMPOraL 8y ago
  Is it? My reading of that definition leads to exactly opposite conclusion. Rot is when something breaks down while environment remains the same. What happens with software is the opposite: it forever remains in pristine condition; it's the environment that changes. (Compare also with description of evolution. A species does not "rot". It dies off when its niche changes so much its no longer adapted to survive in it.)
  - stcredzero 8y ago
    What happens with software is the opposite: it forever remains in pristine condition; it's the environment that changes. Exactly. If you replicate the old environment in an emulator, the old code runs just fine.