Okay, I admit it. I'm one of those overly-anal programmers who, if he has to extend legacy code, has a irresistable instinct to rewrite bits that are duplicative or [otherwise] inefficient. I mean, I'm not crazy. I don't rewrite something that works. Well, not for the most part. I just like to spare as many bits as possible from having to be impressed into service for my applications. And if I'm going to put my name on something, it'd better be done right.

But there are times where the mistakes are so danged convoluted and incestuous that I can't pull out one without opening Pandora's box without the hope. It reminds me of when I decide I'd like to plug my VCR back into the TV where I used to have my DVD player installed. Sometimes the three wires come right out, but sometimes you're pulling out not only the three plugs, but the coaxials and the power strip, taking each wire out until it's totally separate, and starting over. Or you end up telling yourself that the fact that you need three remotes to watch a movie really isn't all that bad.

Let me give you an example. Let's say we've got fifteen legacy JPanels full o' code (if you're not a Java guy, just think 15 panels with GUI widgets on em, and the panels can have their own code). Each of these JPanels is displayed on a JFrame in a CardLayout (again, non-Java translation, "One of these panels can be shown at any one time in a larger frame that is displayed on the user's screen. If panel 1 is visible, then 2-15 aren't, etc").

Now let's say the last team wrote a customized function for each JPanel (they're all different! Can't stress that enough) that essentially cleans the JPanel's GUI widgets. On panel 1 the function is called, "cleanWidgets". One panel 2 it's called, "wipeWidgets". On panel three there are actually four functions doing different parts of the work, and sometimes only 2 are called when the panel's refreshed, and sometimes all four. No obvious reason why -- it would seem all four have overlapping parts.

That's the kind of thing I'm talking about. The original team should have taken the common logic out, extended JPanel with "legacyProjectPanel", and added a default function in this object called "resetGUI". Then each of the 15 panels would have an instance of this function. And, get this, you could centralize the code from moving from one panel to another somewhere in the JFrame! Then it could genericly call the resetGUI function of any "legacyProjectPanel", and any system-wide changes could be done in the JFrame instead of having to do things in a custom fashion in 15 different JPanels.

If I'm going to need to functionality so that you can navigate from one JPanel to the next in a different way, say add a menu that has all fifteen (bad GUI; just an example), I'm going to refactor and insert the resetGUI function that shoulda been there before.

So what to do if it's going to take longer to refactor than you've got to extend in the first place? If you see the jumbled mess but choose to ignore as much of it as is humanly possible (since the code does "work"), you've always got that fear that something that you did rewrite to extend the code is going to cause some strange reaction like the one your high school science teacher got that time s/he mixed two things in a vial and the fire alarm went off.

Anyhow, the point, if there is one to this ramble, is simple. Hire smart people who know how to code and don't let the mess happen from the start. As soon as you hire one person who wasn't on the A-list, face it, your software's going into the toilet. Good luck with version 2.0.