When to rewrite a code base from scratch

Question

I think back to Joel Spolsky\'s article about never rewriting code from scratch. To sum up his argument: The code doesn\'t get rusty, and while it may not look pretty afte

Answer 1

My answer is: rewrite from scratch as often as possible.

I've spent most of my career inheriting steaming piles of dung we politely called "programs", written by young, inexperienced programmers who were considered "rock stars" by the managers. These things are generally unfixable, and you end up spending 10 times as much effort keeping them limping along as you would have spent just rewriting them from the ground up.

But I've also benefited tremendously by rewriting my own work periodically. Every rewrite is a chance to do things differently and potentially better, and you should be able to reuse at least some parts of the older version.

That being said, not all rewrites are a good idea. Windows Vista, for example.

Answer 2

At some point, you have to cut your losses. If you've just inherited this code base, you might make changes that have unintended consequences, and due to the lack of tests, they'll be nearly impossible to find.

At the very least, start writing tests immediately.

Answer 3

I have been part of a small dedicated team that has rewritten code from scratch including reverse engineering business rules of the earlier code. The original application was web service written in C++ (with regular crashes and severe memory leaks) and a ASP.Net 1.0 web application and the replacement was a C# 2.0 asmx based web service and an ASP.Net 2.0 web application with Ajax. That said some of the things the team did and explained to management

1. We supported the existing code base in production until the new code was ready.
2. The management agreed that the rewrite (first release) would introduce no new features but just implement existing features. We added only 1-2 new features at the end.
3. The small team was comprised of very experienced developers with excellent understand ability and cooperation.
4. It was harder to get C++ talent in the organisation and C# was seen as a better alternative for future maintenance.
5. We agreed to an aggressive timeframe but at the same time were confident and highly motivated to work in C# 2.0, ASP.Net 2.0 etc.
6. We had a team leader to shield us from upper management and we followed scrum like process.

The project was highly successful. It was very stable and much better performing. Later it was easier to add new features. So I believe that code rewrite can be successfully done given right resource and circumstances.

Answer 4

First, understand this is a vertical integration decision. Whether you replace a COBOL application with a .NET one, replace one API (or version) with another, decentralize a stored procedure into the SQL queries which consumed it, or refactor to extract an operation from functions, this is a decision about what operations to integrate in your system.

McKinsey's article "When and When Not to Vertically Integrate" explains a lot of useful things I won't repeat, because I don't completely agree with everything they say. https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/when-and-when-not-to-vertically-integrate

The best answer I've read for this question is, "Ask yourself does it compete." And I'm sorry I've lost that article, but this is your business decision. You can change it later. You should weigh things like the difficulty of working in and testing the code, especially how easily you can extend processes and add new processes -- this is horizontal and vertical growth, refer to HBR's 1978 article "How Should You Organize Manufacturing." My architecture has no equal in that area.

We have an ASPX application which I could rewrite in my architecture and MVC, but because ongoing changes to the application are very rare (less than yearly) and minor, other things are better use of my time. Changing interfaces can give users whiplash too and should be a last resort. I even avoided adding new fields to a web page because of the manual data entry work it would've created for users. Immediate control is the first thing people grab for, but it does not compete when continuous control is absent, the ability to exchange control, e.g. cruise control.

Stored procedures don't compete with spreadsheets, because users can understand the calculations and tell whether it filters out financial data, unlike the stored procedure I had to give management the bad news about. That said, no centralized or distributed process competes with an integrated one. Centralization costs controllability.

White papers I've found here and there say refactoring is most often done to centralize processes and very rarely to decentralize them. My architecture defines how to organize processing and thereby eliminates the ongoing need to refactor entirely. This is because it is organized as a manufacturing system, which can easily grow and easily replace steps regardless of process length. There's never anything left to extract.

Answer 5

Joel's article really says it all.

Basically never.

As Joel points out: you'll simply lose too much doing it from scratch. It'll probably take way longer than you think and what's the end result? Something that basically does the same thing. So what's the business case for doing it?

That's an important point: it costs money to write something from scratch. How will you recoup that money? Many programmers ignore this point simply because they don't like the code--sometimes with justification, sometimes not.

Answer 6

Instead of a complete rewrite from scratch you want to start refactoring the code base in small steps while introducing unit tests. For example

1. Move duplicate code into a common class with tests for resuse throughout the project
2. Introduce interfaces to create separate testable modules. You can then refactor the implementation behind the interface while relying on your tests to ensure you don't break anything.