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

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.