Take the 2-minute tour ×

I work in a pretty reknowned MNC, and the module that I work in has been assigned to a new "lead". The code base is pretty huge (~130K or more, with inter dependencies on other modules) , but stable - some parts have grown ugly over the years, but its provably in working state. (Our products are running for years on them, even new ones). The problem is, our lead wants to rewrite the code from scratch, to encompass "finer granularity and a proactive design".

I know in my guts thats not a very good idea, but how do I convince him/the rest of the team(who are pretty much more senior than me in terms of years of exp), without sounding too pedantic myself (Thou shalt not rewrite , as Joel et al have clear articles prohibiting it)?

I have a good working relation with the person concerned, and don't want to ruin it, but neither do I want to be party to a decision which would surely plague us for years to come !! Any suggestions for a milder,yet effective approach ? Even accounts of how you have tackled such a situation to your liking would help me a lot!

EDIT: The code base I'm talking about is not a product/GUI, but at kernel level with all the critical functionalities for our product. I hope now you know why i sound so apprehensive !!

share|improve this question

migrated from stackoverflow.com Mar 15 '11 at 14:20

This question came from our site for professional and enthusiast programmers.

just to make sure, before giving you this kind of advice... Are you doing a lot of evolution/maintenance work on this piece of code (and end up spending a lot of time fixing regression errors)? Do you need to add new functionality but you can't because you would need to touch on the "ugly" parts of your code? I think rewriting is not ALWAYS a bad idea... –  paolo Mar 15 '11 at 14:07
@paolo - nope, the codebase is working fine (i wish I could name our products, you're probably using it :) ). There are bugs for some customers, but no major hacks in the code(except when we have to cover-up for HW flaws !!) –  TCSGrad Mar 15 '11 at 14:36
There are many pros and cons on c2.com/cgi/wiki?RewriteCodeFromScratch –  k3b Mar 16 '11 at 5:49
130k of kernel code as it is, with the drivers being fine granularity and proactive design. Is it sufficiently challenging or near impossible to implement/interface new devices or protocol? Would the result of the intended changes make it substantially easier for customers/downstream users? –  JustinC Mar 16 '11 at 6:02
Customers won't feel a thing - the interfaces are pretty simple and robust enough. What the intention was, as I had determined, was to reduce "reading complexity of code". IMHO, that's a pretty subjective view...if you rewrite the whole code from scratch, it would of course be easier for you to read - but what about the new engineers, who'd have to read through both anyway!! –  TCSGrad Mar 16 '11 at 6:18

7 Answers 7

up vote 8 down vote accepted

Do the math with him together:

On the debt side:

  • how long will it take to recreate the features you have right now. How much does that cost that (devs + overhead)

  • how much will the company lose for not being able to deploy any new features/bugfixes or only at a much slower rate?

  • what's the risk of not being able to complete the rewrite and falling back on the current source base after n-months? Including the risk of killing the product all together.

  • How long will it take until the new code base looks just as ugly as the current one?

On the asset side:

  • how much better will be the code be after the rewrite (measured in saved maintenance costs per month)

Add it all up, possibly doing a best/worst case scenario comparison.

At the end you'll have an answer. If he ignores the answer, talk to his boss.

share|improve this answer
Great enumeration !! I'd add them to my meeting notes !! –  TCSGrad Mar 15 '11 at 14:37
You'd think this was the way to go but it's crazy how you'll over-estimate the time it takes to put in new features in the old code base while simultaneously under-estimate the time it'll take to get the "new" code base up to the feature list of the old. –  wheaties Mar 16 '11 at 4:11
Great Points It would be Good to Actually get these estimations from all the developers involved So every one gets a clear picture. –  Aditya P Mar 16 '11 at 5:00
@wheaties That of course is a problem with every estimate. The way to fight that is to repeat the estimate often and compare it with actual progress. (Think Product Burn Down) –  Jens Schauder Mar 16 '11 at 7:41
quite often the 'asset' of new code is no better than what it replaced - especially after a few iterations of enhancement and maintenance. IMHO total rewrites are never the best idea. –  gbjbaanb Apr 14 '11 at 21:06

Obligatory: Things You Should Never Do, Part 1 (You've seen it, but in case anybody finds this question and hasn't.)

Re-writing from scratch is very tempting for developers. Nobody wants to work on legacy code, everybody wants to write sexy new code. But at the end of the day it's about what's best for the business. Why is a re-write needed? Can they present that case in a clear way which demonstrates added value to the business?

You shouldn't have to convince them not to spend resources. They should have to convince the company to spend resources.

share|improve this answer
I love that article. I hate rewriting things! –  Mark Canlas Mar 15 '11 at 14:27
@Mark Canlas: It's kind of funny actually, because I'm often a proponent of re-writing. I hate legacy code :) But I also understand that if I can't demonstrate added value to the business, the re-write shouldn't happen. My opinion needs to be backed by numbers. –  David Mar 15 '11 at 14:30
I hate legacy code as well, but since reading that article, I've learned to value running ships versus theoretical ones. A broken, running ship is generating more money per hour than a hypothetical one penciled on a napkin. It's a balancing act! –  Mark Canlas Mar 15 '11 at 15:50
@Mark Canlas: Absolutely. And that's where a lot of developers (even very experienced ones in many cases) lose their grip on the overall business. It has to have actual tangible value for the business, and very often the existing product has that value. Though one argument I always hate from the business is "we already spent money on this, so we need to use this." Sometimes, as in the case of my last job, a decision like that drives them into the ground. It's neither "always re-write" nor "never re-write." As you said... balance. –  David Mar 15 '11 at 16:14

How well does your testing approach cover the code base? How about unit testing?

If it is not alreayd there, suggest that any code only be rewritten one section at a time and that any section under rewrite have nearly complete (90%+) unit test code coverage. Once you do this, you will have defined a part of the code that both is well-defined (we could test it) and also has a known interface.

At that point, rewriting that code is much lower risk. Mistakes should be caught by unit tests/other tests, and assuming you also have source control can easily be reverted.

Taking the rewrite in smaller chunks also allows both you and your team lead to more accurately have a feel for a complete rewrite. Do you both know what you are getting into? Are one of you too pessimistic/optomistic?

share|improve this answer
130k of kernel code as it is, with the drivers being fine granularity and proactive design. Is it sufficiently challenging or near impossible to implement/interface new devices or protocol? –  JustinC Mar 16 '11 at 6:03

There are some relevant factors to consider:

  • The fact that it's working the way the users want is an indication to refactor rather than rewrite
  • If you have unit tests, definitely refactor rather than rewrite. If you don't, then that levels the effort between refactoring and rewriting (assuming your goal is to have unit tests for the resulting system). If you don't have unit tests, and all the code is in the GUI layer, it could be faster to rewrite, especially if the functionality is mostly broken anyway. That's my experience.
  • If your goal is to completely change platforms (unmanaged code -> .NET or Windows -> Linux or PHP -> python, etc.) then that's an obvious argument in support of rewriting.
share|improve this answer
Nope, we don't have unittests. –  TCSGrad Mar 15 '11 at 14:53
Its unlikely the new one would have it as well, seeing the amount of work it already involves. Also, the code base I'm talking about is not a product/GUI, but at kernel level with critical functionality for our product. I hope now you know why i sound so apprehensive !! –  TCSGrad Mar 15 '11 at 14:54
@shan23 - why would you start a rewrite and not at least maintain an acceptance test suite? You'll just end up creating the same mess. The fact that it doesn't have a GUI just makes it that much easier to test! –  Scott Whitlock Mar 15 '11 at 14:57

Just say "NO." Be convincing, but be willing to say "You are not only incorrect about its benefits, but you are wrong because it is wasteful of human effort."

share|improve this answer

Where is the business case for a rewrite? You have a code base that is filling a need. Granted, it may not be perfect, but it represents a substantial investment in terms of time and resources. The only time that a complete rewrite is warranted is when the code quality is so bad that it is causing one's organization to lose money or business opportunities. One needs to remember the old adage, if it ain't broke, don't fix it!

share|improve this answer
I have to give this a downvote because that saying is the single worst thing in our industry; it fosters laziness, incompetence and slothful behavior in developers because nobody has the balls to address a problem properly because "it works" in some small capacity. –  Wayne M Apr 21 '11 at 14:45
@WayneM: "the rewrite" option is the worst one, too often its due to ego and incompetence among devs who can't work with existing code. They want torewrite is cool new stuff, and end up making worse mistakes in their misguided attitude that they ae so much better than the guys who did the last stuff. Only when old code has evolved over a lot of time (or was crap to start with) should you rewrite, and even then a serious refactoring should be considered first. –  gbjbaanb Jul 22 '11 at 9:42

Buy as many shorts on the stock as possible. If management agrees to commit suicide, at least you should make some money from it. After all, you will soon be on the street after they tank.

share|improve this answer

Your Answer


