Fog Creek Software
Discussion Board

Plan to throw one away...

you will anyway.

How do you know when you've reached that point in a big project when it would be better to just start over? What if you've spent 2 years coding an SDK and you took a wrong turn on day 1?

Wednesday, January 22, 2003

Duke Nukem Forever?

Ian Stallings
Wednesday, January 22, 2003

A better question is "How do you convince management that the whole design is borked and continuing on is only a waste of money?"

I came into a project with 100% turnover every 6 months and a software product that showed all the signs of a department in serious trouble. Management refused to accept the idea that the current design was so broken and bug ridden that it could never be patched or re-factored and was fundamentally flawed.

They just kept insisting that we just patch the bugs and "eventually" everthing would be ok. They weren't, and I bailed after 6 months. Shortly thereafter, the product was scrapped for good.

So good luck.

Mark Hoffman
Wednesday, January 22, 2003

Get together a refactoring plan. This shows how you can go from a mess to something useable in incremental steps.

I've never seen a project where absolutely every single line of code was a waste. Even if the architecture underneath is flawed, the UI might be okay. So keep the UI and refactor what goes on underneath.

It's always going to be quicker than a rewrite.

Better than being unemployed...
Wednesday, January 22, 2003

The end target of any business is profitability. Therefore you cannot possibly rewrite everything every 2 years when a typical product has a life expectancy of at least 5-6 years.

If new features require a product refactoring the do it as a delta rather than a rewrite. That is quite normal and the business will accomodate that.

The other alternative is the product is a money loser. In that case the company will cut its losses (sooner or later).

Wednesday, January 22, 2003

Unfortunately, you then run the risk of your salary being a good cost they can cut...

Better than being unemployed...
Wednesday, January 22, 2003

"It's always quicker than a rewrite."

I emphatically disagree with this statement. My experience has always been that rewriting is faster than bug-fixing in quality, which is the essence of the rewrite approach.

Jeff Kotula
Wednesday, January 22, 2003

"My experience has always been that rewriting is faster than bug-fixing in quality."

I have no idea what that means.  How can you be "faster" in "quality"? 

Do you mean "faster than bug-fixing at improving quality"?  If so, then the statement is obviously false.  If true, then whenever I encounter a bug I should trash things and rewrite my app rather than fix the bug.

Even if you believe rewriting is the way to go, it's impossible to believe rewriting is always preferable to fixing bugs.  Only on projects above a certain size?  Only when there are more than a certain number of bugs?  Only when the bugs are of a certain difficult-to-solve nature?  It can't be always; that simply doesn't make sense.

Herbert Sitz
Wednesday, January 22, 2003

Side note:  The quote "Plan to throw one away; you will anyway" is from Brooks' The Mythical Man-Month, and it's not meant in the sense that gitboy seems to be taking it.  Brooks meant that one should *begin* by assuming that the first iteration of the project will be thrown away.  It should be part of the entire development process, not a decision you come to later.  See

But, let's talk about when the application should be "thrown away."

Joel's talked about this in "Things You Should Never Do, Part 1":

IMO, this question centers around the tension between rewriting and refactoring.  So, compare them.

Estimate how long it will take you to write the application again.  Be careful and specific; do not succumb to over-confidence about how easy it might be.

Estimating refactoring is more difficult, especially since a refactored codebase is theoretically more stable and bug-resistant than a new one (a new codebase will have lots of undiscovered bugs; a refactored codebase should have fewer), but try.

When you have both estimates -- one for rewriting, and one for refactoring -- compare them.  Compare all the factors involved.

Which is a better use of your time?

Brent P. Newhall
Wednesday, January 22, 2003

I tend to agree with Joel's philosophy on this. A rewrite is usually the worst thing you can do. I say usually -- there are some extreme cases that *might* justify a rewrite, but most rewrites are simply a case of the development staff being too lazy/busy/frustrated to attempt any serious refactoring of the existing codebase.

Wednesday, January 22, 2003

A rewrite is the worst thing you can do, if the rewriters are not better than the original writers. The hindsight wisdom of seeing something fail is not sufficient for a rewrite to be successful.

If the rewriters are more experienced and significantly better craftman, the rewrite is most probably the right thing to do. But this is rarely the case; And unfortunately, most programmers overestimate their own ability.

A kind of a quick test: If you think you can rewrite it faster than fixing the bugs, spend a day or two writing a proof of concept prototype that actually does something useful. If you can't do that, you probably don't want to start a rewrite. If you really care about your company's success, do that on your own time, and if your prototype is a meaningful indication, you'll get your supervisor's approval. Nothing speaks better than working code that does something useful (but .... observe the Iceberg principle)

Ori Berger
Wednesday, January 22, 2003

I agree with the others that you normally don't want to do a rewrite - refactor instead and treat it as mainly a political (not a technical) problem.

However, I've been on one project where we completely threw away the old project (3 years of coding) to do a complete rewrite using a different language and technology.

The argument was 50% removing architectural limitations, and 50% greater productivity (based on 2 engineers prototyping for 2 weeks, and implementing roughly a third of the old product).

Big success. We were allowed to do it only because we had a good dog and pony show that we used to sell four levels of management.

Why such a big hurdle? Face it, if you try to argue for a rewrite management is going to view the current team as a bunch of losers, which means the very last thing they want to do is raise the stakes.

Eric Moore
Thursday, January 23, 2003

No offense, but any project that 2 engineers can rewrite 1/3 of in 2 weeks is not sufficiently large to justify a blanket statement about the merits of rewriting over refactoring. The project I work on is over 5 years old, and would probably take 10 engineers 3 years or more to reproduce from scratch.

Your point about politicking is well taken, though :-)

Tim Keating
Thursday, January 23, 2003

There was an article within the past couple months about the Sims Online project which mentioned that they went through a pretty major refactoring period, and the results were excellent.  Here's the Slashdot article: from which you can get to the article.


Thursday, January 23, 2003

> No offense, but any project that 2 engineers can rewrite 1/3 of in 2 weeks is not sufficiently large to justify a blanket statement about the merits of rewriting over refactoring.

I disagree. In the 3 years of coding there was probably a lot of experimentation done, ironing out interoperability issues, writing test frameworks, coding features that turned out not to be required, writing documentation (that will still be relevant), etc. etc. Over this time the codebase will have evolved and it will probably be non-trivial to maintain (which is why you're considering a re-write, right?).

Now, you've got full knowledge of the problem, you know the exact design you want to implement. All your experience is 100% relevant. New third-party libraries might mean that you don't have to write your own anymore, e.g. you can throw out all of your internal file formats and replace them with XML and use an off-the-shelf parser, or use Qt for cross-platform development rather than maintaing multiple GUIs, etc etc.

Finally, it doesn't follow that the entire project could be completed in six weeks: it was probably the best understood 1/3 of the functionality that was duplicated in two weeks. But you can rest assured that it'll take significantly less than two years to implement the remaining 2/3s.

Tom Payne
Thursday, January 23, 2003

*  Recent Topics

*  Fog Creek Home