Big Software Rewrites

It is well known that big software rewrites are often failures. They fail because they always look easier than they really turn out to be. To replace a system that has been around for years is likely to take years to rewrite. Plus you have to add in all that time required to fix new bugs, add the features that were missed, and handle a whole new set of discovered edge cases. While the rewrite is happening, the existing product is not getting the attention it needs. Bug fixing and enhancements stop and customers become frustrated. This can give the competition an advantage. They may gain market share by delivering features customers want and need while you spend two plus years rewriting and stabilizing your product.

If you haven’t already read it, check out “Things You Should Never Do, Part I” by Joel Spolsky from over 10 years ago that is still very relevant.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Ray Houston

Ray is a software development leader and architect with 20 years hands-on experience. He enjoys finding elegant solutions to complex problems and delivering real value to customers. Ray is a speaker and contributor to community events.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to Big Software Rewrites

  1. Steve says:

    LOL! Joel’s article is about Mozilla, and in 2000 when he wrote that it seemed like a smart commentary.

    Today. Would you say Mozilla is a good product? Would you say that Mozilla has a growing marketshare? What about IE? Where is IE today? How is the IE team able to respond to new features being offered in the marketplace? They’re not, IE is on a steady decline and has under 50% marketshare today. When that was written in 2000 they had 90% marketshare.

    There’s actual a real lesson in the Netscape experience. The real question is why do you have to rewrite everything?

    The answer is because of the way we used to do things, with tightly coupled intertwined Big Giant God procedures. When everything is so tightly coupled a small change becomes a disaster just waiting to happen.

    However through loose coupling, and the other practices involved in Agile development, one can replace a major subsystem of an application with minimal risk to the rest of the application.

    And this is what allows you to respond to the marketplace faster.

    Yes, in 2000, what Netscape did sounded dumb. However their new codebase was more modular and allowed for easy inclusion of new features.

    But when you look at it from 2011, was it?

  2. DaRage says:

    Thank you Steve for the smart comment now.

  3. Duke says:

    Actually, Joel is quite correct. The rewrite of Netscape destroyed the company. It forced them to not release a 5.0 version of the product and ship a very late 6.0, allowing Internet Explorer to surge far ahead.

    In the long run, a better product was produced. But Netscape as a company did not survive. In most cases, this would have been the death of the product too, but Netscape had the foresight to open source their product so that it could live on.

    A greenfield project of course provides the opportunity to do everything right, but many of us find ourselves working on legacy systems which may have accrued years of technical debt. Most companies will be wary of a total rewrite because of the cost and uncertainty involved (the Netscape story actually serves as a cautionary tale). This is where skillful application of refactoring techniques is most important, to re-architect the code base to a more clean design. This was in fact what Joel Spolsky was recommending.

    Refactoring may not be as sexy as a total rewrite, but most of the time, it is the correct thing to do.

  4. Steve says:

    Not really sure this Blog make sense, it reads like an extended twitter comment or something. That, and it’s just a complete generalization.

    Why would rewriting a legacy app mean that said legacy app is ignored? Everywhere I’ve worked that did a rewrite of a major application, there was always a team responsible for supporting the old app (which included adding new features). So the “old” app was never ignored, and new features added there would be added to the “new” product as well.

    I’m not saying rewrites are easy, and the decision to do them needs to be carefully thought out, but just because you rewrite an app doesn’t mean you are going to go the way of the dodo either.

    (A different Steve from that other Steve, although I agree with him)

  5. Ray Houston says:

    Perhaps I should have title the post “Can you afford the Big Software Rewrite?”. It takes capital to be able to support two teams and if you don’t have it, you should think twice about a rewrite.

  6. Steve says:

    Ray,

    Two things, if you have a product that has a market and you have competitors, then you have enough capital for two teams. The size of the teams my differ, and those teams may share resources, but you can still have two teams. If you can’t afford that, then perhaps you need to reassess revenues and the market you are in. That being said, you should always think twice about a rewrite, even if you have the money.

    Secondly, I still don’t really get the point of this post. This “blog” is essentially one paragraph with a link, and the one paragraph makes many different points, and while the points are related, there is no real explanation or references to back up the claims. That is why I thought it read like an extended twitter comment, because it seems more like a reply to another blog (Atwood’s codinghorror posting today perhaps?) rather than a post of it’s own.

  7. Andrew Kuzmin says:

    I agree with Ray, it’s really tough.

    We are SaaS in healthcare area, and decided to rewrite the working app 3 years ago.
    In our case what helped us a lot was that we had a team in India who were working with the original app, so they ended up with maintaining it, fixing bugs, and even adding some small features while we were rewriting the app from scratch ( which took almost a year to the first release).

    Also, once our sales started to demo new prototypes ( which obviously had lot more of bells and whistles ), the potential customers became hesitant whether to buy our existent app ( and later migrate all data ) or wait until new app is released and stabilized.
    We ended up with lot of upfront sales and lot of commitments that sales often made but forgot to bring to dev.

    And then it took another year to migrate all customers from old app to new.

  8. chadmyers says:

    I think there’s a big difference between software you ship, software you host, and destination web site software.

    The rules for rewrite are different. In Rob Conery’s case (TekPub and similar to 37 Signals), the goal is to get as many iterations as possible in the shortest period of time. If your current site makes iteration hard, it’s pretty obvious to rewrite it in order to keep momentum going.

    The rules are a little different from hosted/SaaS software and they are completely different with shipped software (Netscape is in this category).

    Long term maintainability is crucial for shipped software since you can’t easily throw it away and restart since you have customers running many different versions. If you get the rewrite wrong and need to release small incremental fixes, it’ll kill you.

    With SaaS, all customers are on the latest (or close to the latest depending on how your company does SaaS), so rewrites are a little less problematic, but still costly. It’s slightly easier to implement incremental fixes and patches along the way. Some SaaS vendors have gotten to the “many successful/controlled updates per day or week” nirvana.

    With destination websites, you can iterate many times a day and even make some mistakes (be sloppy) without a huge impact.

    Destination web sites: Run and trip as fast as you can. That’s the name of the game. Mistakes are cheap to fix.

    SaaS/Hosted: Jog fast, limit mistakes, infrequent rewrites. Mistakes can be costly, but resolved easily.

    Shipping software: Walk normally or maybe speed walk. Very few mistakes as they are costly to resolve and involve high visibility from customers (shipping a new point release and making customers go through the upgrade process).

  9. chadmyers says:

    I think there’s a big difference between software you ship, software you host, and destination web site software.

    The rules for rewrite are different. In Rob Conery’s case (TekPub and similar to 37 Signals), the goal is to get as many iterations as possible in the shortest period of time. If your current site makes iteration hard, it’s pretty obvious to rewrite it in order to keep momentum going.

    The rules are a little different from hosted/SaaS software and they are completely different with shipped software (Netscape is in this category).

    Long term maintainability is crucial for shipped software since you can’t easily throw it away and restart since you have customers running many different versions. If you get the rewrite wrong and need to release small incremental fixes, it’ll kill you.

    With SaaS, all customers are on the latest (or close to the latest depending on how your company does SaaS), so rewrites are a little less problematic, but still costly. It’s slightly easier to implement incremental fixes and patches along the way. Some SaaS vendors have gotten to the “many successful/controlled updates per day or week” nirvana.

    With destination websites, you can iterate many times a day and even make some mistakes (be sloppy) without a huge impact.

    Destination web sites: Run and trip as fast as you can. That’s the name of the game. Mistakes are cheap to fix.

    SaaS/Hosted: Jog fast, limit mistakes, infrequent rewrites. Mistakes can be costly, but resolved easily.

    Shipping software: Walk normally or maybe speed walk. Very few mistakes as they are costly to resolve and involve high visibility from customers (shipping a new point release and making customers go through the upgrade process).

  10. Steve says:

    Chad,

    That was well said…err, written. Really, my main point was you can’t just throw a blanket “it’s bad to do any rewrite” and expect it to satisfy every condition.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>