Backward Compatibility vs Innovation – Why Apple Leads
In the tech world, there is a reoccurring question that gets debated in marketing, design, and engineering departments—backwards compatibility. It goes like this: a company has existing customers / users of its products, and wants / needs to factor these in when making a new revision of an existing platform or product. Take the example of a spark plug—it has to work in your car, since you are not going to throw your car away when you need a new one.
At a recent analyst conference, Apple COO Tim Cook got me thinking about Apple’s take on the subject:
“How do you protect user experience as developers develop products? This is the privilege and curse of technology—at some point, if you include every hardware you’ve ever shipped, you stifle innovation. Because we’ve done this for so long, I feel like we’ve come to a really intelligent conclusion on these each time. I think that’s part of our knowledge and heritage as a platform provider.”
Backward compatibility can create feature bloat and make a product slow and cumbersome. Conversely, it’s really easy to piss people off—not just customers, but complementary services / developers. Backward compatibility can be achieved through emulation (Apple did this moving from PPC to Intel), but it’s not seamless. So how much time should a company spend taking into account the ecosystem, usability issues & concerns of their captive audience / installed base?
The answer depends. Consider APIs (application programming interfaces) as an example. An API can be a liability if designed wrong—constant source of support headaches. APIs also “capture” customers (they take a long time to learn, and the switching costs are significant). Public APIs are forever – you can add to them but cannot say “this call was a mistake” or you will break people’s programs. That’s why, when developing an API, if there is any doubt, good developers omit the feature. Something can always be added later, but it cannot be taken out. Good code is modular and inter-code module ties are effectively APIs. So these same concepts apply broadly to non-public APIs.
The most intelligent companies put incredible strategic thought into what features to include during the architectural and design phase. In general there is an inverse relationship between how feature-rich a product is and its ability to be backward compatible from generation to generation. This is one reason Apple’s products are so minimalistic. This design philospohy keeps feature-bloat in check, and helps platforms to evolve compatibly with the previous generation. This concept also explains why Apple tends to keep a tight control on their platform.
Here are some other examples:
Google Android is already experiencing a lot of fragmentation and backward compatibility issues today – many of them stem from the platforms ‘openness’ – e.g. developers using non-public APIs that they have been repeatedly warned not to do. This has been a big turnoff for Android users. Also, the issue is recursive since differentiation on an ‘open platform’ like Android encourages designers to differentiate via features, causing more and more fragmentation.
Microsoft is another extreme – they go to great lengths to appease developers and make Windows work between generations. Dependencies in their code are enormous. By attempting to keep every API going back to Windows 95 (3.1?), even with bug-compatibility, they have a bloated, brittle, heavy platform which ultimately detracts from the user experience. Strategy: make it useful to all – displease everyone equally.
Intel should be discussed in the context of PCs vs mobile (more on their mobile issues here). The x86 architecture has become a liability for Intel in handsets. RISC/ARM processors (95% share of mobile) are better designed in terms of transistor count, die size, and power consumption. Why? Because Intel added tons of instructions (multimedia/MMX etc) into x86 for PCs—not needed in mobile. That’s why Intel has zero market in mobile, and are trying to catch up using manufacturing scale (process technology) which isn’t likely going to cut it.
Apple gets lambasted continually by the press for leaving out features that people ‘need’. The reason is intimately tied to their perspective on user experience and backward compatibility. The reality is it takes unbelievable engineering and a vision to move a platform forward while at the same time making sure things don’t break. Apple has mastered this—it’s part of their DNA and design heritage, and it’s why they will likely continue to be a dominant platform company.