4 ms·

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

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.
notacoward 8y ago
> what stops a program from adapting? It becomes "ossified." Because the code organization isn't up to the challenge Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptation - company dies, developers die or change jobs or lose interest. That's why "rot" is an apt metaphor, like a house slowly falling apart due to lack of maintenance. > If all of the environmental variables remain the same > I can deal with idioms. If 1) the idioms are very consistent and 2) you have a reliable syntax driven code rewrite tool, Would you like a pony too? The environmental variables don't remain the same. The tools aren't smart enough to catch every subtle variation of an idiom repeated hundreds of times across a large codebase. Yes, you can automate away the easy cases, but that's not even half the battle. That's why people hire maintenance programmers like you.
- stcredzero 8y ago
  Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptation It varies from shop to shop, but what I've seen is that code organization has a lot to do with it. Basically, if your code organization/factoring is really bad, then it's more likely that porting becomes untenable. Ironically, these are the projects that can have the longest lifespans, sometimes developing a history of multiple failed attempts to "port" them. (Really, re-implement while incurring huge opportunity costs.) > If all of the environmental variables remain the same Would you like a pony too? You're seriously missing the point. My point is that the environmental variables never remain the same. (I was making two points, and I think you missed where I switched.) > 2) you have a reliable syntax driven code rewrite tool Would you like a pony too? I repeat. I've been paid good money to use such a tool. I've used such a tool to enable the 1-step-removed porting of a project to a different language variant. Instead of doing the port myself, I was refining a tool which automated the port and enabled the maintainers to easily port all the changed code they were checking in. This lets you do a port without incurring the opportunity cost. I know of a consulting company that once made most of their income with this. Yes, you can automate away the easy cases, but that's not even half the battle. You can't simply hit a switch with this, of course. Someone has to put real thought into how the translations are made, especially if you want idiomatic, readable code going out the other end. The good thing about consistent idioms, is that they can be leveraged to multiply that work. The manual part can be re-leveraged through automation. That's why people hire maintenance programmers like you. That could be read in a way that sounds less than friendly and maybe a bit elitist.

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.

notacoward 8y ago

> what stops a program from adapting? It becomes "ossified." Because the code organization isn't up to the challenge Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptation - company dies, developers die or change jobs or lose interest. That's why "rot" is an apt metaphor, like a house slowly falling apart due to lack of maintenance. > If all of the environmental variables remain the same > I can deal with idioms. If 1) the idioms are very consistent and 2) you have a reliable syntax driven code rewrite tool, Would you like a pony too? The environmental variables don't remain the same. The tools aren't smart enough to catch every subtle variation of an idiom repeated hundreds of times across a large codebase. Yes, you can automate away the easy cases, but that's not even half the battle. That's why people hire maintenance programmers like you.

stcredzero 8y ago
Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptation It varies from shop to shop, but what I've seen is that code organization has a lot to do with it. Basically, if your code organization/factoring is really bad, then it's more likely that porting becomes untenable. Ironically, these are the projects that can have the longest lifespans, sometimes developing a history of multiple failed attempts to "port" them. (Really, re-implement while incurring huge opportunity costs.) > If all of the environmental variables remain the same Would you like a pony too? You're seriously missing the point. My point is that the environmental variables never remain the same. (I was making two points, and I think you missed where I switched.) > 2) you have a reliable syntax driven code rewrite tool Would you like a pony too? I repeat. I've been paid good money to use such a tool. I've used such a tool to enable the 1-step-removed porting of a project to a different language variant. Instead of doing the port myself, I was refining a tool which automated the port and enabled the maintainers to easily port all the changed code they were checking in. This lets you do a port without incurring the opportunity cost. I know of a consulting company that once made most of their income with this. Yes, you can automate away the easy cases, but that's not even half the battle. You can't simply hit a switch with this, of course. Someone has to put real thought into how the translations are made, especially if you want idiomatic, readable code going out the other end. The good thing about consistent idioms, is that they can be leveraged to multiply that work. The manual part can be re-leveraged through automation. That's why people hire maintenance programmers like you. That could be read in a way that sounds less than friendly and maybe a bit elitist.