Rewriting Code from Scratch: A Detrimental Decision for Large Software Companies

When considering large-scale software projects, the decision to rewrite code from scratch should not be taken lightly. This approach often represents one of the worst strategic mistakes a company can make. Strikingly, software systems do not wear out in the same way physical products do. As long as a software system fulfills its intended purpose, there is no inherent necessity to replace it. However, this doesn't mean that code rewriting shouldn't be considered in certain scenarios. In this article, we will explore the implications of this decision, weighing the risks and potential benefits.

The Risks of Rewriting Code

One of the most significant downsides of rewriting code from scratch is the loss of historical context and solutions to existing problems. When a team rewrites code, they are essentially starting from zero, reintroducing and solving the same challenges that were originally addressed. This can be particularly problematic when the original codebase contained well-documented and effective solutions to known issues.

Additionally, the act of rewriting takes valuable time away from other critical initiatives. While a development team is focused on rewriting code, competitors can continue to innovate and improve, potentially leapfrogging your company. Rewriting the codebase can be a labor-intensive process that ties up resources and hinders the company's ability to stay competitive.

Cases Where Rewriting Might Make Sense

While the general advice is to avoid rewriting code from scratch, it is important to recognize that there may be situations where this decision is justified. Factors such as the complexity of the system, the technology stack, and the age of the codebase can influence whether rewriting is a reasonable option.

For instance, in scenarios where the software is part of an advanced system like avionics for a new drone capable of AI-based target acquisition in wartime, rewriting the system from scratch might make practical sense. In such a high-stakes environment, custom-built solutions can often offer the necessary security, performance, and reliability that off-the-shelf alternatives cannot.

However, for more typical business applications, such as a Customer Relationship Management (CRM) system for a midsized auto parts supplier with multiple warehouses, rewriting the code from scratch would be a catastrophic mistake. There are open-source alternatives available that can be easily configured and put into operation with minimal effort. Investing time and resources in building a solution from scratch would be far less efficient and more costly.

Principles for Strategic Decision Making

Following a general principle of buying before building is often wise. However, making such decisions should be done on a case-by-case basis, considering the specific needs and circumstances of each project. It is crucial to define clear goals and objectives for any potential rewrite. Before embarking on a major rewrite, stakeholders should identify specific areas for improvement such as performance optimization, security enhancements, interface modernization, or updates to libraries and frameworks. Failing to define clear goals can lead to unnecessary complications and potentially exacerbate existing issues.

Conclusion

The decision to rewrite code from scratch is a complex one that should not be made without careful consideration. In many cases, evolving and improving the existing codebase might be a more effective strategy. However, in situations where custom-built solutions are necessary or where open-source alternatives fall short, rewriting can be justified. Ultimately, the key to making the right decision lies in understanding the specific context and needs of the project, setting clear goals, and weighing the potential risks and benefits.