Comparison
RewritevsSecond-system effect
Rewrite
you decided to start again, and the old system kept receiving feature requests the whole time.
Replacing a system with a new implementation rather than evolving the existing one. It is occasionally correct — when the platform is unsupported, the model is fundamentally wrong, or the thing is small — and it is usually chosen for the wrong reason, which is that reading the old code is unpleasant. The costs that get missed are the undocumented behaviour the old system accumulated and the feature freeze that never actually holds.
Full entry →Second-system effect
the rewrite is going to fix every compromise in version one, all at once, and it is nine months late.
The tendency for the replacement of a system to be bloated with everything its designers wished they had done the first time. Brooks named it because the first system is disciplined by ignorance and the second by none: the designer now feels expert, has a list of regrets, and there is no user yet to say no. It is the standard failure mode of a rewrite, and the reason to ask which of the new features are load-bearing for the migration itself.
Full entry →