18

Possible Duplicate:
When is a BIG Rewrite the answer?

In Joel Spolsky's famous (or infamous) article Thins You Should Never Do, Part I, he makes the case that doing a rewrite is always a wrong move because:

  1. It automatically puts you behind (your competitors/schedule/etc.)
  2. The code probably isn't as bad as the programmers believe (anything someone else wrote is always a mess, although some are bigger messes than others - and even then)
  3. It's probably easier/quicker/cheaper to fix what's truly wrong with it than to rewrite from scratch.
  4. In rewriting from scratch, you are probably going to re-introduce bugs that were fixed in previous versions the original code.

Instead, he recommends fixing what's wrong with the code.

I assume this is a good summary of his post, and I'll postulate that it is generally true.

I'm trying to collect a set of rules/guideline for my team, and one of them (based on Joel's article) is

We don’t re-write ... ever! 
- But we can refactor large portions of the code.
  (this exception takes care of ugly/problematic code issues)

One question that has cropped up is "What about when technology changes and you can no longer get support for older versions?". This is what I think of as the Sisyphean Upgrade path.

E.g., I recall when Oracle moved from SQL*Forms 2.x/3.x through to Forms 6i and beyond, Forms that were originality developed in the old .inp format were no longer supported with the current version of Oracle and Oracle Forms.

So you had a choice of sticking with an unsupported database with unsupported tools or rewriting the Forms from scratch (or converted with 3rd party tools and then gone over with a fine toothed comb). Which I will call porting, particularly when you are doing a faithful line by line/function by function translation into the new tech and not adding any functionality.

The rule then became:

We don’t re-write ... ever!
- But we can refactor large portions of the code.
- And we can port the code to a new platform when we *truly* have no other 
  choice.

(and by truly I mean, you can't even buy your way out of the problem for 2x the cost of porting it)

Are there any other exceptions that I've missed?

Community
  • 1
BIBD
  • 421
  • 3
  • 11
  • 4
    Related: [When is a BIG Rewrite the answer?](http://programmers.stackexchange.com/questions/6268/when-is-a-big-rewrite-the-answer) – spong Aug 12 '11 at 19:24
  • 2
    @sunpech I'd go as far as to call that a possible duplicate. – Adam Lear Aug 12 '11 at 19:36
  • @Anna Lear Agreed, it basically the same ground. – spong Aug 12 '11 at 20:09
  • Always a tough call. Joel is prolific and convincing. For a counter point, Fred Brooks in his seminal work "The Mytical Man Month" contends you **will throw one away**. In his view at least one rewrite is unavoidable. `The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.`. – EBarr Jun 19 '14 at 01:32
  • 1
    @Mawg, re-read the first line of the question. – BIBD Jun 02 '15 at 14:35

5 Answers5

15

As with any hard and fast claim that Joel Spolsky spews out...

You are not supposed to take it literally!

He likes to paint a dramatic argument for a common problem and common situation, but like anything in the real world there is always that gray area, no matter how small.

He intends to get people thinking and to create an aversion to being "re-write happy" which I completely agree with. 95% of re-write situations don't warrant it but of course you will have that exceptional case where "Our client is moving to Linux servers and they won't install Mono. We should rewrite this .NET app in some other technology."

The fact that what he said worried you enough to post a question means that he does his job well. He got you thinking and that is his ultimate goal I believe.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 1
    And you never really rewrite. It's like moving to a better home, more suitable for the family growth. You don't have to trash all your clothes, the car or your wife, you throw what became obsolete or problematic with time. –  Aug 12 '11 at 20:00
  • O.K., but when should you rewrite? – psr Aug 12 '11 at 20:41
11

My view is this: You should rewrite when it would be easier to start from scratch than to refactor. For instance, if the refactoring effort would involve months of retrofitting procedurally-written OOP code to proper OOP before you could even start to refactor the code, then a rewrite is the better option because you have to change everything. Another example would be if there are zero unit tests and the infrastructure doesn't support unit testing (i.e. tightly-coupled code, no separation of concerns), you cannot begin to refactor the code without a test suite, but creating the test suite requires taking the guts of the application and making some pretty serious modifications to enable creating those tests in the first place. It's an infinite loop, of sorts: You can't refactor without the tests, but the tests can't exist without refactoring.

I disagree vehemently with Joel's article on rewriting, because I've been in many situations where a serious refactoring cannot happen because literally NOTHING is done correctly to support refactoring at all. In a situation like this, the choices are often: 1) Rewrite the application, or 2) Don't touch anything and keep slopping on code.

You should also consider a rewrite when you need to introduce some serious architectural changes to the code that can't be retrofitted, again the quintessential example would be working on an app that's been thrown together without rhyme or reason, no unit tests, no separations, hard-coded SQL, magic numbers everywhere.. you get the idea. Trying to change a beast like that is like Sisyphus trying to push the boulder, especially if you want to introduce proper design concepts like SOLID, or introduce a proper ORM, or say move to ASP.NET MVC when everything is WebForms with all logic in code-behind to it.

To stay with the whole "technical debt" theme, I put forth this:

Refactoring is going through a (technical) debt consolidation and slowly paying back the debt over a (usually long) period of time.

Rewriting is (technical) bankruptcy.

Just like in real finances, sometimes your debt is so great that bankruptcy is the best (if not the only) option to just wipe everything clean and start again, provided you don't make the same mistakes again.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
  • The choice of your 1) or 2) is a business decision. It is up to the programmers to lay out the case and let management decide. The code exists to serve business concerns, so those might be vastly more significant in this case. –  Apr 07 '17 at 14:27
3

Probably...but

There are probably additional exceptions - at some point 'large scale refactoring' and 'rewriting' are indistinguishable - when every line of code changes!

But what I'm wondering is: what is the purpose of making hard-and-fast rules for situations you have yet to encounter? Joel's example was an extreme case (NetScape) not a common case. If you have the wrong design or have outgrown the architecture or changed platforms et al, rewriting may be a valid option. If your team never gets to that point, then the rules debate is a waste of breath. When you get to that point, the situation may be so different that the hard-fought rules you come up with today no longer apply.

Community
  • 1
Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • 2
    The purpose of the rule to deflect the immediate reaction I'm running into with less experienced developers. Their first reaction to any piece of code they didn't write is often "this is awful, we MUST write this", while the reality of the situation is we don't have the budget to re-write it and turn around time for a particular fix/change is on the order of days or weeks, and not months. – BIBD Aug 12 '11 at 19:21
  • 1
    As far as refactoring ~= a rewrite. I still see refactor as a lot less work and less error prone than a re-write. Consider fixing inconsistent indentation of a million lines of code and/or making variable names conforming to a consistent standard vs. a complete re-write. Ever line or character may be touched, but I'm sure the re-write would take longer and be more error prone. – BIBD Aug 12 '11 at 19:28
  • 2
    Refactoring may have the effect of a rewrite, but it is not the same. Refactoring is incremental. In the end, you may refactor all the code, so that not one original line remains, but in between, you still have working code. – kevin cline Aug 12 '11 at 19:45
  • 1
    @CodeSlave obviously. The only time a rewrite is in order - IMHO - is when there is a chasm that must be jumped. There's no such thing as incrementally jumping a chasm, so you rewrite - but the rewrite can certainly be guided and aided by refactoring. As for the noobs, perhaps a better rule would be _learn to read other people's code_ ;-) – Steven A. Lowe Aug 12 '11 at 20:45
3

I've read his article, and 1,2, and 4 are good points, but 3 is a circular argument. Also, his code examples aren't even close to the worst code I've seen. Surely, at some point, there must be code worth rewriting from scratch? It's one thing to say never do it, but it would be more helpful to try to come up with a way to reasonably decide where to draw the line.

What if someone wants to upgrade an obsolete software stack that uses files instead of a database, is written a private language with a buggy custom compiler into COBOL, has no comments, no tests of any kind, and uses nothing but GOTO for flow of control and global variables for state, and is an entire enterprise application in one layer with everything dependent on everything else (but the users love it)? I'm making this up, but in that situation, would it truly be cheaper to fix than to rewrite?

I think point number 3, is it cheaper to start over then to fix up (including any porting), is the key point. In your case, if a line by line port really wouldn't work maybe you could admit your basically rewriting and plan accordingly.

psr
  • 12,846
  • 5
  • 39
  • 67
  • 'Rewrite' in this case is more accurately stated as: "We are starting work on our next major product." Either you will do that some day anyway or you will be closing up shop some day anyway. –  Apr 07 '17 at 14:31
2

if your design turned into unmaintainable spaghetti (common issue with single programmer/small code-base projects) and you're still early in the project (or the part affected is small enough) it's better to take out the garbage and restart

but that's pretty much the only reason you should ever rewrite

and when you start rewriting make a clear plan on what the new design is going to be and STICK TO IT, you should already have an idea of what is needed and where it went wrong the first time and create a design from that hindsight (keep old bug reports and recreate the circumstances with the new project coughunittestscough to fix respawning bugs)

if you want to recreate an existing prior project as the next major version keep it as a side project and keep the main project active and supported for a backup when the rewrite fails and only ship the rewrite when it matches the requirements that the old one reached or throw it out when it fails; Joel's article mentioned M$ tried to rewrite word but it failed but they kept the old codebase active so the were fine besides lost dev time.

ratchet freak
  • 25,706
  • 2
  • 62
  • 97