A recent project got me thinking about the old trope that, upon getting involved in an existing project, the first thing any developer wants to do is rewrite it.

Obviously, that’s not always true, and in fact, I’ve rarely been tempted. But the following situation made the thought cross my mind, and it also led me to realize the reasons I didn’t bite.

Let’s talk about it, but first, I’ll talk more generally about rewriting codes, the potential benefits, and the reasons it’s typically best not to.

Why Rewriting Can Be Tempting

Long ago when I was just transitioning from personal/college code to writing commercial code as a real job, there was a time when I thought there was no reason that code shouldn’t be beautifully written, almost like a poem. Considering I was doing a lot in Perl at the time, I wasn’t alone.

I also had a somewhat peculiar background steeped in human languages as much as computer ones, so it all seemed to make sense. Eventually, though, I saw that my beautiful writings ended up being edited – ruined! – by people who didn’t share my sentiment, and in any case, it all ended up out of sight or destroyed by a compiler anyway…

My personal background might have been a bit unusual, but we all bring our own sensibilities to a project when we sit down and look at all the work the people before us have done. Inevitably, the existing code doesn’t match up to what we envision, it feels uncomfortable, and we may begin to feel like a rewrite is the right choice.

With experience, though, I’ve learned that a fair amount of this mismatch is really more personal preference than absolute necessities. Things like…

• spaces/tabs,
• naming conventions,
• line length,
• and probably a whole lot more.

Not that these things don’t have any significance; there just isn’t much absolute good or bad about any of the choices people make. They’re relative, and they’re definitely not a reason to rewrite.

A Quick Aside

Fortunately, these days, if you stay within a particular language, there is often an accepted style that you can learn or even automate. So, little mismatches aren’t such a big deal anymore.

Having said that, you’ll lint the if statement brackets out of my cold, dead hands.

If (omitBracketsForAOneLineStatement)
{
   Echo (“NO!);
}

That’s only one rule to remember about IF/ELSE syntax instead of two. Now, I have extra neurons free to remember more Golden Girls trivia, Rose! (Yes, I know virtually nobody agrees with me on this.)

Why Rewriting Is (Probably) Not It

Of course, as I think we all realize eventually, rewriting old code isn’t usually the way to go. For one, unless you’ve been appointed top dog, nobody is likely to authorize the time and expense to do it for any reasonably functional project.

Which is just as well. We’ve all heard that old code is good code, and I can posit at least three reasons why, and no doubt there are more.

1. The business doesn’t care. If the processes are more or less doing their job, then further work is just an unnecessary expense (and they may not be wrong!).
2. Often, old code incorporates requirements, fixes, and updates that are loosely or not at all documented. If you rewrite, you might lose that,
3. Old code may be ugly, but it’s consistent within an organization and familiar to the other developers. Consistency trumps ugly.

Suffice it to say, as long as it’s quality code, rewriting is probably not the way to go.

What Really Is “Quality Code”

So nothing matters, and it’s ok to just write any crap you want, right? I’m pretty laid back about all this, but even I wouldn’t go that far.

Certainly, in the past 3 quarters of a century, programmers have uncovered some language-independent pillars of “quality code.”

They’re incredibly basic but cover much more territory than you’d think. One way you can tell that something is important is that it has a catchy acronym, and a couple that I find coming up a lot are:

• KISS: Keep It Simple Stupid
• DRY: Don’t Repeat Yourself

Probably most everyone knows KISS because it applies to … everything. DRY is a favorite of mine because it prevents a lot of unnecessary maintenance later on.

There are more (ask different programmers and you’ll probably get somewhat different ones), but more and more, I think they all lead to the one true rule.

The Question at Hand: To Rewrite Or Not To Rewrite?

So, let’s go back to the project I mentioned at the very beginning. It’s the first project I’ve come across lately that really had me wondering, “Would extensive refactoring — rewriting — be worth it?”

In the midst of that pondering, I stopped myself and thought back to some of the projects I’d worked on in the past. It didn’t take long to remember that I’d been here before. I could take advantage of hindsight to evaluate what I should really do.

Here are my insights from both sides of the coin, but the decision is ultimately yours.

On One Hand:

• Code that doesn’t use CamelCase right but is consistent is probably fine.
• Code that puts brackets on the wrong lines but does it the same way throughout is probably fine.
• Code that breaks the problem down differently from what you’d do but does the job correctly is probably fine.
• Code old enough to be from the Eisenhower administration is probably GREAT… in its own way.

On the Other Hand:

• Code that doesn’t have consistent naming, spelling, or spacing such that you can’t effectively do a global find is probably bad.
• Code that doesn’t handle reasonably expected types of errors without crashing so that you’re constantly chasing support issues is probably bad.
• Code that mushes several disparate operations all into one stream-of-consciousness block so that it’s nearly impossible to figure out what’s going on is probably bad.
• Code that is copied and pasted all over the place so that one change becomes twenty changes is probably HORRIBLE.

The Bottom Line

Here’s my point: you may work on old code that you don’t like, but take some time to really think about what would happen if you “fixed” it.

Will it keep you from chasing crazy support issues? Will it allow you to make future updates with 2 lines of code instead of 200 or find a problem in two minutes instead of two weeks? If yes, go for it! Refactor and rewrite to your heart’s content. Otherwise, think twice.

As I said, that’s my advice from both sides of the issue. The decision is yours and should be based on your situation. And remember, everyone knows that a good programmer is lazy, and good code lets us be.

I’d love to hear your rewriting thoughts and stories. Drop a comment below, and remember to check out the rest of the Keyhole Dev Blog for more content!