Why the Second System Effect traps so many

Little by little we make too much.

After an app or system does well, there’s often talk about version 2 or phase 2 or release 2. The promise of fixing all the gaps from the first system get pushed into the promise of this second system.

Moreover, the scope of the second system expands. Hubris runs rampant for all those involved in the project until timelines slip and then slip again.

This is the Second System Effect.

Let me share with you a sure fire way to ensure your project becomes an example of one.

Ignore the lessons of the past

"The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one." - The Mythical Man Month

That quote may sounds just like scope creep. But it's not mere scope creep. It's scope creep you had judiciously avoided in the past.

But now it's almost like a reward to indulge in trying a hand at the things you correctly avoided before.

Worse yet, there's a natural progression to how systems get made over time. As the state of the art has moved along when you go to implement features you once refused to make, there's a tendency to be making features that people no longer want.

In the Mythical Man month, it was noted that most of the designers of the system began to incorporate features in OS/360 for the IBM evolutions to the ideas found in the prior system that they were explicitly moving away from. In short refinements and embellishments to features that were no longer needed.

Like making improvements to hitch on a carriage in 1920s, it's not that it's useless, but it's soon to be useless.

This Time It'll be Perfect

This allure for perfection is always there when building a system. However, the second attempt holds the promise of perfectly avoiding the mistakes of the past. This attitude usually means you lack respect for the first system, the system that actually enables you now to be able to detest it because it was successful enough to employ you.

Among the various risks of seeking perfection, one major risk is the choice of not wanting to release even a test version that is anything less than perfect.

One notable example is Multics, short for Multiplexed Information and Computing Service. It aimed to create a highly secure and efficient operating system for time-sharing on mainframe computers. It was giant effort involving MIT, Bell Labs, and GE.

Due to the desire to incorporate numerous features and the lack of a clear focus, Multics took much longer to develop than anticipated and was very costly—$3-4 million per year across 5 years in the 1960s or in aggregate $200 million in 2023 dollars. At its height, development involved about 110 people.

Bell Labs eventually withdrew in 1969 and went on instead to make Unix directly from the lesson of the "increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier".

Multics as an operating system is no longer in use whatsoever. However, the direct consequences of its failure was to build smaller modular tool sets rather than larger monolithic tools.

Forget what makes you successful

Fundamentally, the Second System Effect is more about forgetting about how and why you were successful in the first place. So you might make several subsequent systems and only much later fall into the trap.

It was 2002. Microsoft was the undisputed king of both the web with Internet Explorer and computing. Apple and Netscape were limping along.

Windows XP had just released the prior year and the company was soaring high. It had hit a cadence of releasing a new version of Windows about 12-18 months or so, and development of Longhorn had been underway already in 2001.

It should have been close to getting to release in 2002. But it never did.

For whatever reason, 5 years later in 2007, it stumbled out the door as Vista.

A version of Windows so universally hated that Microsoft tried to make special ads to re-introduce it to people under a different brand—after they incrementally fixed all the bugs and user experience issues.

One of the things that made Microsoft so dominate in the 1990s was that steady cadence of incremental improvement. When an organization shifts to large leaps rather than steady improvement, it’ll get neither.

The building of systems is incremental wins, not large leaps.

Finis

Remember these things when building a second system:

• Repeat what you avoided when building the original system.

• Know that you won’t make the perfect second system.

• Remember why you succeeded before and build on those wins.