Justifying Code Rewrites?

snow70 asks: "It seems that it is getting harder and harder to justify the decision to re-write rather than hack/patch away on a flawed code base, given the economic situation and the drive to squeeze every last drop out of an existing code base. Are the readers aware of any research articles or reports that extoll the benefits of re-writing in terms of the cost savings in maintenance and support ?" This topic was discussed two years ago, but I think many people who'll find themselves in this situation would also benefit from any research articles or publications as snow70 requests.

Comments

Hate to be the heretic...

[Violet Null]

But it's been my anecdotal experience that unless there's a real, justifiable reason for the code rewrite, then it's usually not worth it. Something like taking a client/server application and making it a web application requires a rewrite as a matter of course, for instance, but otherwise the costs and time tend to outweigh the benefits.

Sure, a code rewrite allows you to remove bad architectural assumptions and dump the cruft, but it also introduces the possibility of an exponentially higher number of bugs. So you've dumped a fair amount of developer work in the rewrite, and then it needs to be followed up with an even more massive amount of QA work. And, if you're actually making sweeping architectural changes, chances are very high that the new architecture will pose some unforeseen problems of it's own.

I'm not saying a code rewrite is never a good thing, but, IMHO, it's not something that should be done just because "this code is nasty" or "language X is cooler". If you can't think of a reason as to why a rewrite should be done, then it shouldn't.

Re:Hate to be the heretic...

[sporty]

It depends on the scale of the rewrite. Rewriting your OS would suck. Rewriting a single library and fixing things via refactoring methods.. it's not that bad.

-s

It's good that rewrites are hard to justify!

[JonRock]

Point one: rewriting from scratch can be a strategic disaster.

Point two: rectifying a "flawed" code base can be done within the framework of good software engineering practice, and is a very marketable skill besides.

Re:It's good that rewrites are hard to justify!

[Cuthalion]

Gee, it only took them like 5 years. Could they have made Netscape better in 5 years without starting over from scratch, during which time they lost the browser war and were acquired by AOL? Is Netscape, as a company, successfull?

I would say the answer is no.

Refactor

[MountainLogic]

Refactor, don't rewrite! First write unit & functional tests then start refactoring.

Re:Refactor

[__past__]

As you say, refactoring relies on having good tests in the first place. Probably a code base that needs a rewrite hasn't been developed test-first up to now, or even in a test-friendly fashion, so that's a huge problem - coming up with good tests after the fact is a lot of error-prone (and boring) work.

It's probably still a better idea than to start from scratch, though. I seem to remember that someone announced a book on this subject (adding tests for legacy code) on the XP or test-driven mailing list, maybe the original poster should look there.

not B&W

[NanoGator]

Sorry to say this, but we don't live in a perfect world. As long as management bases their timelines on when the next trade show is coming up, we're not going to see rewrites happen until one of these deadlines is very badly missed. The people in charge just plain don't care about flawed or badly maintained code bases. They're concerned with getting a product that meets the promises that Marketing made. Sadly, engineers are too good at working within their limitations, thus making rewrites not all that necessary. (As in "we can't launch unless we do that" necessary.)

I don't think finding articles that show off the wonderfulness of code rewrites will be useful at all. Instead, this topic needs to be made attractive to PHBs out there. Make "total rewrite" a buzzword (you know, like e-commerce, push technology, and multi-media) and you'll gain a lot more leverage than landing a report labeled FYI on your boss's desk. Make it fashionable.

You all may thing I'm being cynical or even sarcastic, but I've spent the last 6 years watching PHB's work. I've listened to some bizarre rationale. I understand enough about how they work that I could become a cartoonist. I'll be happy to carry the torch when Scott Adams retires.

Things you should never do...

[metacosm]

Rewrite is one of them... Read: Things you should never do

Let me quote a little from the linked article

When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.

First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code.

A second reason programmers think that their code is a mess is that it is inefficient. The rendering code in Netscape was rumored to be slow. But this only affects a small part of the project, which you can optimize or even rewrite. You don't have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang.

Third, the code may be doggone ugly. One project I worked on actually had a data type called a FuckedString. Another project had started out using the convention of starting member variables with an underscore, but later switched to the more standard "m_". So half the functions started with "_" and half with "m_", which looked ugly. Frankly, this is the kind of thing you solve in five minutes with a macro in Emacs, not by starting from scratch.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

Re:Things you should never do...

[ClosedSource]

Any kind of advice that says "Always do.." or "Never do.." is going to be wrong at least some of the time. To state the obvious: not all situations are the same, so you can't treat them as if they were.

One reason you might want to rewrite a program from scratch is if the effort to understand the code is significantly greater than the effort to understand the problem you're trying to solve. Of course, requirements are an important part of the analysis. If legacy behavior is a requirement (which will typically include behavior that has nothing to do with the actual problem), then that argues against rewriting since you're going to have to reverse engineer the system anyway.

One should also consider the "do nothing" option. Perhaps the benefits are outweighed by the costs and risks of development.

Re:Things you should never do...

[dubl-u]

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

That's true only if you don't plan to do anything differently.

I recently got called into consult on a project. They have a bunch of code. They need new features by August. Question #1 is, "Do we start over?"

The current code base mostly works, but it is complete spaghetti code. No architectural coherence, hugely inefficient, absolutely no tests, lots of copy and paste, insane use of exceptions, etc, etc, etc. My first conclusion is that the existing code is totaled.

But there isn't time to rewrite it all by the deadline and get the new features in. So we compromised with the businesspeople. Working together, we designed the new features in such a way that we touch as little of the old code as possible. Features that required modifying old code got very high estimates, so the suits deferred most of them. Further, all new code will be developed with full unit tests and functional tests, with energetic refactoring so that the architecture is solid. This gives us a good foundation to build from.

Then, after the release, we'll see what we can do with the old code. Thanks to a highly interactive estimation process (XP's Planning Game), the business people really get that touching old code is expensive. And we've also explained that hacking new stuff into existing code is throwing good money after bad; when asking for those features, they frequently ask how much of the effort can be reused. So they're almost as interested in getting rid of the old stuff as we are.

So my tips for a rewrite are:

1. Don't rewrite everything at once. Do it in a way where you can provide a stream of new releases, rewriting as you go.
2. Make the economic case for a rewrite clear. If you're getting a paycheck for this, you're obligated to help them get the best value for their money.
3. Don't do the same old thing. Figure out why the current code base sucks, and take clear steps not to repeat their errors. E.g.,
   • write unit tests and functional tests (preferrably before you write the code)
   • continuously refactor your code
   • do code reviews and design reviews (or, better, pair programming).
4. Measure the difference you're supposedly making. If your bug rates, design metrics, code metrics, reliability of hitting estimates, and performance aren't clearly better than the existing product, then maybe you're doing a rewrite for the wrong reasons.
5. Be humble. The reason the current code base sucks is that the last chumps got in over their heads. Be sure that you aren't doing the same. Remember, they probably looked at the previous old system and said, "Gosh, we could rewrite this and make it so much better!"
6. Make sure this is the last rewrite. Sure, future requirements always mean that parts of the app will be changed. But make sure the code never gets so stinky that it needs to be tossed. Every couple of months call in somebody from outside the team to review things and give you an honest checkup.

Refactor

[neitzsche]

I am a sold on the concept of refactoring instead of completely rewriting.

About four years ago, I rewrote a 15 year old device handling sub-system. It was quite horrible. The primary justification for doing it was to generate billable hours to charge the government. The secondary justification was because the old code was horrible, nightmarish and impossible to maintain.

Unfortunately, I didn't get the opportunity to redesign the legacy file structures it used. I also had to maintain 100% backward compatability. On my personal agenda was adding useful features. In hindsight, if we had used the refactoring approach the end result would probably hve been better. Certainly the beta testing would have gone smoother if it had been done in smaller increments. (Having a non-technical manager didn't help either.)

With that experience behind me now, I recommend two things to justify a major piece of work (either rewriting or refactoring):
1) Identify the current design flaws
2) Identify the features missing

These days, the only time I'm presented with a rewite opportunity is when an application is being migrated to a new platform. i.e. Web enabling a legacy app. The only applications that remain out there are still there because they are too ugly, outdated and nightmarish to maintain. So once again, I would recommend refactoring.

Don't be mad at management for being gun-shy when they hear the word "rewrite." They should be leery of a major rewrite. The end-user training costs alone can be devastating. And unless we're talking about your own personal copyrighted intellectual property, they do have a lot vesting in the old "ugly" code that they (rightly) should be scared of losing.

Typical geek. Focus on the business problem.

[(H)elix1]

I'm not going to touch the refactor/rewrite issues, because the fundamental problem is you are not effectively giving yourself enough time to do whatever the hell you want to do. Take what time you think it will take to implement something, double it, and round up to the next unit of measurement. Odds are the business does not give a rat's ass about the wrong or right way to implement something anyhow. Why confuse them with options?

How long will it take to fix this? (keep the snicker internal) Two weeks...

If the

[geekoid]

author looked at the code I inherited, he would change his point of view.

We got a function thats 16 hundred lines long(not countinf white space and comments), it has 5 goto's.

The person who wrote the code was a self taught programmer. the next person was a self taught programmer with no experience in the language.

The use 3rd part controls that leak like a sieve.

there is redundant code all over the place. Comments are lacking.
there is stuff like:

If (X = 1) and (X = 1) then

and stuff like

while .eof
if .eof then ...
loop

Nothing is generic, so swapping aout the major 3rd party control would entail change 95%
there a 75 forms, 25 of them identicle.

Use of the database is incorrect, we got dirty reads happening all over the place.

This code might be salvagable if there was a design spec in the begining, or any documantation for that matter.

When it was written there where no specs, and the people working on it had little experience with the industry.