It's a generally accepted principle in programming that when you release a newer version of your software you should remain backwards compatible with older versions of your software (or content that your software produced). If you make a word processor, version 2.0 better open documents created by version 1.0 or you're doing something wrong. Apple is one of the few companies brave enough to throw away backwards compatibility and they've proved that if you do it right you may take an initial hit but in the long run it's worth it.

It's a generally accepted principle in programming that when you release a newer version of your software you should remain backwards compatible with older versions of your software (or content that your software produced). If you make a word processor, version 2.0 better open documents created by version 1.0 or you're doing something wrong. Apple is one of the few companies brave enough to throw away backwards compatibility and they've proved that if you do it right you may take an initial hit but in the long run it's worth it.

Doing It Right

In 2001, Apple released Mac OS X and the Cocoa and Carbon APIs. Mac OS X was an entirely new operating system (with NeXTSTEP roots) with no ties to Mac OS 9. Apple made it clear that Cocoa was the future and Carbon was a stopgap solution. They didn't wholesale dump all the previous developers but they let them know that times were changing. They provided the ideal while recognizing the reality of the situation required an older solution to remain in place. In 2012, the Carbon API was finally retired (11 years after Mac OS X was introduced) and will no longer be updated. Programmers need to know they have long term support if they invest in your technology — Apple provided that while also introducing a completely backwards incompatible, more "ideal" technology. When the iPhone SDK was released in 2009 it was completely forward looking — you used Cocoa Touch and you liked it. No existing applications worked, and most couldn't be ported.

Apple continued the trend of introducing dramatic changes to software on the consumer side with iMovie '08 that removed many of the features from iMovie HD 6 while simplifying the interface for casual users. To sate the appetites of the power users, Apple also released iMovie HD 6 as a separate (free) download on their website. When iWork '13 came out, Apple again drastically simplified the interface (and feature set), throwing away all of their older code base to work toward the ideal. For their power users, Apple kept the older iWork 9 installed as well.

You Can't Please Everyone

Windows 8's "Metro" interface is a joy to use on a tablet. Its use of gestures and multitasking is unrivaled by both Android, iOS, and even the late WebOS which pioneered gesture controls on tablets. Unfortunately, Metro is a nightmare to use on a Desktop (where most people will encounter it). It was so poorly received that in the Windows 8.1 update it was completely bypassed when starting the computer. Desktop users now boot straight to the old Windows desktop. At the same time, tablet users of Windows 8 (and strangely, Windows RT) are given the option to use the classic desktop and desktop applications as well. The classic desktop on a tablet is basically completely unusable, filled with tiny tap targets and either unreadable or gigantic text. What Windows 8 on tablets needed was a great divorce from the desktop. What Windows 8 on desktops needed was a fresh coat of paint, updated APIs, and to be left alone with the classic Windows 7 UX that everyone knew and loved. The only problem was that Microsoft wanted developers to produce WinRT applications — they believed that if they forced the Metro interface on desktop users (where it was unnatural) it would compel developers to produce for the large audience. At the same time, in order to sell WinRT tablets, Microsoft believed they needed Microsoft Office (and the classic desktop interface) on Windows RT. As they say, no guts, no glory. Windows RT tablet sales have been abysmal and Windows 8 (which is driven mostly by OEM sales) hasn't seen as great a reception as Windows 7.

Google, on the other hand, decided on a different approach to tablets that was also flawed. In order to alleviate the burden on developers (and pretend to have tablet apps), Google built guidelines on how to have phone apps scale to the size of tablet screens. Unfortunately, they were just guidelines. Android tablets were completely backwards compatible with phone apps and thus most developers just ignored tablets. An ideal solution would have meant more work for developers — a break in backwards compatibility with all the phone apps. It would have also meant that users would have had an easier time finding quality applications for their Android tablets — applications that were guaranteed to have at least some amount of thought and effort put into their interface. Apple, on the other hand, did somewhat of a placate-and-shame approach with the introduction of the iPad. iPhone applications were supported but only in a windowed interface that made your application usable but obviously a phone app. These applications could only be downloaded by explicitly saying you wanted iPhone applications, they weren't allowed to pretend to be tablet apps.

Stagnation

Developers have proved over and over that they're more than happy to move on to the latest technology. Node.js is all the rage, LESS, SASS, CouchDB, Mongo, Ruby, Python — all of these are technologies that either sprouted to life in the past 10 years or gained renewed interest and fervent fan bases. Why have they moved on from more established and popular languages? Because they're conceptually closer to the ideal the developers strive for. PHP may be more mature, faster, and has a much larger support base than many competing languages, but that doesn't matter to many developers for one simple reason: PHP will NEVER fix many issues that are broken at the core due to backwards compatibility. The functions strpos and str_replace will never both start with the subject string and strpos will never become str_pos. Could these kinds of things be easily fixed in a backwards-incompatible release of PHP 6? Sure! And they could continue to support the PHP 5.x branch for ~10 years while striving towards an ideal language in PHP 6.

The same problems in PHP occur in all the popular CMS's — WordPress, Drupal, Joomla. Their large communities have created swathes of plugins and extensions. The core development teams are crippled — they can't release a truly great new CMS that fixes all the mistakes of past releases because it would break backwards compatibility. WordPress has a global function named the_content() that has survived through version 3.9.1 (the latest release at the time of this post) — need I say more?

Trust Your Users

Don't change things just to change them but don't be afraid of changing things because of the potential fallout either. If something is truly better, it should replace the older, more comfortable solution. Your users may balk at first but if you explain the change they'll be understanding and most will grow to appreciate it. Don't lock yourself into your past mistakes, but at the same time support users who (for whatever reason) enjoy those mistakes or need time to adjust. Make great software, even if it means leaving your older, incompatible software to rot in only-bugfixes-from-here-on-out bin.

Share on Twitter or Facebook Published June 17th 2014