3 ms·

I's mostly agree with this. But I'd note for the OP that "complete rewrites" are not necessarily guaranteed failures. It depends how it's done and what the goa

I's mostly agree with this. But I'd note for the OP that "complete rewrites" are not necessarily guaranteed failures. It depends how it's done and what the goals of the rewrite happen to be. The two types of rewrites I've seen be successful: 1. Ship of Theseus rewrites. This is where small modules/segments of code in the project are completely rewritten and integrated back into the whole. This has the advantage of being able to test the new code against existing data constantly, get user feedback, etc. Over time, the entire project has been rewritten, but the benefits (for the cost) have been proven at every step. And you get repeated buy-in from everyone involved from management down to end-users. 2. Massive change of requirements. One may argue (successfully) that this may not actually count as a rewrite as opposed to just being considered a new project. These are usually successful when the project being replaced is notoriously bad/complained about by end-users. But, the same concerns still exist: no benefits are seen until done, potential loss of functionality, new bugs, lost knowledge (read: edge cases not ported), etc. Ship of Theseus rewrites are successful quiet often. The others... yeah, not so much. It's rare. But, it can happen.

gregjor 5y ago
The OP asked for horror stories. I didn’t mean to imply rewrites can’t work, only that I’ve never seen it work (in 40 years programming). My very first programming job at Nike was what was then called a “conversion,” moving a working code base from one platform (PDP-11) to another (DECSystem 20). Conversions were common rewrite-type projects back then (‘70s) because every vendor and computer model had a unique OS and set of languages and tools. That project succeeded. Throughout the project the project manager (one of the best I’ve worked with) resisted every attempt to expand scope so we could focus on getting the current functionality working on the DEC 20. It was partly automated and then required line-by-line examination of the source code and rigorous unit testing. I wouldn’t call it a ground-up rewrite, no new features got added and we had a working system to start with. It was more like an evolution. I worked on other conversions early in my career and they mostly got derailed when management and users took the opportunity to “enhance” what was working as part of the straight conversion, and/or when the programmers were allowed to get carried away adding functionality themselves.

gregjor 5y ago

The OP asked for horror stories. I didn’t mean to imply rewrites can’t work, only that I’ve never seen it work (in 40 years programming). My very first programming job at Nike was what was then called a “conversion,” moving a working code base from one platform (PDP-11) to another (DECSystem 20). Conversions were common rewrite-type projects back then (‘70s) because every vendor and computer model had a unique OS and set of languages and tools. That project succeeded. Throughout the project the project manager (one of the best I’ve worked with) resisted every attempt to expand scope so we could focus on getting the current functionality working on the DEC 20. It was partly automated and then required line-by-line examination of the source code and rigorous unit testing. I wouldn’t call it a ground-up rewrite, no new features got added and we had a working system to start with. It was more like an evolution. I worked on other conversions early in my career and they mostly got derailed when management and users took the opportunity to “enhance” what was working as part of the straight conversion, and/or when the programmers were allowed to get carried away adding functionality themselves.