Lessons From Six Software Rewrite Stories (medium.com) 118
A new take on the age-old question: Should you rewrite your application from scratch, or is that "the single worst strategic mistake that any software company can make"? Turns out there are more than two options for dealing with a mature codebase. Herb Caudill: Almost two decades ago, Joel Spolsky excoriated Netscape for rewriting their codebase in his landmark essay Things You Should Never Do . He concluded that a functioning application should never, ever be rewritten from the ground up. His argument turned on two points: The crufty-looking parts of the application's codebase often embed hard-earned knowledge about corner cases and weird bugs. A rewrite is a lengthy undertaking that keeps you from improving on your existing product, during which time the competition is gaining on you.
For many, Joel's conclusion became an article of faith; I know it had a big effect on my thinking at the time. In the following years, I read a few contrarian takes arguing that, under certain circumstances, it made a lot of sense to rewrite from scratch. For example: Sometimes the legacy codebase really is messed up beyond repair, such that even simple changes require a cascade of changes to other parts of the code. The original technology choices might be preventing you from making necessary improvements. Or, the original technology might be obsolete, making it hard (or expensive) to recruit quality developers.
The correct answer, of course, is that it depends a lot on the circumstances. Yes, sometimes it makes more sense to gradually refactor your legacy code. And yes, sometimes it makes sense to throw it all out and start over. But those aren't the only choices. Let's take a quick look at six stories, and see what lessons we can draw.
For many, Joel's conclusion became an article of faith; I know it had a big effect on my thinking at the time. In the following years, I read a few contrarian takes arguing that, under certain circumstances, it made a lot of sense to rewrite from scratch. For example: Sometimes the legacy codebase really is messed up beyond repair, such that even simple changes require a cascade of changes to other parts of the code. The original technology choices might be preventing you from making necessary improvements. Or, the original technology might be obsolete, making it hard (or expensive) to recruit quality developers.
The correct answer, of course, is that it depends a lot on the circumstances. Yes, sometimes it makes more sense to gradually refactor your legacy code. And yes, sometimes it makes sense to throw it all out and start over. But those aren't the only choices. Let's take a quick look at six stories, and see what lessons we can draw.
Re: (Score:2)
Try the first link in TFA.
I know, I know -- it does not look like it right one, but it is.
Perhaps that was deliberate? (Score:2)
I disagree (Score:2)
Rewriting an application with proper software design stages IS a way to improve your software.
When you have a large code base including too many corner cases snippets and dirty patches that stick out from it, then it's brine for a rewrite. But only if you carefully learn from the past mistakes.
Re:I disagree (Score:5, Insightful)
If the person recommending the rewrite is the person who wrote the original code, they are usually right.
If the person recommending the rewrite understands the code and has years of experience with it, they are often right.
If the person recommending the rewrite is the new guy fresh out of uni, they are almost certainly wrong.
Disclaimer: I was once that new guy.
Re:I disagree (Score:5, Insightful)
If their title is Manager, or Consultant, they are ALWAYS wrong.
Re: (Score:2)
Re: (Score:2)
If the person recommending the rewrite is the person who wrote the original code, they are usually right.
If the person recommending the rewrite understands the code and has years of experience with it, they are often right.
I would still take it with a large grain of salt. These two groups are also the most likely to lean towards the second-system effect. There needs to be significant objective justification for a complete rewrite, more than just "Bob's gut feeling is that we need a redo".
And yes, even the recent graduate can offer valuable insight since they're most immune to the "we've always done it this way" and the "it's always been this way" symptoms.
Re: (Score:2)
Have to agree there. I've seen that new guy in several places. "Why are you using C+ in your embedded system, there's this new language called Java you should use!", "Well, MY professor said that's the wrong way to do things", "I have a few suggestions for your coding style document", "I saw a goto in the code, who's the proper HR person to report this to?
Re:I disagree (Score:5, Interesting)
I disagree with your disagreement. Rewriting a working application is juggling with a loaded gun. You say "if you carefully learn from past mistakes" but this is almost impossible in any organization I've ever seen. All those snippets and dirty patches are not documented properly. If there are comments, they may (or may not) be out of date. Maybe there is a reason they chose a weird data structure but that guy retired 15 years ago. So you do something "proper" and find it is 10X slower. Oops.
If I've learned anything, I've learned you gotta let sleeping dogs lie. More patients are killed by doctors in this business than anything.
Re: (Score:1)
He didn't retire, he got pushed out so they could bring in a cheaper recent grad or an H1-B.
Re: (Score:3)
Half the time the people who wrote it don't even realize they made a mistake. I've done it myself, looking at old code and thinking "what moron did this?", looking at who made the code commit, and realizing it was me.
Re:I disagree (Score:4, Insightful)
So you rewrite your code with a new sets of corner cases snippets, dirty patches that stick out from it.
The problem is old code while ugly, has been made to work over the decades, you are not going to learn from the past mistakes, because in the rewrite, you will undo years of patching which explains the changes in thought.
Re: (Score:2)
OTOH, each of those patches, especially the ugly ones represent a case of "if I knew then what I know now" for the architect. It MAY be that the problem is inherently warty, or perhaps there is a design based on the much improved knowledge of the problem that can solve it cleanly. If it's the latter, someone else may render you an also ran.
Re:I disagree (Score:5, Insightful)
I do think refactoring is a must and needs to be part of the design cycle, just as much as getting the features that marketing already has sold to customers.
Technical debt is a thing, and getting that heap of hacks, kludges, workarounds, and other junk out of the codebase is just as critical as doing months long sprints to appease marketing. In fact, the Agile cycle in theory has room in between sprints for doing just this and fixing stuff. However, every place I have worked at who tried to do Agile had a "permanent sprint" in place, which not just burned people out, it made code bases which were all but impossible to maintain. Especially with management always threatening to outsource or offshore the devs, to the point where the devs knew they were going to get offshored, so they didn't care about anything except making their deliverables, even if it meant that they left gaping security holes, or just horri-bad code, because that mess would be cleaned up by someone else.
If a company actually values its code base, they will treat it just as they do any other machine... take time to take it down and service it, fix glaring problems, add actually useful code documentation (no comments about "don't touch this routine, we don't know how it works, neither will you.") Then, start seeing if you can do things like performance testing and code optimization, perhaps a pass for security checking (strncopy(), not strcopy(), etc.)
Re:I disagree (Score:5, Interesting)
Technical debt is a thing...
Best place I ever worked knew that, and worked to quantify it. That helps a lot when you're trying to figure out whether or not to refactor. In a couple cases, it became apparent that a partial refactor was going to accomplish something like 90% of a full one, with 10% of the effort.
Quantifying your pain-points with even back-of-the-envelope calculations can really help you make good decisions about how to move forward.
Re: (Score:2)
That is a definite sign of a quality workplace. Places like that are exceedingly rare. In my experience in Agile environments, being able to take time to do anything but code the latest bell or whistle, or try to put out the latest fire, is something that rarely happens, much less having the ability to do any refactoring whatsoever.
Most places don't even bother, because management views refactoring as "reinventing the wheel" at best, a loss of productivity at worst, because they don't see the man-hours wa
Re: I disagree (Score:2)
Oh yes, Agile.
Sounds great until management gets hold of it. Then they turn it into permanent sprints, oversized teams, and basically a micromanagement clusterfuck.
Thereâ(TM)s a clue in that word âoesprintâ. You canâ(TM)t do continuous sprints. Then itâ(TM)s not a sprint. You need a rest period.
Re: (Score:3)
One that that can help is to rewrite in modules. Build the base modules first. You can then migrate customers who only use those modules and are not in an immediate rush to u
Re: I disagree (Score:2)
That is not really a ârewriteâ(TM) as Spolsky meant it. Going from Text to Web is really a new system. âRewritingâ(TM) there means ending in up with a new implementation of the same thinyg for no good reason
Re: (Score:2)
But moving from Text to GUI then later to Web seem like two rewrites.
Don't forget I mentioned the very first rewrite was from Text to Text -- but just much fancier text 'gui' type interface. (no mouse, but much fancier keyboard operation, more curses like, is a way to describe what I mean)
Re: (Score:2)
The snag is that rewriting is not a direct revenue generating operation, so it's usually frowned upon as a waste of money. I know lots of code that really needs rewriting but it can't practically be done. Most likely the people who understand that code have left years ago and never documented anything (the code wouldn't even need rewriting if the original authors were good enough to know to document things clearly).
Don't even start thinking about rewriting until you have clear documenation about what the c
The only unmatintainable code... (Score:1)
Re: (Score:1)
... is undocumented code.
Documentation is often useful to users, but rarely of much use to developers. If your code doesn't make sense without a separate document to explain it, you should be fixing your code, not writing that doc.
Re: (Score:2)
'Clever code' shouldn't be blanket banned. It should be considered and if it's worth it, commented to hell and back.
Re: (Score:2)
'Clever code' shouldn't be blanket banned. It should be considered and if it's worth it, commented to hell and back.
In-line comments are not the same as documentation. But even in-line documentation should not be used as a crutch for poor code.
foo(a, b); // Compute the dot product of the inputs and bias
dotProduct(inputs, bias);
Which is better?
Re: (Score:3)
The best is:
dotProduct(inputs, bias);
Re: (Score:3)
Re: (Score:1)
If your code doesn't make sense without a separate document to explain it, you should be fixing your code, not writing that doc.
The code may make perfect sense for the situation for which it was created, but it may not make sense to anyone who is unaware of what that situation is. Explaining the circumstances for which the code makes sense, is what you put into the comments.
You do that not only to give "the next guy" who has to maintain the code a head's up on why it was written that way, but because if you're in the same place for any length of time, "the next guy" is likely to be YOU, after you've forgotten why the heck you wrote
Re: (Score:2)
The comments should be in the code, so when you go back 2 years later, you know what it is doing and why.
Re: (Score:2)
Often the incompetent people who understood the code originally leave and are replaced with incompetent people who don't understand the code. Hiring competent people may not be one of the options you're presented with.
Re:The only unmatintainable code... (Score:5, Insightful)
The classic answer to that is 'job security' == 'unpromotable'
But that assumes you aren't going to change companies, on your schedule, and 'fuck them'.
The truth is 'job security' == 'not promotable without an employer change'. But that's just true for many employers in any case. If that's your boss, there is no reason not to play 'knowledge is power', just don't be slow blatant about it the PHB can see it.
No different than writing a book (Score:5, Insightful)
Sometimes you have to completely rewrite everything from the beginning.
Other times, changing a few words here and there, or a paragraph or two is all that is needed.
Re: (Score:3)
On this topic, I was thinking about the Thunderbird email client. It's been pretty stable, with no major changes in years as far as I can tell.
Does that mean it's "done", or is it too complex for people to work on?
The latter case seems to be hinted at in this blog post [mozilla.org].
Has anyone here contributed to it and if so, any comments? I love Thunderbird but when I looked at the code several years ago it was fairly daunting.
There's a couple of problems with working on Thunderbird. It's built on Mozilla (Firefox) code base, which is huge and fast changing at times, especially lately as they replace big chunks, so right there is a huge learning curve including learning how a bunch of stuff works under the hood,
Ant then there is the Comm-central (Thunderbird and SeaMonkey) code, which much is old and complex as well as intertwined with Mozilla code.
They are being forced to rewrite much due to Firefox having large chunks ripped ou
Re: (Score:1)
Re: (Score:1, Offtopic)
“It was a substantially expanded version of the first four episodes of the radio series, in which some of the characters behaved in entirely different ways and others behaved in exactly the same ways but for entirely different reasons, which amounts to the same thing but saves rewriting the dialogue”. -Douglas Adams, Introduction, The Ultimate Hitchhiker’s Guide to the Galaxy
Re: (Score:2)
Neil Gaiman? Seems to have rewritten Neverwhere. Then there's rewrites for the big screen or small screen that probably happen more.
Even with software, I'd expect large projects not to rewrite everything, but rather chunks. Firefox for example has had a lot of rewriting in the last couple of years but I'd guess stuff like widget/ are only lightly touched.
Is it really the same application (Score:1)
That's how we've ended up approaching this question. Is this really the same application, or are we creating something new. Often, we've found that a major upgrade isn't an upgrade at all, but a new approach to doing a somewhat similar set of things to what our client's application has done. Joel is right; there is an amazing amount of knowledge embedded in the code base. However, if that business knowledge doesn't apply, then throw it out. Artifacts from motor controllers that were obsolete a decade ago,
Summarized in four words: "Make a New Product" (Score:5, Interesting)
Nowhere in this article is any flaw in Joel's pronouncement to never rewrite found. The only of the six stories that was a rewrite of an existing product is Netscape and that was a disaster. The fact that Firefox came out years later doesn't make it any less of a disaster.
In the rest of the cases, no one is re-writing their existing product and letting the competition catch up. No, what they are doing it making a new product and moving users over if possible. That makes sense and that is what I learned from Joel's original article.
Making this seem like some kind of intriguing rethink of rewriting legacy code is false and click-baity.
Re: (Score:2)
Even Netscape is questionable. Look at the graph again. By the time the rewrite started, it was already on the way down. IE6 had already reached parity. Did the rewrite really reach back in time?
Clearly by the time the rewrite started they were already in deep trouble. So much that they had resorted to open sourcing the whiole thing hoping outside developers would turn their steaming pile into something. It coundn't, so they decided to do a re-write.
Did the re-write actually fail from natural causes or was
Citation needed. (Score:5, Informative)
The articles own facts don't support the article's conclusions.
"Netscape’s slide into irrelevance wasn’t entirely due to the rewrite—a court agreed that Microsoft had deliberately abused their monopoly. But the rewrite was certainly a contributing factor"
The graf accompanying this section shows Netscape's market share dropping from about 80% to 50% BEFORE the rewrite. Now that drop continues from 50% to near 0% during and after the rewrite, so the rewrite certainly did not save Netscape. But the slope of the decline barely changes pre- and post-rewrite. Basically, unless there's other evidence not presented, the best conclusion is the rewrite had no effect.
Also, "what finally ended the IE6 era wasn’t Firefox but Google Chrome."
Except your own graf shows IE market share dropping starting in late 2002 in mirror to the rising Mozilla/Firefox. Chrome doesn't even show as a factor until 2008. The articles own facts don't support the article's conclusions.
What really killed Netscape was releases a lousy product. 4.0 suuuuucked. (Folks on the web in '96/97 remember.) And IE at the time was releasing it's first good version, a better version. Fact is, at that time IE was better than Netscape.
What Netscape needed was a better product, and if it took a ground-up rewrite to get that better product, then a rewrite was necessary.
What we know now is the rewrite did not save Netscape. But we'll never know if there was some other course of action that could have saved the it. What we really should be doing is examining what was going on in '95/'96 to produce such a bad product and lose that market share in the first place, not at what rearrangements of the deck chairs was done as the ship went down.
Re: (Score:3)
The graf accompanying this section shows Netscape's market share dropping from about 80% to 50% BEFORE the rewrite. Now that drop continues from 50% to near 0% during and after the rewrite, so the rewrite certainly did not save Netscape. But the slope of the decline barely changes pre- and post-rewrite. Basically, unless there's other evidence not presented, the best conclusion is the rewrite had no effect.
The decline of Navigator was caused by Internet Explorer. This is pretty easy to see on the graph, and for anyone who was around at the time, easy to remember. IE improved steadily with each release, and bundling it with Windows 95, first in the Plus! Pack and later in SP1 (in early 1996), had a massive effect. This, more than anything, caused the decline of Netscape.
What Joel and others are saying is that starting a rewrite of the product prevented Netscape from reacting quickly to the problems with Nav
Re: Citation needed. (Score:2)
Re: (Score:2)
What really killed Netscape was releases a lousy product. 4.0 suuuuucked. (Folks on the web in '96/97 remember.) And IE at the time was releasing it's first good version, a better version. Fact is, at that time IE was better than Netscape.
This exactly reflects my experience. In college, we all used Macs, and MacOS had Netscape installed by default as it came with the install CD. Everybody was explicitly replacing it with IE5, because it was a much, much better browser.
Mac people intentionally using MS software by choice, because it was actually better? Say it ain't so!
Re: (Score:1)
There's no Java version of Netscape/Mozilla/Firefox*/etc (it's all C++); the big user-visible change with 4.x was the full application suite (Browser, Mail, IRC client and something else I don't remember right now). The rewrite mentioned by Joel is Netscape 6.0 which was a near disaster (based on alpha Mozilla code -- circa 0.5 IIRC -- really unstable, RAM-hungry and incompatible with two critical plugins at the time: Flash and Shockwave)
My first internet experience was as a kid with Netscape 4.x and IE 5.x
edge cases and weird bugs (Score:2)
Precisely why re-writing should be on the table.
WHY do the "edge cases" exist? Did you not really understand the situation originally?
Re: (Score:2)
Does anyone really understand a complicated real-world situation without trying things to see what happens?
Re: (Score:3)
I would say nobody ever fully understands the situation originally. Thinking otherwise is hubris.
Re: (Score:3)
And almost everyone who codes stumbles across some old code and asks, "Who the hell wrote it like this?" And then realizes it was them a long time ago, and that there was probably a reason for it but they have no idea what it was.
Don't be a Hero. (Score:4, Interesting)
Sometime you need to disconnect your software from your ego.
A lot of full rewrites are primarily due to the fact the developer wants to be the Hero, toss out the old broken code, and make a new superior on in their own image. (Which then over times becomes old and broken)
Also trying to keep bad code on life support, because you had invested so much into it over your time there, is just as bad, as the application barely meets the business needs anymore, and every fix is getting increasingly more complex.
Sometimes what the code really needs, is just some reorganization. (Move your function and methods in more logical locations in your code so you visualize the problems more easier. Beautify your code, make white spaces consistent. ) Create a script to see where each function is called and where, Delete unused functions. Identify duplicate logic and merge them, or make a parametrized function of of them. It is actually amazing how a little cleanup work can turn a mess into a manageable application for decades.
Also if designing software really try to split Logic and Interface/System call into separate portions. The routine that checks the required field, should be straight logic. Not generating HTML or Form boxes, giving the errors. Despite what your bosses say, assume the platform it is running on will be retired in 5 years, and try to plan to port the application over.
Finally, really try to use basic core components as much as possible, avoid 3rd party tools as much as you can (this includes semi official repositories such as with pip or cargo). Don't be a Hero and make a ground breaking new interface, just use normal component.
Re: (Score:3)
Maybe it is sometimes ego. Sometimes it is being tired of fixing spaghetti code that evolved over years with a CEO that says to fix it now, without taking the time to fix it right.
AT MSI they had a person port the code from Windows to Mac, and came out with crap that was thrown away. If done correctly, it could have been the core of the new generation and been used as core of the NLM transport module. If they did this when they ported it from DOS to Windows, the port to Mac would have been much easier. Th
I've found what works best is the Pheonix (Score:2)
I've been a lot of projects, some where we re-wrote from scratch, some where we just kept trying to overhaul stuff...
It's true what he says about re-writing either missing, or spending a long time discovering the special understanding of things embedded deep in your code.
What is ALSO true though, is that trying to fold new things into an ancient code base becomes harder and harder over time, to the point where even the smallest of features is torture to implement.
The approach that has actually seemed to wor
WTF, Slashdot (Score:5, Funny)
Two programming articles in a row? How in the world am I to satisfy my deep inner thirst for bleeding-edge news about global warming, basic income, the Model 3, and Ajit Pai?
Keep this up and I'm going to have to go back to HuffPost. Sad!
Re: (Score:2)
Two programming articles in a row? How in the world am I to satisfy my deep inner thirst for bleeding-edge news about global warming, basic income, the Model 3, and Ajit Pai?
Thank you for your succinct summary of why I should really stop wasting my time here.
Rewriting Netscape gave IE the web. (Score:4, Insightful)
I hope in five years time, when Chrome has 90%+ market share Mozillians take a hard look at themselves and see that they were responsible for the chromageddon.
Re: (Score:1, Insightful)
Re: (Score:2)
We could have had a strong Mozilla, now we got a weak one. Imagine a Firefox released in 2000, not 2004. We could have defeated IE earlier and avoid IE6 all together.
It was the dominance of IE and Microsoft's hubris which together brought down IE. Apart from a small bunch of Microsoft haters most people used IE until browser specific malware broke their computers in unacceptably short intervals. This trend did not catch on before 2003-2004, and fortunately Firefox was ready for prime time by then.
BTW IE6 (with its legendary web standard non-compliance) hurts Microsoft a lot more these days than it hurts Firefox, so we might as well cheer the former appearance and ubiqui
Joel was incorrect.. (Score:5, Insightful)
His article hinges upon the assumption that Netscape was screwed over by the rewrite. In reality, they were almost certainly screwed on the business side to the extent no amount of technical effort could overcome their position.
To the extent they had technical woes, it may well have been the case they couldn't sort out how to make the improvements they wanted to make given their current design.
Now there are valid points, that 'old code' may look crusty but there is a good chance it is crusty for a reason and that sort of thinking should be ever present while making such a call, to try to understand *why* it is crusty before throwing it out. However sometimes it is for bad reasons:
-Written against a once-presumed 'winner' of the market that becomes defunct. Your shockwave website has to be rewritten because the supporting technology is toast, and you better be scrapping your flash website soon if not already.
-Maybe the runtime is still around, but *your* ability to find willing developers is difficult, so you have to switch languages/runtimes to align with the labor market
-The people doing it didn't know what they were doing and did it incorrectly. Optimally, this is the same team that recognizes they painted themselves into a corner so they know what to do next time.
-The code is full of workarounds for third party libraries that no longer apply. True this doesn't scream 'rewrite', but one of his points was that the ugliness of code is due to fixes for things long forgotten that still matter, but it's frequently the case they do still matter.
In short, like all opinions be informed and influenced, but no simple answer is ever 100% correct no matter what. Internalize the points and evaluate in your scenario.
Re: (Score:2)
"Coders at Work" lays out the problems with Netscape. Netscape had a usable product written in C. Then they bought a company that never had a successful product, and whose programmers used C++. The C++ programmers did the (horrible) rewrite.
Re: (Score:2)
While I'm willing to believe the rewrite was a debacle, I would guess that the same team that did a crappy rewrite would have also failed at extending the existing codebase as well. In fact I'd be surprised if they hadn't spent some non-trivial time failing to evolve the codebase before resorting to rewrite.
Rewrites are frequently the 'end of the road', but I think they are usually a symptom rather than a cause. When the product starts failing, a rewrite is a likely 'hail mary' move to hope for the best.
New versions lose new customers (Score:1)
Re: (Score:1)
Yeah, it is a fairly common story, and I believe the reason why a lot of small tech companies go under:
- Start with a client that has money and needs an application.
- The application is decent and makes the client happy.
- The company has money and more clients are interested, so new features are developed for the application.
- Enough technical debt has now accumulated that small problems take 10x as long to fix as they used to.
- "Let's take our knowledge of the application and rebuild it from scratch." Now
Re: (Score:2)
Well, if you used duct tape and paper clips it would be much easier.
Wrong reason to to rewrite (Score:3)
I once worked in a government department that liked silver bullets. One of the things they tried was moving the development shop to one language, Java. That meant rewriting everything they wrote and even used. Even apps that were running without issues had to be re-written just because it was originally written in C. They even wanted to rewrite the utility formmail.pl that most sites were using at the time just because it used Perl.
Re: (Score:3)
I once worked in a government department that liked silver bullets. One of the things they tried was moving the development shop to one language, Java. That meant rewriting everything they wrote and even used. Even apps that were running without issues had to be re-written just because it was originally written in C. They even wanted to rewrite the utility formmail.pl that most sites were using at the time just because it used Perl.
Perl itself is an example. The grand rewrite to Perl 6 is still a work in progress.
I think it killed Perl in the process.
A lot of it is vanity (Score:2)
The insistence on rewriting because "The old code is complete crap" is often just about vanity. That it works and meets the business requirements is irrelevant, they just don't like it. They don't care that rewriting it will take a lot of time and cost a lot of money to get to where they already are functionally.
While that rewrite is going on someone else is busy maintaining and enhancing the existing product. By the time rev 2 is near done it is already out of date. Many times I've seen it get canceled
Re: (Score:2)
I don't know that it's vanity as much as it is an unwillingness to take the time and effort to understand 1) the workflow the code supports and 2) the code itself. I guess sure, there's a bit of vanity and overconfidence thrown into the mix too. Disdain for the existing code and overconfidence in my capabilities.
If you have have all the requirements, true, full, accurate requirements, and an intuitive, easy to use interface, sure a rewrite can succeed. The successful cases listed in the article (Basecamp to
Re: (Score:2)
I don't know that it's vanity as much as it is an unwillingness to take the time and effort to understand 1) the workflow the code supports and 2) the code itself. I guess sure, there's a bit of vanity and overconfidence thrown into the mix too. Disdain for the existing code and overconfidence in my capabilities.
If you have have all the requirements, true, full, accurate requirements, and an intuitive, easy to use interface, sure a rewrite can succeed. The successful cases listed in the article (Basecamp to Basecamp2, Visual Studio, Inbox to Gmail, Freshbooks and Billspring) all knew what FEATURES had to be implemented. They had true requirements. They had continuity in management and likely programmers.
Getting the true requirements can be very, very difficult for a new team. As far as the crufty edge cases go... how much of that is a user requirement versus some flakiness caused by a weakness somewhere else in the program?
The problem with eliciting requirements from users is that they can't envison what they truly want until they can play with a real version of the product, and THEN they realize how they want to use it (I guess this is a more of a problem for a new feature). Requirements for new features seem to evolve too. Gross requirements -> user plays with the product -> refined requirements, rinse, repeat.
Another factor is how long the rewrite will take and what the user migration path is. If it takes too long the product stagnates.
I think the Perl 6 rewrite killed the Perl momentum and it's never coming back.
This killed my software (Score:2, Interesting)
Maybe add this as a seventh cautionary tale.
I developed an application for reserving lab equipment for one of the largest server manufacturers in the world. It was capable of automated inventory, software and image deployment, and automated permissions handling that worked with an out-of-band IPMI interface and was capable of getting data as detailed as PCI bus info, CPU and memory information of virtually any server that runs IPMI. I wasn't the first to attempt an inventory management system like this with
Mixed bag (Score:3)
The first two never produced anything and sucked up huge amounts of development resources.
The reason was identical both times:
New management wanted to take over a successful product and make a name for themselves.
They never really understood the original product and nor did the (largely) new development staff thay used.
The third rewrite project was a success.
The original management used most of the original development team to rebuild, from the ground up, the product.
While the rewrite took slightly longer than the estimates, the results were better than predicted.
The company was subsequently sold to a huge bank for hundreds of millions of dollars.
The team that built the original product and also did the rewrite still consider themselves a team, despite the fact
that most of us no longer work together.
IT'S ALL ABOUT THE TEAM
Full credit goes to the management for team building, which is the most important aspect of managing just about anything.
Rewrite if Microsoft deletes your language?! (Score:1)