8

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 !!

Improve this question
5
  • 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, 2011 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, 2011 at 14:36
  • 1
    There are many pros and cons on c2.com/cgi/wiki?RewriteCodeFromScratch
    – k3b
    Mar 16, 2011 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, 2011 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, 2011 at 6:18

7 Answers 7

Reset to default
8

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.

Improve this answer
4
  • 3
    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, 2011 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, 2011 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, 2011 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, 2011 at 21:06
13

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.

Improve this answer
2
  • 2
    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, 2011 at 15:50
  • 1
    @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, 2011 at 16:14
8

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?

Improve this answer
1
  • 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, 2011 at 6:03
2

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.
Improve this answer
3
  • Nope, we don't have unittests.
    – TCSGrad
    Mar 15, 2011 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, 2011 at 14:54
  • 1
    @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, 2011 at 14:57
0

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."

Improve this answer
0

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!

Improve this answer
2
  • 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 Molina
    Apr 21, 2011 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, 2011 at 9:42
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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