Description

A big bang rewrite replaces an old system with a new system with one big bang deployment. The new system is developed from scratch. The opposite approach would be an incremental replacement, where individual parts get replaced step by step.

Experiences

Positive:

  • Basecamp rewrote their product successfully within a year. (Note: they kept the old and new system running in parallel and customers could decide to switch or not, therefore this is not a hard big bang)
  • An insurance company replaced a small system within 4 month by big bang
  • A multiple years running big bang replacement project of a governmental application has been successfully delivered in time and budget (but they also had no market pressure for new features)

Negative:

  • Chad Fowler wrote about all the failures he was involved (and the reasons)
  • Netscape’s market share dropped to almost zero (and stayed there), because of their rewrite
  • Borland and Microsoft wasted a lot of money with trying to rewrite Quattro Pro and Word (which eventually failed)
  • Logistics company lost 4 years and rewrote the system twice until they could proceed with new features
  • A data aggregation company estimated the rewrite to take 15 month, but it took 27 month and twice as much developers as originally estimated.
  • A telecommunication company failed twice to replace two of their old invoicing systems with a big bang approach due to incomplete requirements and an unrealistic time schedule. This led to a bad designed and buggy new system, which had both had to be rolled back from production.

Risks

Big bang replacement of medium and large systems have many risks, which shouldn’t be taken lightheaded. You need to make sure that you understand and communicate the risks and that risk, cost and benefit are worth it.

  • Software as a spec: Way too often, a big bang rewrite project has no proper requirements engineering. “Make it do what it already does.” is an often heard answer on how a feature should be implemented. As Chad Fowler points out in his blog, this has two major drawbacks: 1) if you are not familiar with the old system you don’t know what questions to ask and 2) if you are familiar you certainly don’t remember every little corner (especially when you need to estimate effort this will go horribly wrong).
    Therefore you need to reverse engineer the code base to write proper requirements. Since the software is in such a bad condition that it needs to be rewritten you can be sure that this is not an easy task.
  • Your business will certainly not like the big bang rewrite, because it takes minimum one year, often two or three to fully rewrite a system. This means that your business won’t get any new features during that time and that could be a threat to the business itself. Governmental agencies might be fine with this, but the rest certainly not. Ask Netscape.
  • In many cases, the business is asking for new features for the old system, while the new system is still under development. You will then chase a moving target, which can be a long and painful journey. The old systems has certainly some dark corners and a few stakeholders want to get rid of them. This is what Chad Fowler calls a wish list. Now you’re at a point where you have to clearly write down the requirements, because the two systems go into two different directions.
  • The old system usually collected a lot of bad Technical Debt (that’s often the main reason we rewrite). In the beginning of the rewrite everything is good, the code is clean. But because you chase a moving target, need to implement new features or things that are just harder as expected, you are running out of time, which introduces a lot of bad Technical Debt in the new system. You replaced a badly implemented system with old technology with a badly implemented system using new technology.
  • The organisation creates often a culture of the “tiger team”: the people who work on the new system get bragging rights. Expectations grow and are hard to manage.
  • The “Big Bang Day”. Eventually you have to deploy the new system and migrate the data. This happens often big bang and is therefore a major risk.
  • As Joel Spolsky put it: “It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again and introduce some new problems that weren’t in the original version.”

Applicability

You should consider a rewrite (not necessarily big bang) for the following reasons:

  • Your application is totally unmaintainable, but it needs new features, because the market demands them. And:
    • Your application is rather small and can be rewritten in less than 3-6 month if you are in a domain where your customers don’t accept a longer time without new features
    • Your application can be rewritten in less than 6-12 month if you are in a domain where your customers totally accept a longer time without new features (or have no choice, e.g. internal applications or government)
  • You lost the source code and you have no other choice
  • Your platform is so old, that you need to buy hardware at eBay, because the current hardware is deprecated.
  • Your codebase is still pretty good, but you want your application to do things in a radical new way and incremental change doesn’t help you with that. You don’t want to replace the current system with a new one and keep the requirements as they are right now, but you want to build a better system for your users as well (= your main motivation).
  • Quality developers with experience in the technology you need are too hard to find
  • You have deprecated central software frameworks or hardware (It can’t be upgraded to support newer platforms/features)
  • There is new technology out there making things possible, which weren’t possible before (and those things give you a competitive advantage)
  • The cost of maintaining the current system is too high
  • Important (new) quality attributes like performance, availability or security cannot be met anymore and the changes needed to implement them are so substantial that a rewrite is necessary
  • Even simple bug fixes take too long because of the complexity of existing code and might introduce new bugs
  • New features take too long and cost too much because of the interdependence of the codebase (new features cannot be isolated and therefore affect existing features)
  • Deployment is hard or impossible to automate, takes too long and is really risky. In fact, it fails often.
  • Your data are inconsistent and causes surprised and/or angry users. Keeping the data consistent is extremely hard, because the data model and the code operating on the data model is a huge mess.

A big bang approach is possible, if you cannot or want to incrementally replace the system for the following reasons:

  • The new system should undergo a revolutionary improvement instead an incremental one for both, technology and functionality
  • The system is small enough that it can be rewritten quickly within a few month
  • You analyzed other approaches like Strangler Approach or Seams and they could not help you approaching the problem incrementally
  • You and your stakeholders are aware and understand the risks and consequences of a big bang rewrite and want to go for it anyways (you might have good reasons to do so).

Consequences

  • You and your stakeholders are OK with
    • Not getting new features, rather less, for the time of the rewrite despite having higher cost (writing the new system and running the old one)
    • The new system will have less features than the old one (at least in the beginning)
    • The new system will have more bugs (because the old one is already battle-proved for a long time and the new one is not). Please be aware that it is naive to belief that you can deliver the new system almost bug free, because you already have the experience of the old system
  • In case the application cannot be rewritten within 3 months, you and your stakeholders need besides enough budget and manpower a lot of patience to rewrite the application completely. Getting impatient and rush into the release creates bad Technical Debt
  • You will have higher cost and risk of failure, but no benefit for your users. If you want to give your users a benefit, too, you cannot simply replace the old system with a new one, but you also need to rethink the way the application behaves in terms of usability, speed or flexibility. If you don’t want to incrementally improve your product, but rather introduce a revolution, the big bang rewrite is what you need
  • In case you rewrite the system using a new platform and language, there will be winners and losers regarding the change. Developers who are strong in the “old” technology will feel left behind unless they get a good chance in mastering the new technology. In any case, they will loose their strong expert position for some time and that alone causes tension and conflict.

Also Known As

Things you should never do.

References