5 ms·

Software does not evolve; software degenerates

9 points by nocivus 17y ago

locopati 17y ago
The dead ends of the first design usually inform the design decisions of a major rewrite/refactoring. So, in that way the line of evolution is unbroken. Even moreso, if you expand the metaphor from the evolution of an individual or a species to the evolution of an ecosystem, which is really what a software project is - the code, the libraries, the deployment environments, the containers (hardware, databases, app servers, etc), etc.
benwerd 17y ago
Seems like a great argument for clear, modular, well-written code to me. Sometimes you get dead ends, but that's true of evolution too. If your base is sufficiently flexible that it can tolerate significant changes, the amount of refactoring you have to do further down the line is diminished.
- sophacles 17y ago
  There are some problems with this. First, it assumes you know up front the best way to solve the problem. Second, it assumes that the problem doesn't ever change. Third, it completely ignores a suprisingly common issue: the tradeoff. By this I mean: sometimes modularity/flexibility in one area requires being unflexible in another. Guessing wrong requires a big refactor. There are good arguments for both -- sometimes you just have to do one and find out if you were right. The problem comes when management says "how come you didn't do it right the first time?" and refuses to accept that thier three sentence change of spec requires serious redesign.
  - nocivus 17y ago
    That is precisely my point in the post: A lot of times the problem itself changes. Not to mention the requirements that management sees as "details" but that, in reality, are complete game changers as far as the system architecture goes.
bediger 17y ago
He needs to take a look at this one: "Does Code Decay? Assessing the Evidence from Change Management Data" http://nisla05.niss.org/technicalreports/tr81.pdf http://nisla05.niss.org/technicalreports/tr81.pdf The answer is "yes", except if you undertake extraordinarily rare "perfective maintenance". Mostly, managers Just Want It Done Fast, so perfective maintenance never ever gets done, leading to devolving code.

9 points by nocivus 17y ago

The dead ends of the first design usually inform the design decisions of a major rewrite/refactoring. So, in that way the line of evolution is unbroken. Even moreso, if you expand the metaphor from the evolution of an individual or a species to the evolution of an ecosystem, which is really what a software project is - the code, the libraries, the deployment environments, the containers (hardware, databases, app servers, etc), etc.

benwerd 17y ago

Seems like a great argument for clear, modular, well-written code to me. Sometimes you get dead ends, but that's true of evolution too. If your base is sufficiently flexible that it can tolerate significant changes, the amount of refactoring you have to do further down the line is diminished.

sophacles 17y ago
There are some problems with this. First, it assumes you know up front the best way to solve the problem. Second, it assumes that the problem doesn't ever change. Third, it completely ignores a suprisingly common issue: the tradeoff. By this I mean: sometimes modularity/flexibility in one area requires being unflexible in another. Guessing wrong requires a big refactor. There are good arguments for both -- sometimes you just have to do one and find out if you were right. The problem comes when management says "how come you didn't do it right the first time?" and refuses to accept that thier three sentence change of spec requires serious redesign.
- nocivus 17y ago
  That is precisely my point in the post: A lot of times the problem itself changes. Not to mention the requirements that management sees as "details" but that, in reality, are complete game changers as far as the system architecture goes.

bediger 17y ago

He needs to take a look at this one: "Does Code Decay? Assessing the Evidence from Change Management Data" http://nisla05.niss.org/technicalreports/tr81.pdf http://nisla05.niss.org/technicalreports/tr81.pdf The answer is "yes", except if you undertake extraordinarily rare "perfective maintenance". Mostly, managers Just Want It Done Fast, so perfective maintenance never ever gets done, leading to devolving code.