4 ms·

Corn and Software

23 points by sant0sk1 18y ago

edw519 18y ago
In my experience, 95% of the time something appears unused or irrelevant, it is. It's the other 5% that bites you in the ass. I'm finding more and more that a total rewrite makes the most sense. This used to be taboo, but now, it often takes less resources than untying the Gordian knot of horribly evolved software. And besides, someone should actually know what it does every 20 years or so.
- DanielBMarkham 18y ago
  I would be willing to bet that 80% of most deployed software should be rewritten instead of patched/upgraded. Brooks was right with his "build one to throw away". The problem is that it never works out where people can/will throw the first one out.
  - stcredzero 18y ago
    I have seen production systems where the programmer will copy an existing method, rename it and modify it to "extend" the system. I have also seen programmers use their code browser as a revision control system that way. I have literally seen "lava flow code" where many, many programmers have been afraid to modify code, and it has been patched and program flow rerouted in a convoluted way that resembles hardening erupting lava. The current system I am working on has a history of developers throwing away and rewriting subsystems. Not surprisingly, it has very understandable code.
    - edw519 18y ago
      The current system I am working on has a history of developers... How do you know that? Imagine working on a system with no standards, documentation, version control system, or audit trail. Oh wait, some of us don't have to imagine.
      - stcredzero 18y ago
        I know the history of the system in my current job, because there are people from its inception over 12 years ago. They've told me about how subsystems have been rewritten. I've also witnessed it in my 3 years there. It's not always pretty. I've seen one subsystem rewritten 3 times by 3 different people who each thought they were smarter than the last guy, but then went on to make the same (very subtle, very difficult to understand) mistakes. The 4th time has stuck, however. The resulting code is much cleaner and is finally (relatively) trouble free. Its approach is significantly different from the last 3 attempts. Figure that! I've also seen subsystems evolved in 2 or 3 iterations by the same developer, each iteration involving a rewrite. So, I'd have to say my current shop is pretty good. They really should be doing more refactoring. They could be doing more incremental improvement and avoid the pain of complete rewrites. But at least they are wise enough to avoid pounding their heads against the wall of bad design indefinitely. (Or, to be fair, naive 1st drafts.)
- danw 18y ago
  Watch out for the Second System Effect however http://en.wikipedia.org/wiki/Second-system_effect http://en.wikipedia.org/wiki/Second-system_effect
nostrademons 18y ago
A good comprehensive test suite helps here too. Cut the fat out, run the tests, if it passes you know that functionality wasn't needed and you can check it in. If it fails, take a look at the failing test and either cut the test out or revert your changes.
- eru 18y ago
  Yes, and a version control system is implied.

23 points by sant0sk1 18y ago

In my experience, 95% of the time something appears unused or irrelevant, it is. It's the other 5% that bites you in the ass. I'm finding more and more that a total rewrite makes the most sense. This used to be taboo, but now, it often takes less resources than untying the Gordian knot of horribly evolved software. And besides, someone should actually know what it does every 20 years or so.

DanielBMarkham 18y ago
I would be willing to bet that 80% of most deployed software should be rewritten instead of patched/upgraded. Brooks was right with his "build one to throw away". The problem is that it never works out where people can/will throw the first one out.
- stcredzero 18y ago
  I have seen production systems where the programmer will copy an existing method, rename it and modify it to "extend" the system. I have also seen programmers use their code browser as a revision control system that way. I have literally seen "lava flow code" where many, many programmers have been afraid to modify code, and it has been patched and program flow rerouted in a convoluted way that resembles hardening erupting lava. The current system I am working on has a history of developers throwing away and rewriting subsystems. Not surprisingly, it has very understandable code.
  - edw519 18y ago
    The current system I am working on has a history of developers... How do you know that? Imagine working on a system with no standards, documentation, version control system, or audit trail. Oh wait, some of us don't have to imagine.
    - stcredzero 18y ago
      I know the history of the system in my current job, because there are people from its inception over 12 years ago. They've told me about how subsystems have been rewritten. I've also witnessed it in my 3 years there. It's not always pretty. I've seen one subsystem rewritten 3 times by 3 different people who each thought they were smarter than the last guy, but then went on to make the same (very subtle, very difficult to understand) mistakes. The 4th time has stuck, however. The resulting code is much cleaner and is finally (relatively) trouble free. Its approach is significantly different from the last 3 attempts. Figure that! I've also seen subsystems evolved in 2 or 3 iterations by the same developer, each iteration involving a rewrite. So, I'd have to say my current shop is pretty good. They really should be doing more refactoring. They could be doing more incremental improvement and avoid the pain of complete rewrites. But at least they are wise enough to avoid pounding their heads against the wall of bad design indefinitely. (Or, to be fair, naive 1st drafts.)
danw 18y ago
Watch out for the Second System Effect however http://en.wikipedia.org/wiki/Second-system_effect http://en.wikipedia.org/wiki/Second-system_effect

nostrademons 18y ago

A good comprehensive test suite helps here too. Cut the fat out, run the tests, if it passes you know that functionality wasn't needed and you can check it in. If it fails, take a look at the failing test and either cut the test out or revert your changes.

eru 18y ago
Yes, and a version control system is implied.