Should we keep compatibility, or make a clean break?

The question behind the question

Every technology company eventually faces a design it has outgrown. The architecture limits performance, the language accumulates flaws, the file format cannot express what customers now need. The temptation is to start again. The question is who pays for the restart. A clean break moves the cost of transition onto users: their code must be rewritten, their files converted, their habits relearned. The site’s pattern compatibility becomes gravity describes how, once enough depends on an interface, keeping it compatible becomes more valuable than improving it.

When compatibility won

The clearest case in the record is the 64-bit transition in processors. In 1994 Intel and Hewlett-Packard set out to develop Itanium, a new 64-bit architecture designed from scratch around explicitly parallel instructions, abandoning compatibility with the x86 software base. AMD instead extended x86 to 64 bits with full backward compatibility, announced in 1999 and shipped in 2003. Customers could run their existing software and gradually adopt the new capabilities. Intel adopted AMD’s approach for its mainstream chips in 2004; Itanium lingered in high-end servers until it was discontinued.

The same logic runs through software. Microsoft’s TypeScript, released in 2012, added optional types on top of JavaScript rather than replacing it: every JavaScript program was already a valid TypeScript program, so developers could adopt it one file at a time. IBM’s System/360, announced in 1964, made an entire range of computers run the same software, so that customers could move to bigger machines without rewriting their programs, a decision that defined IBM’s dominance for decades. TSMC’s bet on immersion lithography in 2003 extended existing 193-nanometre tools with a layer of water rather than moving to a new wavelength that needed new materials, and it became the industry’s standard.

When the clean break failed

IBM and Microsoft developed OS/2 from 1985 as the successor to DOS, initially targeting a processor that could not run DOS programs well. Windows 3.0, which ran on top of DOS and kept existing programs working, took the market in 1990. IBM’s later attempt to position OS/2 as “a better DOS than DOS and a better Windows than Windows” conceded that compatibility was what customers valued. Lotus concentrated on a version of 1-2-3 for OS/2 rather than Windows and lost its lead in spreadsheets. Ted Nelson’s Xanadu designed hypertext as a coordinated system with two-way links that would never break, an elegant clean break from the messy existing world; Tim Berners-Lee’s web accepted one-way links that could break, worked with existing computers and networks, and won.

When a clean break was right

Clean breaks do succeed, and the record shows when. Apple’s iPhone of 2007 broke completely with the keyboards and buttons of existing smartphones, but Apple had almost no installed base in phones to protect, and the leading phone makers’ bases were built on a design the touchscreen made obsolete. The relational database replaced navigational databases over the 1970s and 1980s because the old approach imposed costs on every user every day, and the new one could be adopted for new applications first. The pattern is that clean breaks win when the installed base is small, failing or easily bypassed, and when the new design can be adopted for new work without requiring the old work to move.

A diagnosis to start from

The diagnosis rests on two quantities: the size of the switching cost users would bear, and the improvement they would feel in their own work. John Gourville’s research on new-product adoption suggests a rule of thumb: because users overweight what they give up and sellers overweight what they offer, a new product often needs to be many times better, not marginally better, to persuade people to switch. The site’s idea Loss Aversion and the Pull of the Status Quo explains the psychology.

The guiding policy is to change what is inside and keep what users touch: preserve interfaces, file formats and programming models, and improve beneath them. When a break is unavoidable, the coherent actions are a bridge (emulation, translation, a compatible mode), a long period of overlap, and a way to adopt the new design for new work first.

The strongest counter-case

The strongest objection is that compatibility can trap a company in a design that eventually fails. Intel’s x86 compatibility, which beat Itanium, also tied it to an architecture that struggled in phones, where ARM’s simpler designs won. Microsoft’s compatibility with decades of Windows software made its operating system harder to secure. Every compatible step defers a reckoning, and the debt can come due all at once. Clayton Christensen’s work on disruption shows established companies losing to newcomers who were not bound by their old customers’ needs.

The objection is right about the long run. But it argues for knowing when the installed base has stopped being an asset, not for breaking compatibility early. The newcomers who disrupted incumbents usually did so in new markets where there was no base to break with.

What the wider research says

Joseph Farrell and Garth Saloner showed in 1985 that users of a standard can suffer from excess inertia, staying with an inferior standard because each waits for others to move first. W. Brian Arthur argued in 1989 that technologies with increasing returns can lock in through historical accidents, so that the winner is not necessarily the best. Carl Shapiro and Hal Varian distinguished two strategies for a new technology: evolution, which offers compatibility and a migration path, and revolution, which offers compelling performance and asks users to switch. The record suggests evolution should be the default, and revolution reserved for when the old base is weak.