28

Possible Duplicates:
When is a BIG Rewrite the answer?
Have you ever been involved in a BIG Rewrite?

I am at a customer where I have been tasked to fix a number of issues they have in their existing systems. These systems are all quite old and was built in older technologies to really low development standards.

All of this makes it quite difficult and frustrating to properly maintain these systems, because of the two thoughts that often come to mind while working on this:

  • A. It would have been so much easier / quicker to do this in one of the newer technologies.
  • B. I would not have coded this feature like this. There are many better ways to design this application to make it more maintainable and better performing. (examples are bad OO design, code is often repeated, settings are hard coded, etc.. the list is long).

So under the circumstances I try to make the best of it and fix everything to the best of my ability without complaining too much, but my question is now:

How do you decide when it is time to rebuild a system with newer technology, versus keeping on plugging holes in an old one? And how do you make a case for rebuilding? How can you persuade the powers-that-be it is necessary to rebuild the system?

Improve this question
6
  • 30
    You always, always, always severely underestimate the work needed for rebuilding an application.
    – user1249
    Commented Sep 19, 2011 at 12:12
  • See also these similar questions on StackOverflow
    – MarkJ
    Commented Sep 19, 2011 at 15:59
  • 1
    Customers will keep a system running for as long as they can afford to hire somebody to maintain it. Yes, there are businesses that STILL run MSDOS apps on MSDOS computers. Don't want to do it? Raise your rates until it is not worth it them and they find another guy-- or maybe they will re-consider your offer to re-write.
    – Angelo
    Commented Sep 19, 2011 at 16:15
  • 1
    +1 to @Thorbjørn's comment. Learned it the hard way despite reading Joel's article about never doing it. You think you know exactly how it's going to work because you've built it once, so it should be easy to do again. Except you want to write it "better" and that apparently takes longer than the original despite knowing what you're doing now.
    – David Ly
    Commented Sep 19, 2011 at 17:45
  • 1
    @Davy8: Fred Brooks called that "the second-system effect", the desire to put in all the possibilities you passed over the first time around. Of course, he also said "plan to throw one away; you will anyhow". The trick is to throw the first away without getting caught up in the second-system effect.
    – Dave Sherohman
    Commented Sep 20, 2011 at 11:17

8 Answers 8

Reset to default
39

It is a tough call.

Obligatory Joel reference: Things You Should Never Do, Part I

That said, there are of course cases when it is still better to rewrite from scratch than to keep fixing the fundamentally broken. If all of the following applies to your case, you probably have a reason to rewrite from scratch:

  • there are no automated tests,
  • the original project team is gone, and noone knows how the product is implemented, thus making any changes is incredibly difficult and results are unpredictable,
  • the product is so low quality that replacing it with a new, necessarily bug-fraught implementation would not make a major difference,
  • the technology used is obsolete, and there is a pressing need to replace it with something new (e.g. in order to enable some desired major feature, or to deploy it on a new platform - @Thorbjörn's answer contains a good example for the latter).

(If only some of these applies... well, that's the tough one to decide, and there is no general answer there.) At any rate, you would also need the following conditions to give you at least a chance of making such a move successful:

  • time-to-market is not an issue - customers are patient enough to wait a looong time for a promised, fundamentally better version and there are no competitors,
  • there exists live, detailed knowledge (ideally in well written specifications, but also in several people's heads - and these people are accessible to answer developers' questions) on how the damn thing should actually behave in any specific situation,
  • management is at least open to the idea, and ideally they understand the potential costs vs benefits.

All in all, you must take into account that a complete rewrite from scratch is going to take a lot more time, effort and pain than anticipated. So if you can, try to partition the job into smaller chunks, to replace only modules/components of the old code one by one. This way

  • you can start by building a suite of regression tests around the existing program, which then make it much easier to preserve (and if necessary, improve) the old functionality with the new code,
  • you will have a working, up-to-date program most of the time (thus way happier users and management),
  • you may save rewriting (potentially significant) parts of the code which do not need to change and "just work".
Improve this answer
19
  • 7
    I think the Joel article shouldn't be taken as seriously as many in the industry do take it. Surely he doesn't believe there is no justification for a rewrite, just that he makes a good case for doing it only after careful and scrutinous evaluation of the situation at hand. He is against rewrite happy developers as we all should be but some sometimes polishing a turd will not get the customer to buy a turd.
    – maple_shaft ♦
    Commented Sep 19, 2011 at 12:12
  • 9
    @maple_shaft, I fully agree. He often likes strong wording and provocative statements, which of course make a bigger splash. How many of us would have read the same blog with a title like "Things You Should Do Only Rarely, After Careful Consideration of All Pros and Cons"? :-)
    – Péter Török
    Commented Sep 19, 2011 at 12:18
  • 3
    @Péter Török: I would! Link!? Link! ;)
    – Steven Evers
    Commented Sep 19, 2011 at 13:31
  • 2
    Even when there are no automated test, this is no excuse. Check out the book "Working Effectively With Legacy Code" by Michael Feathers
    – Yam Marcovic
    Commented Sep 19, 2011 at 15:35
  • 3
    It's not hard to write unit tests, ergo, the "no unit tests, ergo rewrite, Joel said so himself", is pure BS.
    – Warren P
    Commented Sep 19, 2011 at 16:40
3

How do you decide when it is time to rebuild a system with newer technology, versus keeping on plugging holes in an old one?

With businesses, it usually boils down to money. Their purpose is to make money, and they tend to think in terms of it. If it makes more sense, financially, to do a rewrite, then it's a strong indication that you should go ahead (and, hopefully, that you've considered many different sides to the equation).

Beware though, as many others have pointed out, developers tend to underestimate heavily. Also, it's usually not quite as simple as "it will cost X to rewrite, Y to fix, and X < Y"; you might need to think in terms of licensing, risk of a new implementation, risk of the old implementation, missed business opportunities (all of these can pretty much be expressed in terms of money), documentation, training, and many more. What seems like a good idea one minute might not seem so great if you take a step back and think about it for a second.

And how do you make a case for rebuilding? How can you persuade the powers-that-be it is necessary to rebuild the system?

This follows pretty simply from the above - you make a case by showing an estimated difference in cost between the two solutions, over time. Yes, you are definitely sticking your neck out when you do this, but if you're going to make recommendations that have a large financial impact, you should not do so lightly.

Improve this answer
1
  • +1. Assess the risk of underestimation too. Errors of 1000% are not uncommon when estimating large projects (a rewrite of a large program is a large project). Consider whether the rewrite will pay off if the time and money are significantly greater than originally estimated.
    – MarkJ
    Commented Sep 19, 2011 at 16:04
3

A good one to prompt a rewrite is when the implementation technology is not supported anymore.

I recently had the experience that Windows 7 (64 bit) explicitly said that it disliked the Visual Basic 6 installation cd when inserted. We used that as a strong hint that it was time to port our VB6 applications (to Java as that is what we do).

Improve this answer
9
  • 2
    I've seen the opposite with VB6. It drives companies not to upgrade to Windows 7 and stick with Windows XP because of these kinds of problems. Adding the cost of a re-write on top of the company-wide OS upgrade is too much.
    – jfrankcarr
    Commented Sep 19, 2011 at 13:35
  • 1
    So the VB6 IDE is unsupported. You only need to keep it working on a few development PCs, using any means necessary (e.g. virtual machines). The runtime is still fully supported. I do not find this a compelling argument for a rewrite.
    – MarkJ
    Commented Sep 19, 2011 at 16:03
  • 1
    @MarkJ as always it depends. We didn't have any VB6 experts around, and a major change was needed. I didn't pop in the installation cd just for fun.
    – user1249
    Commented Sep 19, 2011 at 16:08
  • 1
    Microsoft recognizes you using an old tool, and pops that kind of warning up. They do it with Delphi 7 too. I think it's hilarious.
    – Warren P
    Commented Sep 19, 2011 at 16:41
  • 3
    @WarrenP, it may be quite reasonable given that these can do Win16 programs that cannot run under 64-bit.
    – user1249
    Commented Sep 19, 2011 at 18:42
1

Someone once commented Premature optimization is the root of all evil on one of the questions that had asked. You can never build a completely optimal solution to a problem. Certainly, correcting somebody else's code is one of the most frustrating tasks when you that you could have coded better.

But with reference to that, if you find yourself changing the source code too often, maybe you need to be stop being quiet about it. :) If you're the only one maintaining it and if the technology is completely outdated, if newer (and better) alternatives are available, if the holes are too much, you may very well talk to your higher authorities about the same. I see no point in keeping on plugging holes when you can actually rebuild the same.

Improve this answer
1

Rewriting an application at some point is a necessary decision. Leaving stale code can mean nightmare for maintenances - for fixing bugs and adding new features. An application never ends up doing only what is was originally designed for and the environment it was designed never remains the same.

The real question is "How to rewrite it?"

If the original application was written in a truly modular manner it can be rewritten in phases.

If it was not (which is often the case with legacy systems), then the development must be branched, were one branch keeps struggling with upgrading the old systems and another creates a new one. This requires more investment, but it keeps the company alive without leaving behind.          The optimal solution is to try and develop components for the new application that with some effort may be integrated into the old one, so that the new development will somewhat contribute to the old system.

Some guidelines to prevent reaching a situation were the entire application must be rewritten with no option of integrating new code into it:

Design and write modular code, use dependency injection.

Refactor your code often, do not write work arounds on work arounds.

Use clear coding standards, give good names in correct English, do not use Hungarian notation.

Write external documentation and internal documentation, do not auto generate it.

I can not emphasize enough the importance of fully automated unit tests, integration tests, & system tests to enable updating of both existing modules and future updating of new modules.

Improve this answer
0

The proper, and safest approach is to isolate your changes.

First, determine where the new fix needs to be made. Write tests around this functionality. Break that functionality out into a new application in the newer language/framework.

Yes, you have a split system. But, you've fixed the system, cleaned up a small portion. Modularized your system. And added tests to ensure the fix is correct.

Any future bug fixes/features get handled the same way. In the end, the original app is gone. Leaving a nice clean new system, full of tests.

Improve this answer
-1

When it gets to a stage that the fixes you're repeatedly making are as time consuming as redeveloping the program then you can start thinking about it. You've got to of course factor in the time for testing/Q&A but if you think that it's becoming a time sink then it's definitely worthwhile considering it.

Improve this answer
-1

When the whole base architecture, framework or foundation is incompatible with new business requirements.

IMHO, core changes are the only ones when you start from scratch. And expect them to be expensive.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.