It’s really about another kind of code, but read on a bit...
This is an old dream: making the tax code shorter, simpler. From time to time, a politician of the populist persuasion comes out and promises to get things right. The ultimate expression for this drive towards simplicity is the Flat Tax movement: a single fixed (as opposed to today’s progressive, accelerating) tax rate for everyone. Google ‘‘flat tax” and you get more than 40 million hits. A popular fantasy. And not one just held by kooks, conspirationists and other End of Times prophets. Stanford University hosts the very serious right-wing Hoover Institution, a think tank that publishes scholarly papers such as this one. Or we have Steve Forbes, as in Forbes Magazine, proudly posing, postcard in hand, on the cover of his book: Flat Tax Revolution: Using a Postcard to Abolish the IRS.
Fun stuff, or sad, you pick your perspective. (Speaking of fun, this note’s title is a reference to a cult movie: Honey, I shrunk the kids!)
The basis for the agitation is a feeling of hopelessness. Year after year, we add articles to the tax code, to adapt to new circumstances, to new projects, to plug loopholes. As a result, the code grows and buggier.
This latter phrase, “the code grows fatter and buggier”, also applies to our high-tech spaghetti code: operating systems. Every new rev served with fresh bugs!
Software is… soft, malleable. Next to hardware, adding/changing features is comparatively easy, tempting. With features added upon features, bug fix patches over earlier generations of patches, the whole edifice soon starts to look like the accumulated layers of a Babylonian archeological dig.
Over time, the mess resulting from this “organic” growth gets worse and worse because OS developers are caught between the past and the future.
Looking forward, happily fueled by relentless technical progress, our industry constantly comes up with new hardware features and more modern software techniques. These improvements result in new ways application programs “talk” to the system. We use the acronym API (Application Programming Interfaces) for the way application software accesses OS resources.
Looking back, companies and individuals have huge investments of money and people in application software. OS improvements can’t come at the expense of backward -- an ominous adjective -- compatibility.
When making improvements, the system must add new APIs and keep the old ones around. Add but never subtract: he result is bloatware.
Let’s try a metaphor using musical instruments. The musical score is the application software. The API is the set of rules the composer must use to write music for a particular instrument.
Using the violin as an example, beside simple notes, its API allows glissandi, pizzicati, col legno (“with wood”, meaning using the bow’s wood instead of the side holding horse hair) and other subtle pitch variations.
Now, moving to the piano, we could say it has more expressive power than the violin because it can play more complicated scores, with a wider range of notes. Does this make its API a simple superset of the violin’s? No. While these instruments have many capabilities in common, there is music written for the violin that can’t be played on the piano and vice versa. You’ve got to keep the two ways, the two APIs around. So do operating systems.
Not a problem for music, we love baroque music as well as the saxophone.
For computers, the accumulation of API’s starts as good deed, compatibility, and ends up as a punishment, unfathomable bloatware. We’re sentenced to OS code that becomes so entangled that it ceases to be understandable, so complex that even the sharpest of programmers can’t build a mental representation of its architecture, let alone its implementation. As a result, patches, bug fixes come with prayers they won’t make things worse.
There is no easy way out of this cancerous growth.
Most of the time, OS makers work hard at stabilizing the patient. From time to time, they manage to excise some really old bits that finally fell out of use. One such example is Apple obsoleting (most of) the PowerPC compatibility bits out of OS X, after the 2005 move to Intel.
OS builders ca also carefully rebuild a module, they do what’s called a “clean rewrite”. Simplifying a bit, an OS module is like a administrative office with many windows. You present a request at a window, it’s processed inside and results come out. The windows are the APIs already mentioned, the results are actions such as drawing an object on the screen, updating a file on disk or sounding a beep. In theory, you don’t need to know the inner workings of the office. All you need is knowing the rules, knowing how to deal with what goes in and what comes out of the “black box”. So, in theory, the place where one of my engineers said he wanted to move “because everything works in theory”… In theory, then, if you’re unhappy with the way an OS module works, if you now have better ways to implement a given “black box”, if you have a new programming language, off you go with a clean rewrite.
But, in reality, “where things don’t work so well”, bad things happen between clever programmers and OS modules. Looking for performance, or ways around limitations, or defending against known or suspected bugs, programmers reach inside the “black box”, they devise their own tricks. Going back to the admin office metaphor, imagine someone discovering the internal phone directory. Then, instead of dialing the main number and presenting a “well-formed”, general request to the operator, they direct-dial the nurse and request an aspirin. Clever, simpler, quicker.
But… later, the admin office is reorganized, this is the clean rewrite. The nurse’s office is subsumed into a more general-purpose HR (Human Remains Resources) department, the old internal phone directory is obsolete and, in any event, the request for an aspirin must be done in two steps, not one: first ask for HR, then as for an aspirin.
Back to computerese, we use the phrase “private API” for such tricks. Sometimes they’re discovered by enterprising application programmers; sometimes their hidden by the OS programmers for their own use; sometimes they’re devised by OS makers for “competitive” purposes. Microsoft was accused of letting Office or Internet Explorer programmers use “OS hooks” unavailable to competitors.
In any event, the clean rewrite isn’t as (conceptually) simple a task as one initially imagines: the “black box” is grey, its messy insides are visible.
So, OS makers seem to be left with a stoic, resigned fight: palliative care against malignant code growth.
There could be one exception, though: the iPhone OS. When I first saw the January 2007 iPhone demo at Macworld in San Francisco, I thought Steve Jobs was having his way the facts: about 8 minutes and 30 seconds into his presentation, he claimed the iPhone was running OS X. Impossible, I thought. Six months later, geeks opened the iPhone and its software and found out: indeed, the iPhone was running a version of OS X recompiled for the ARM processor. A pared down version, but the real thing nonetheless. And, three years later, the iPhone OS having matured, will now run inside the iPad.
OS X successfully “shrunk”!
This wouldn’t be too important if the iPhone and the iPad were mere sideshows in the huge computer industry. But what’s happening before our very eyes is a new beginning: smartphones are the really personal computers, they are the new wave of computing. You’ll recall these slides from the Mary Meeker’s Oct 20th, 2009 Morgan Stanley presentation:
A look at Apple’s financials shows their iPhone business is now the most important one: largest revenue, biggest profits and fastest growth. No longer a sideshow, smartphones are now the main act.
Let’s compare market capitalizations. Dell: about $27B, Acer, the rising PC maker from Taiwan, about $8B. RIM, the Blackberry smartphone maker, $39B. Nokia, $51B. (Apple’s market cap is $190B but it contains PC, smartphones and MP3 players components that make a straight comparison difficult. Still, if you only attribute half of the total amount to iPhones, it makes a nice $95B number to compare to a straight PC maker such as Dell.) Wall Street seems to agree smartphones are the next PC wave.
Put another way: Steve Jobs reboots its PC business using a “shrunk” OS X.
Apple achieved two unusual feats: paring down its OS and taking a lead position in a new computing platform race.
Microsoft couldn’t pare downsize its desktop OS to create Windows Mobile. And now, for its “Windows Phone 7 Series”, it wisely went with a really new, unencumbered OS. Wags will say the new mobile OS is no longer afflicted by System 32 directory filled with DLLs.
As sharp-eyed readers have already detected, there is a bit of “now you see, now you don’t” in the way I’m presenting Apple’s OS shrinking feat. The company didn’t really manage the double exploit of drastically paring down a desktop OS that takes about 4 gigabytes on the distribution DVD and maintained applications compatibility. In rebooting to a new platform, the iPhone/iPod Touch/iPad, Apple breathed a heavy sigh of relief while leaving existing applications behind and creating a brand new, well (some say overly) controlled applications world. No more begging for application software like in the early Macintosh days.
And other no less attentive brains will have seen another nuance in today’s story: Linux on smartphones. Android is based on Linux, so is Nokia’s Maemo, even before gobbling Moblin, Intel’s also Linux-based Mobile Internet Device platform. The desktop or server Linux OS, in one or more of its many forms, was pared down to fit smartphones. And just as in Apple’s case, there was little concern for backward application compatibility.
One last twist: OS X is a certified Unix 03 operating system. See here and here. Apple got a nice certificate to put on a wall somewhere in the Infinite Loop campus in Cupertino:
Seriously, I don’t think Apple will seek Unix certification for the iPhone OS. But he parallel between three of the leading smartphone brands, Nokia, Android and Apple, is interesting.
And, of course, after the OS reduction comes the sad, ineluctable adding of layers and patches. Further down the road, we’ll have hardware incompatibilities, more modern APIs having to coexist with old ones for the sake of backward compatibility with hundreds of thousands of App Store titles.
As we say in English: Plus ça change...
It’s really about another kind of code, but read on a bit...