The Second-System Effect

Fred Brooks described the second-system effect in The Mythical Man-Month: the second version of a system, built by the same people, tends to be overengineered.

The first system ships under constraints - tight deadlines, limited resources, uncertainty about what’s actually needed. These constraints force simplicity. You build what you need and nothing more.

Then you get to build it again. Now you know what you’re doing. You have time. You have ideas - all the features you wanted to add, all the “right” ways to do things you couldn’t do before. And you have a list of every shortcoming in the first version that you’re determined to fix.

So you build something bloated. Every edge case gets a feature. Every future need gets anticipated. The architecture is “flexible” in ways that will never be used. The second system ships late, if it ships at all.

Classic examples: Windows Vista after XP. The Netscape rewrite. Any v2 that tried to fix everything at once.

The fix is boring but effective: resist the urge to solve problems you don’t have yet. Iterate instead of rewriting. Bring in people who weren’t on v1 to challenge assumptions. Treat scope like a budget that’s easy to overspend.

The constraints that made v1 good weren’t bugs - they were features.