Scalable Human Blog

In the fast-paced world of software development, it’s natural to look at aging systems and think, “Wouldn’t it be easier if we just started over?” This sentiment often leads to what is colloquially known as the “big bang” rewrite, where a team sets out to rewrite a system from scratch. However, history has shown that this approach is fraught with dangers. In this post, we’ll explore the reasons why a total system rewrite might not be the best decision.

1. Loss of Business Logic

Problem: Over time, systems accumulate layers of business logic, often as a response to real-world challenges and unique edge cases. This logic can be subtle and not always well-documented.

Impact: A rewrite might unintentionally overlook or misinterpret this logic, resulting in a new system that doesn’t meet all the business needs or behaves unpredictably in certain scenarios.

2. Resource Drain

Problem: Rewriting a system requires a significant amount of time and effort. During this period, resources (developers, testers, etc.) are directed away from other potentially revenue-generating projects or essential maintenance.

Impact: This diversion can result in missed opportunities, decreased adaptability to market changes, and increased technical debt in other areas.

3. Extended Time Horizons

Problem: It’s notoriously difficult to estimate the time required for large-scale projects accurately. Rewrites, with their inherent complexity and unknowns, are particularly prone to delays.

Impact: As the project drags on, costs spiral, and the organization can lose faith in the development team. This can also lead to a longer time-to-market, giving competitors an edge.

4. Risk of Failure

Problem: Big projects have a higher risk of failing, either because they never get completed or because the final product is not up to par.

Impact: A failed rewrite can be a costly mistake, wasting time, money, and damaging the morale of the team.

5. Change and Growth

Problem: While you’re busy rewriting the old system, the world doesn’t stand still. Business requirements, technologies, and market conditions evolve.

Impact: By the time the rewrite is ready, it might already be outdated or not aligned with the current needs of the business or its customers.

6. Transitioning Costs

Problem: Switching from the old system to the new one isn’t just about turning off the old server and turning on the new one. It involves data migrations, user training, integration with other evolving systems, and potential downtime.

Impact: These transitional challenges can lead to additional costs, disruptions, and the potential for data loss or system outages.

7. Moral Implications

Problem: Suggesting a total rewrite can inadvertently signal to those who worked on the original system that their efforts were not valued or were misguided.

Impact: This can result in decreased team morale, potential loss of experienced team members, and a distrust between development teams and management.

8. Loss of Incremental Improvements

Problem: While waiting for the “big bang” release of the new system, incremental improvements to the existing system often grind to a halt.

Impact: Users are forced to endure current issues for an extended period, leading to decreased user satisfaction and potential loss of customers.

Conclusion

While there are cases where starting anew might be justified, it’s essential to weigh these considerations heavily. Rather than a full-scale rewrite, a more incremental approach, refactoring parts of the system piece by piece, might offer a more balanced path. This allows for continuous improvements, reduces risks, and ensures that the evolved system remains aligned with the ever-changing landscape of business requirements and technological advancements.

📚 Further Reading & Related Topics

If you’re exploring why a big bang rewrite of a system is a bad idea in software development, these related articles will provide deeper insights:

• The Dangers of Hero Culture in Development Teams – Learn how hero culture in development teams often leads to risky decisions, including big bang rewrites, and how fostering a more collaborative and iterative approach is healthier for long-term success.

• Navigating Software POCs: Balancing Project and Product Perspectives in Agile Teams – Explore how focusing on smaller, incremental changes rather than a big bang rewrite aligns with Agile principles, helping teams better manage scope and expectations.