A common mistake.

A conversation last night left me thinking about programmers and projects I’ve worked on over the years.

I particularly ended up thking about a rather interesting essay that Joel Spolsky wrote. It’s about programming and called Things You Should Never Do. It is interesting to look at it now, through the glasses of the post-dot-bomb.

His argument, quite simply, is that the urge to rewrite a coded product from scratch is the “single worst strategic mistake any software company can make.”

The emphasis below is his. IT’s even stronger on the article. But this is how he opens his explanation:

There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.

He goes on to talk about how used and tested code may look warty or have odd bits in it because real-world needs put them there. And when you rebuild, you throw those away and set yourself up for the same problems and errors, as well as what you might generate.

He equates it to practically gifting any market leadership to your competitors, and considering the real-life examples he highlights, he’s right.

There is always a time and place for refactoring. Hell, that’s the fundamental basis for many development models. Be they called “SCRUM” but the Ruby folks or “Rapid Prototyping” by the C folks.

There is a time an place for complete rebuilds too. But 90% of the time I hear folks talk of it, it isn’t for a business reason. It’s for the “fun” factor. It’s for the “shiny” factor. And I’ve seen many a professional programmer argue for it by any means possible when it was just for their own pleasure.

A good admin or programmer should recognize the business side of the case. You don’t go swapping out systems that function for no reason. And if you do have to swap them out, you do so carefully and thoroughly tested. You treat your users with respect.

I just hate seeing time wasted rewriting things that work. Especially when it adds the risk of reintroducing bugs and problems. And often while other tasks are waiting to be done. It is a waste of time, a business risk, and often being done for the wrong reasons.

6 Responses to “A common mistake.”

  1. susandeer says:

    It’s like someone doing scads of research and testing over the course of a couple of years to come up with all the data necessary and it’s just about to the point where the numbers all add up nice, but the product looks great and the customers are happy..! And then someone else in the lab, whose usual job there is something else entirely, jumps up and down and says, “Hey! I bet I can do it! Let me just throw all of this years’ worth of stuff and experience in the trash and start ALL OVER AGAIN THIS WAY…CAUSE IT’D BE FUN!

    And then the boss goes, “Sure! Go ahead! Oh, and dude #1? Polish the test tubes and stuff so that when the customer comes in, we can present it all nice and pretty!” Even when it fails.

    Yeah.

  2. krin_o_o_ says:

    I tend to agree.

    There are times when it is a good thing to re-evaluate old work
    and decide if it needs to be redone using the lessons learned
    after 4 or 5 years of bitter experience.

    Code is a LOT like streets and roads. Well used APIs and Modules are well travelled ones and get LOTS of maintenance and upkeep to keep them modern, well lit, and functional. But, backwaters exist where there’s nothing but dirt and gravel and even the stoutest adventurer dare not go without a local guide (or code guru).

    This is where having super strong unit and integration tests are a must. Something sadly lacking in most of the industry. If I change one little thing, I have over 4000 tests to run in my playpen to verify that I do not break established behavior and protocols before i can push that code into production. Once pushed, there are about 10 other products that use my code with their own testing systems and personel.

    So, given all that going on when I change something… there’s a LOT of built in inertia to code changes in my company’s products.

    But durn, it still is fun to take a flame-thrower to some of that old swampy code! * BURN BABY! BURN! *

    – Krin

  3. wingywoof says:

    Have you read Dreaming in Code? Joel has a review here: http://www.joelonsoftware.com/items/2007/01/21.html

  4. Phil says:

    I can’t tell you how many times I’ve been in a meeting with even one or two other programmers, trying to figure out how something should work, and we’re just not getting anywhere. So I go off in my office and take out a piece of paper and figure it out. The very act of interacting with a second person was keeping me from concentrating enough to design the dang feature.

    Man. I had that happen TODAY in a work meeting. Do non-computer engineers have the same trouble?

  5. wingywoof says:

    Yes and no. There are times when “too many cooks ruin the broth” but other times when collaboration is almost imperative.

    Depending on the topic, I usually make sure I have some ideas to bring to the table well in advance of a meeting. That way some thinking has already been done. It’s good to keep an eye out for other people’s motives too since they can steer a design a totally different direction if you’re not aware.

  6. Anonymous says:

    The old saw, ‘If it ain’t broke, don’t fix it’ applies. Even when tossing out working software for something new and shiney.

    Sirius Dogfire

Leave a Response