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?

Community
  • 1
Ghlouw
  • 444
  • 4
  • 4
  • 30
    You always, always, always severely underestimate the work needed for rebuilding an application. –  Sep 19 '11 at 12:12
  • See also [these](http://stackoverflow.com/questions/653182/refactor-or-rewrite) similar [questions](http://stackoverflow.com/questions/35233/rewrite-or-repair) on StackOverflow – MarkJ Sep 19 '11 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 Sep 19 '11 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. – Davy8 Sep 19 '11 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 Sep 20 '11 at 11:17
  • See Joel's "Things You Should Never Do, Part I" joelonsoftware.com/articles/fog0000000069.html – Mawg says reinstate Monica Jun 02 '15 at 12:51

8 Answers8

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".
Community
  • 1
Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • 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 Sep 19 '11 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 Sep 19 '11 at 12:18
  • 3
    @Péter Török: I would! Link!? Link! ;) – Steven Evers Sep 19 '11 at 13:31
  • 1
    @SnOrfus, you should only read that after careful consideration... –  Sep 19 '11 at 14:13
  • I think this link does a good job of summing up your point http://programmer.97things.oreilly.com/wiki/index.php/Before_You_Refactor – Spencer Rathbun Sep 19 '11 at 15:10
  • 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 Sep 19 '11 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 Sep 19 '11 at 16:40
  • @Warren, "It's not hard to write unit tests"? Great! I can send you a few classes from our legacy app which I find somewhat problematic to unit test, please show me how easy it really is ;-) – Péter Török Sep 19 '11 at 17:43
  • @Yam, it is a great book indeed. Lack of automated tests *in itself* is not an excuse, noone said it was. – Péter Török Sep 19 '11 at 17:45
  • You should edit your post then because it was clear to me that you stated otherwise. By the way - I agree, it's still not easy - that's why there are about 300 examples in the book for refactorings. But it could still be worth the effort, for some of Joel's points. – Yam Marcovic Sep 19 '11 at 18:26
  • @Yam, above I wrote in bold, right after the list of causes: "If all of these applies to your case, you probably have a reason to rewrite from scratch." - IMHO this is clear enough. – Péter Török Sep 19 '11 at 19:02
  • 1
    Oh right. "Above" was the problem - it's below. Consider actually putting it above as it communicates your point more clearly. – Yam Marcovic Sep 19 '11 at 19:29
  • @Yam, you are right, thanks for the feedback. Fixed :-) – Péter Török Sep 19 '11 at 19:52
  • +1 for rewriting in chunks and +1 for it's going to take a lot more time, effort and pain than anticipated. I would say even if you anticipate it :-) – keuleJ Sep 19 '11 at 20:06
  • @Peter - I have no doubts that you have some code that is not unit testable. You should note those are untestable, and some day, refactor them so they are easily unit testable. That is of course, the point. – Warren P Oct 13 '11 at 20:52
  • 1
    @WarrenP, no offense but it sounds like you haven't seen legacy code yet. In such code not just some, but *most* of the code is not unit testable. And how do you refactor without unit tests? – Péter Török Oct 13 '11 at 21:17
  • @WarrenP, I agree with Peter: When the code contains hundreds of huge monolithic functions, highly coupled in a tangled spaghetti of undocumented connections (combined with stratified layers of unused boneyard code), creating unit tests can be more demanding than a re-write – kmote Feb 06 '14 at 23:25
  • Okay let me rephrase. I have read "Working Effectively With Legacy Code", and I have grappled with un UNIT testable code. Getting code "more under Test than it is today" and getting it completely "under unit test" are sometimes two different things. It is always possible to make progress towards having some testability, at a UNIT or Integration level. It is NOT always possible to survive a rewrite. – Warren P Feb 10 '14 at 14:10
  • @WarrenP, fully agreed, that's basically the point I was trying to make above :-) – Péter Török Feb 17 '14 at 11:56
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).

  • 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 Sep 19 '11 at 13:35
  • @jfrancarr - yep, we're still on XP. Windows 8 may be out before we switch. The powers that be see no reason to upgrade, they play with their iPads half the time anyway. – JeffO Sep 19 '11 at 14:03
  • 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 Sep 19 '11 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. –  Sep 19 '11 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 Sep 19 '11 at 16:41
  • 3
    @WarrenP, it may be quite reasonable given that these can do Win16 programs that cannot run under 64-bit. –  Sep 19 '11 at 18:42
  • @ThorbjørnRavnAndersen - I would say that this is becoming less of a problem than it once was, with VMs and the like, expecially if the application is not intensive. It was a big problem in DOS->Win transition->Win32 transtition however. – Rook Sep 19 '11 at 21:35
  • I support a VB6 application (and I'm in the process of upgrading it to .NET). My development machine is a Windows 7 x64 machine. I run the VB6 IDE on it with no issues. Google has lots of hints about how to tweak the IDE to make it work better under Vista/7, but it does work. – Scott Whitlock Sep 20 '11 at 00:18
  • @Scott have i understood it correctly in that this is not a trivial thing to dó? –  Sep 20 '11 at 05:32
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.

Daniel B
  • 6,184
  • 1
  • 22
  • 30
  • +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 Sep 19 '11 at 16:04
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.

c0da
  • 1,526
  • 3
  • 12
  • 20
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.

Danny Varod
  • 1,148
  • 6
  • 14
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.

CaffGeek
  • 8,033
  • 5
  • 32
  • 38
-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.

Nicholas Smith
  • 1,621
  • 10
  • 11
-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.

Coder
  • 6,958
  • 5
  • 37
  • 49