Is rewriting old code a good idea yet?

Question

Inspiration here

Let's say I have a big, wonderful set of integration tests for my product. It tests anything and everything that we need to test. And after the product passes all these tests, we take a look at the source, decide it's complete garbage, and start from scratch. Is this a good business decision?

I fully acknowledge that no set of integration tests is perfect, and there are always time/budget constraints to be considered, but for the sake of this question we'll put those aside. Let's look at the benefits.

1. If our code base is 5 years old and written by the early programmers in the company who were learning as they go, and now we have "experienced" programmers who can make the code more maintainable. Yes, some may need ramp-up time on domain knowledge, but I'd argue writing from scratch would help develop this knowledge faster and more completely.

2. If the existing version of our code uses some core library that is "outdated" and performs badly in all scenarios, and replacing it wholesale will take 10 months and rewriting it with the shiny new thing will take 6. Seems like a no-brainer, right?

There's plenty of other "good" reasons to rewrite a product, but Joel's point is that you're bound to make the same mistakes that the previous product already outgrew.

But what of tests? If I have a way of testing a product that's not tied to the code itself (for instance, integration tests), doesn't that ensure that those potential mistakes are caught early?

Assuming you have a way of verifying behavior and output easily, especially with the tools available today, is starting from scratch still a bad idea?

Answer 1

It depends what your trouble with the code is. If you hardly ever have to visit it anymore, it is probably not worth it. If you find yourself debugging it all the time, spending 99% understanding how it works and 1% to change the code, it may be worth it.

And then you may have some folks that grew up with the mess who do not see the problem (they know all the quirks because they made them or were close when they emerged). They have good memory too so they know their way in what they did. Good luck with them.

Answer 2

There is no single answer for this question, It depaend on the case. Rewriting your code will cost time, And you will feel like you didn't get anything for this time. But, if you think of the future, If one day you will want to change things in your code or add features it will take much more time with a bad code, it will be hard to debug, So it might be that rewriting the code will even save you time in long term. I would recommend to do it if you think that there is a good chance that you will need to change this code in the future, And if not dont rewrite it. Try to think how much time you will need to spend for rewriting and how much time it will take to add feature to the current code, It will help you decide.

Answer 3

The danger here is being seduced by the green field.

We all love the feel of a new project where adding things is so easy as to almost be thoughtless. Once that time is over it's very tempting to want to get it back.

An established code base slows you down. You have to make what you want fit with what already exists.

You can only get your speed back by ignoring those considerations because that's what this speed is, considerations ignored. You could go fast before because you didn't even know you were ignoring them.

A code base teaches you things that need considering. If yours is like most projects the code is where your real specification documentation is.

You might think it's simply a physical limitation of working in the code base. I know that's not true because when I've worked converting a code base from one language to another I still feel slowed down even when the new language is barely started yet.

That's because even though I have all this fresh space to work in I can still see what's coming. So I'm being careful where I put things.

Now given all that you might feel a bit trapped. I assure you, there is no code base so fully established that a bad design decision spread out within it can't be overturned with deliberate work. It is possible to salvage the useful work that's been put into it without perpetuating the bad ideas. Incremental changes made to improve the code and add tests help do this slowly. If you need a big sudden change it's going to take a bit of heroic coding. Even if you try that don't just go for a full rewrite. Tackle one bad idea at a time.

Otherwise, if you just go for the full rewrite, when you're done you'll find after all that work you've simply replaced old bad ideas with new bad ideas.

Don't let yourself be seduced by the green side.