Is it better to rewrite inherited code than fix it?

Question

Possible Duplicate:
When is it good (if ever) to scrap production code and start over?

Say you have been given a project, and you look at the code. Although it works, and is functional, you realize that to make future changes it would be easier to rewrite a large portion or all of the code. Is it better to do the rewrite? If it costs you a delay now, but saves you delays later (and possible bug fixes later), is it worth it?

Or do you simply fix what you see as you go along and are touching that part of the code?

Or do you fix it only if a bug is reported that would require touching that code?

Answer 1

You should fix it if you want to preserve the current design. If you decide to rewrite, normally a design review is in order. It also depends on the projected lifetime for the product, you could plan a comprehensive rewrite as a future version.

Answer 2

It depends how large the code base is.

Have you read this article?

Answer 3

• How much time do you have?
• How much money can you spend?
• Have you done an ROI analysis?

It too often comes down to money$$.

Answer 4

I think as a programmer it will always be easier to rewrite code that having to adapt to an existing code but at the end this doesn't not mean is the best solution.

Here's an interesting article:

Answer 5

When I started my current job, there was a (then) 10-year-old C++ application I started to work on right away.

For various reasons we decided to rewrite it and to keep maintaining the old one in the meanwhile.

We are still working (5 years later) on getting back all the same functionality there was in the old application in the new one so that we can stop maintaining the old one. On the other hand, we got some functionality early in the new one that would not have been possible in the old one, so that our "customers" didn't feel they were being had. If we had worked all this time with nothing to show for it, they would not have understood (and would have stopped paying...)

You can even cheat a little and pretend something wouldn't have been possible in the old framework when it could possibly have... Who's going to contradict you? No that we had to exaggerate much this way in our case... we were really running in technical limitations that couldn't be worked around without a rewrite.

Answer 6

I inherited a code base ten years ago. I'm still in it, twisting it here, bending it there. Some portions I had the chance to rework thoroughly, and I'm almost always happy with the result.

The funny thing is, though, that after all these years, when I look back at the initial code base, I must admit that the initial design had other merits than I gave it at first sight.

My conclusion? First try to fully understand the design of the code you inherit; only then start to think if a rework is needed.

Answer 7

This is a complicated issue many of us face, me included. Consider reading a good book on the subject, because this is a huge topic. How much time/money do you have, and do you really understand the scope? If (1) you have enough time/money, and (2) you're sure the solution will be active long enough to make back the investment, and (3) you are certain you understand the scope of a total revamp, then the total revamp may well be better. But that is a lot of "ifs".

Because of time/money constraints and uncertainty concerning how long the solution will be relevant, piecemeal refactoring is more often the better choice (meaning, lower risk). How agile are you? If your flexibility and designing-on-the-fly skills are your strong point, and your client/boss supports you in this, then gradual refactoring will almost always be the better choice.

• Use the same balancing skills you use when evaluating how exactly to write new code.
• Compare time spent now against maintainability/testability/simplicity later.
• Refactor the code most likely to need to be debugged/fixed/reconfigured in the future.
• Don't bite off more than you can chew; usually there isn't a lot of time available for refactoring.
• Unit tests are your best friend when refactoring.

And again, don't try to do too much! When your client/boss asks why features aren't being delivered, it doesn't sound good to say "well, I started refactoring a bunch of stuff, and it caused a lot of bugs, and I'm still trying to fix those." Better to get just one key part of your code in good shape.

Answer 8

This is what refactoring is all about. Changing the design of existing code without changing its functionality. You say you "realize" that it would be easier to rewrite, but that entails a certain presumption: that you know what will be required of the code in the future, that you know how much work rewriting it would be, and that you know how much work reworking it would be. I haven't known any programmers for whom that is true (myself very much included).

Refactoring - versus rewriting - offers some protection against this presumption. Done well, you can work only on what you need today, design the code you have so it can serve the immediate need you have, then modify it to serve that need. Bit by bit, your code gets cleaner and more malleable. And the bits that change are the ones that need changing - without making impossible predictions about the future. If you haven't read Martin Fowler's Refactoring, have a look at it; also Michael Feathers' Working Effectively with Legacy Code.

Answer 9

Don't just set off to rewrite the code based on what you understand. There's a lot of experience, implicit requirement, and bug fixes in it.

Instead, keep improving the code as you work with it. Put in unit tests when possible, and look for opportunities to clean it up. What you want to be doing is called "refactoring", which means making relatively small changes to the code to improve it in a controlled manner. Refactoring changes should be small enough so that you're confident they aren't introducing bugs, and unit tests will be very useful in that.

For example, where I work, I've been moving some functionality from where it was originally put (because it was in the same class as the routines that used it) to another class. The other class is considerably smaller, so it's cleaning up the original class somewhat, and it's designed to have the information the functionality needs. I've been doing it as I've been going along.

You'll never get the code as clean as it would be if some omniscient being rewrote it one night, but no real-world code is ever in that state. Either it's new and buggy, or tested and at least somewhat ugly. You can get the code to a state where it's a lot easier to work with.

Answer 10

Rewrite makes you a target for management. I'd go down that path with trepidation.

Answer 11

Unless there is a specific need (such as having to extend the functionality of the code beyond its original intentions), rewriting the code often introduces more bugs into the mix. Then you'll get the statement from customers: "But it used to work...".

That being said, sometimes it just has to be done. Recently, I've run into both scenarios.

Answer 12

One of Joel's articles suggests that you shouldn't rewrite code because "Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed".

However I have been in situations where the old code was originally designed completely wrong, and we decided it would be better in the long run to rewrite it.

Answer 13

It's never as easy to rewrite as it seems and if you need to maintain the existing application whilst the rewrite is happening then you risk never being able to match the existing application's functionality and always being several steps behind it. It's better, IMHO, to set about a process or improvement and refactoring so that as you maintain and extend the application it slowly gets better and moves nearer to the ideal design that you may have in mind if you were able to rewrite.

This is hard work. It's always tempting just to hack in new changes and fixes without making things better but I've found that if you can take the extra time to add some unit tests as you go then you can slowly move even the worst 'big ball of mud' application towards something that is easier and safer to extend and maintain.

I'd start with the following approach:

1. Produce a high-level report on what you think is wrong with the current system and get buy in from the project sponsors. Ideally you'll be able to point out that the delays in fixing 'simple bugs' or adding 'tiny new features' are due to X problem or Y design issue. You need this because improving things takes time and you need to be able to remind the people in power why the extra work is required. You'll possibly need to remind them regularly...
2. Ensure that everything is under source control and that you have a repeatable build and release procedure.
3. Begin adding unit tests as you make all future changes; this will initially take more time than simply hacking in a fix - the first few tests for each subsystem will probably take a substantial amount of time to get in place as you'll most probably need to fight with the code a bit to get it into a test harness. Persevere it's worth it in the end.
4. Release the changes to real users, if you can. The shorter your release cycle the more sure you are that you haven't inadvertently broken anything whilst making your last set of changes. If you HAVE broken something, add more tests and fix it.
5. Goto 3

Once you get more tests in place you will be able to confidently refactor more of the application. The tests will make sure that you don't break the existing functionality and will support you as you change things. The good thing about working this way is that you'll gain an understanding of how the existing design hangs together (and assuming that it's currently providing business value then you're doing so without destroying value).

I worked on a system in this way for a client back in 2003 and wrote some blog posts about various aspects of it, they may be of interest and an index of these posts can be found here if you're interested: http://www.lenholgate.com/archives/000220.html