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

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...
–
paoloMar 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 !!)
–
TCSGradMar 15 '11 at 14:36

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?
–
JustinCMar 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!!
–
TCSGradMar 16 '11 at 6:18

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.
–
wheatiesMar 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 PMar 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 SchauderMar 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.
–
gbjbaanbApr 14 '11 at 21:06

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.

@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.
–
DavidMar 15 '11 at 14:30

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 CanlasMar 15 '11 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.
–
DavidMar 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?

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?
–
JustinCMar 16 '11 at 6:03

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.

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 !!
–
TCSGradMar 15 '11 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 WhitlockMar 15 '11 at 14:57

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!

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 MApr 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.
–
gbjbaanbJul 22 '11 at 9:42