
Corn and Software - sant0sk1
http://adam.blog.heroku.com/past/2008/8/23/corn_and_software/
======
nostrademons
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
Yes, and a version control system is implied.

------
edw519
_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
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
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
_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
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.)

