The ‘Big-Bang vs. Iterative’ dilemma
It’s been a few years since we’ve had to make a decision on the Big Bang vs. Iterative dilemma for our project. When Erik van der Wenden and I presented our case “Incrementally replacing a legacy system using the Strangler pattern” at the Tweakers Developers Summit in February 2018, it was still very current and present in the day-to-day life of many attendants. It appears that the industry still struggles with this dilemma and that neither of these strategies clearly wins the match.
Given that renovating the legacy system is no longer an option, the dilemma arises to choose what strategy to take in replacing the old system with a new system. To clarify the difference between the two:
If you were to choose the Big Bang strategy, it means you will be building a completely new system next to the old one until you’re done and replace the old system at once. It is very important to note here that in this case you will replace the old system in one go.
The Iterative strategy, however, is about building a new system that runs simultaneously with the old system and replace it bit by bit each time the next bit is ready. In this case you replace the old system feature-by-feature; preferably small features or subfeatures.
A rationalist's comparison
Many people have a strong intuitive feeling towards one of these strategies. This bias often moved people from solid decision making to gut feeling. I’ve seen both approaches being taken at various replacement projects and the decision for taking either approach should've been made by reasoning. If you do, you see both options have their ups and downs.
Big Bang pros
Isolated/focused development
Lower development complexity
Big Bang cons
Higher risk at release/switch
Deferred business value
Chasing a moving target
Iterative pros
Immediate business value
Short feedback cycles
Iterative cons
Higher development complexity
Inside knowledge of legacy system required
The Big Bang pros (B+), and cons (B-), Iterative pros (I+), and cons (I-). Let’s go through each of them.
B+ 1. Isolated/focused development
Sure thing: if you build a new system from scratch until it’s done, you don’t have to account for the legacy system in production. Ongoing business doesn’t disturb you and no production issues. It's just your team building an amazing new system. Sure, one day it will replace the production system, but until then you can be focusing on rapid application development and ignore real-world problems.
B+ 2. Lower development complexity
Since you are isolated from the rest of the organisation and you don’t need to account for the legacy system in production it is lowering the complexity as opposed to the iterative approach. For instance, you don't need any synchronisation of data between both systems. This is a major booster for development speed for this strategy.
B- 1. Higher risk at release/switch
Since everything that was built for the new system was in a sandbox environment, it is hard to predict how the system will react once it is in production. Think of load capacity, performance, functional fit, bugs, but also how users will react to this sudden change. Not to mention, even before the go-live, how will your migrated data be in the new system; does it fit at all? What to do with incompatibilities? Many things you will need to adopt to, now that the system will actually be used.
B- 2. Deferred business value
New features and improvements surely have made its way into the new system. But they will only make profit once they’re live to your end-users. And that moment is there when the system is completely ready and deployed to production. Sure you may have done the user acceptance testing period, but human psychology works in a way that most issues will be found when it is live.
B- 3. Chasing a moving target
During your rebuild project, business moves as well. It needs improvements and changes, no matter how small. If they’re important enough, these things will be put in the legacy system in production. But they also need to propagate into the new system; doing the same thing twice.
I+ 1. Immediate business value
Replacing your legacy system bit by bit means by every iteration. Iterations should be short (i.e., at most a few weeks). With every iteration you deliver new business value because you replaced a little bit of the legacy system already.
I+ 2. Short feedback cycles
Because you deliver in short iterations, you see gradually what impact this little go-live has on your new system, infrastructure and users. You'll gather feedback on each iteration for you to take in the next iterations. This drastically reduces the risk of releasing new things as opposed to a Big Bang strategy.
I- 1. Higher development complexity
One of the downsides of iteratively replacing a system is that you need to account for the legacy system because both systems run simultaneously. This increases development complexity. For instance, you will need to synchronise both systems in terms of data consistency.
I- 2. Inside-knowledge of legacy system is required
In order to properly take over the legacy system iteratively, and in short cycles, you will need to hook into the legacy system to find the spots where you need data synchronisation, or external system calls, etc. Legacy systems tend to be not so well structured (this is often a reason for replacement in the first place). To achieve this, it requires inside-knowledge of the legacy system.
An empirical evaluation
I’ve seen projects that chose the Big Bang strategy as the way to go. They’ve used the previously mentioned pros for the Big Bang approach as arguments for doing so. Unfortunately, the business stakeholders interpreted them (faulty) as shorter time to market. Their reasoning was that because development is isolated and less complex, the development would be quicker and they would sooner replace the complete legacy system than if they would go for Iterative replacement. This project was estimated for six months but went on for several years, over-time and over-budget...
Some other projects went for the Iterative strategy. Again, using the previously mentioned Iterative pros as arguments for doing so, but also consciously agreeing with the cons it brings. The projects that made an estimation all went over-time and over-budget...
Should we conclude that both strategies are unsuccessful?
Wrong perceptions lead to wrong estimations
One of the hardest things in software development projects is estimating time and costs. Not just because it is very hard to determine at the start of a project what work needs to be done, and how much time it will take. It’s all very dependent on the team and the individuals that make up the team, but also the management of stakeholders and their requirements, demands and expectations, and add to that: variations in team, management, etc. during development.
Additionally, the software itself has some weird characteristics: it is easy to change and it evolves. As more work is being done on the same codebase, the structure and quality of the code changes. Sometimes for the good, sometimes for the bad. This has its effect on the complexity of new work and thus on the time it takes to do the work. Work that was already estimated when you planned the project upfront. This moves you further away from your estimated time and budget targets; in a negative way, of course.
The misinterpretation of looking at software development as separate projects lays in the fact that software is never finished. Software development is a continuous process of putting effort in developing new and maintaining existing features. This is why agile methodologies, such as Scrum and Kanban, work so well on software development. It is a flow of continuous change that need to be managed. No upfront estimate for any software project of significant size will ever be correct and accurate at the same time. There's just too many factors of influence. You better manage these factors than trying to predict the future.
Choosing a strategy
So, what strategy to choose in replacing your legacy system?
The choice is very much depending on the agile maturity of your organisation and depending on the type of system you replace. In general, if your organisation is used to agile methodologies, and it is feasible to use an iterative strategy for your case, the iterative strategy is usually the best idea: you receive value early in the process and it increases as the replacement progresses. So even if the replacement takes several years, you’ve delivered more value and reduced more business risks than with the big bang strategy.
Further read
Big Bang adoption
Strangler Application, by Martin Fowler