Published October 22, 1998

Any Sufficiently Advanced OS Is Indistinguishable From Magic

We spend a lot of time talking about our favorite OS. It fuels the Silicon Valley empires, makes for spirited conversation, and makes us feel part of something bigger. It's almost a religion for some. But there's a problem. Somewhere along the way, perhaps around 1990, our OSes outstripped our ability to understand them as a whole. We fancy ourselves computer technologists, but, in fact, we've become shamans.


Learning the Offense

There was a time when one could completely understand a personal computer. In the days of the Apple II, we had the famous "Red Book" that documented the 2 kilobyte ROM. One could look up where the code was that loaded data from cassette. One could memorize the address where the disassembler started. So why is that a big deal? It's a big deal because, today, we routinely use computers and OSes that we can't possibly understand, but we like to think that we do anyway. It's the grandest illusion of our time.

It all has to do with how much time it takes for the human mind to achieve mastery.

I was watching Monday Night Football, and Boomer and Dan were talking about Miami's fragile and injured pass receiving corps. Boomer mentioned that a new player, perhaps part of a trade, might be able to learn the Miami offensive system in four to six weeks and become useful. Astounding. Many hours a day and more study of the playbook in the evening for possibly six weeks to learn a pass offense!

Now, I'm not going to get into a discussion about how smart these guys are. We know that if they were a lot smarter, they wouldn't be playing football for a living. But it got me thinking about the time it takes to become an expert in something. Anything.

Counting the Hours

Based on some personal experience, I calculated that it takes about 15,000 hours of study, starting in high school and ending with a Doctorate (over a period of 15 years) to become a physicist. Add another 4,000 hours over two years as a postdoc, and you're ready to make a contribution to the world of science.

I have a friend who flys 727s for United Parcel Service. He reports that it takes 9 to 12 years to work up from 2nd officer to first officer to Captain. It's hard to pin down the number of hours required, but by the time a pilot makes Captain and sits in the left seat, he usually has several thousand hours of flight time.

Of course we're all familiar with what it takes to master ice skating or the balance beam in the Olympics. Every four years we hear the young athletes talk about how they get up at 5 am, drive to an ice rink an hour away, and practice for four hours. Six days a week. From age 4 to age 16. That's about 15,000 hours.

Do you see a pattern emerging here, Sculley?

Now lets move on to computers. An Operating System with 10 to 30 million lines of code is, of course, written by a team of people over a period of many years. Each programmer is assigned a particular segment and that often leads to specialization. One programmer takes, for example, TCP/IP, another takes the File System, and another might take GUI admin tools. No one programmer can possibly understand the whole system. There just aren't enough hours in a day to do ones job and understand every other person's specialty as well. But the Chief Architect, or project manager, call her what you will, will likely have a good overall grasp of the OS, albeit without a deep understanding of all the code details. Assuming 10 hours/day over a period of four years, a Chief Architect can expect to invest about 10,000 hours in her "baby".

Are you beginning to get a feel for what it takes to achieve mastery?

Now let's look at the average software developer working for a software company. For the sake of argument, I'll use an eight hour day, even though that's conservative in most cases. He or she will spend, I estimate, about 7 hours a day writing and debugging code and about 1 hour a day learning the ins-and-outs of the host OS in order to get the job done. This may be higher initially when the project starts and will likely drop off as the project nears completion. This amounts to about 240 hours a year learning the fine details of the host OS. Over a period of years, they start to approach the thousand hour level in OS expertise. These people, justifiably, consider themselves fairly knowledgeable about the OS they are working with.

Four years writing code for an OS. That's what it takes before one can even think about saying something intelligent about an OS. Still far from mastery.

Systems That Are Too Complex

So let me ask you: how many hours a day do you spend studying the technical details of your OS? I think it's safe to assume that very few of us get to the point where we are really distinguished experts on a particular OS. One might look at a MacAddict article with a blowup of the screen and call outs describing various functions. Then one reads the body of the article about the jazzy new features, and be off and running. After using the OS for an hour a night reading e-mail and surfing the Net, one then decides that he knows everything about that OS.

Then, to complete the illusion, one reads about the "enemy" OS here and there, whichever that might be, and comes to the exciting conclusion that his OS is superior. After what? A few hundred hours of hands on experience? And zero with the enemy OS.

This is exactly why you see so many differing opinions about OSes on the Net. Every different person has a different level of mastery, and their utilization profile is different as well. About the best most people can do is shop around until they find someone whose opinion matches theirs and hang on for dear life.

Now we're getting ready to make a quantum jump. Windows 9X will give way to NT in some kind of consumer variant. Apple is getting ready to unleash a Unix-based system on us, but wrap a really nice GUI on top so we don't see the horrendous complexity underneath.

The really scary thing here is that in a little over a decade, we have gone from DOS and ProDOS to NT and Unix in the hands of consumers. What's worse, for sake of appearances and commerce, we are being led to believe that these OSes are just what we need: more powerful, less likely to crash, and more features. We are all playing along with that because the vendors of these OSes, driven by technology and market pressures, have no choice.

Complexity Can Come Out oF Simplicity

When I was at White Sands Missile Range in the early 1980s, I worked on a military combat model. The model, at that time, had about 180,000 lines of Simscript code. It was technically an expert system since our military colleagues spent a lot of time creating decision tables that implemented military doctrine. (As an aside, the model was designed to simulate the engagement of NATO tanks and helicopters defending a Russian/East German ground assault into West Germany.) One of the things we learned was that a huge collection of simple routines combined with the decision logic could lead to unexpected results.

Even though we obeyed the rules of programming, kept our routines short, and made sure we understood the output for a given range of inputs, when the model ran, the sequence of calls to the routines depended on a lot of factors. The model was completely stochastic, so initial conditions like the weather, placement of the defending forces, and attack scenario all combined with random events during the battle to produce complicated, random, and sometimes unexpected outcomes. As a result, we had to build extensive audit capabilities into the model so that we could conduct a post mortem and make sense of the results.

The point here is that you may have a lot of simple routines, but in a complex system, the sequence of the calls and the great number of calls to routines combines to obscure the logic. A human can no longer follow the sequence of events or indeed make good predictions of the outcome - except on the most global scale. For all practical purposes, the result is magic.

Unlike a combat model, however, where it was vital to understand the sequence of events that led to an outcome, so we could evaluate the effectiveness of various weapons, the whole philosophy of an OS is to obscure from the user the decision tree. For example, if I were to observe that my router's activity lights suddenly started furious activity, I would like to get a report from the OS explaining what was happening. But because MacOS X is Unix, Apple will likely go to a lot of trouble to hide the messy details of what that kernel is up to. We want the user to be happy and content. We don't want the user asking a lot of irritating questions about what's happening. The answers, if even framed in an understandable form, would curdle his blood.

And that's the problem.

We are forced, as users, to depend on a system that we can't possibly understand. Because the modern GUI can only do so much in terms of revealing the inner happenings of the OS, we're forced into our own kind of magic. We make up a mental model of what we think is happening. Every time something strange and unexpected happens, we modify our mental model in order to explain the events we observed. Sometimes, we're not such good observers and then our model betrays us. Frustration with the OS kicks in.

Essentially, we're like scientists observing interactions in a particle collider. We use our imagination and experience to build a logical framework, one that we think explains the events. We test our theories by comparing them to experimental results and modify them as necessary. If we're really good, we end up with a satisfactory mathematical model of nature.

As I said above, it takes many thousands of hours of study and training to be able to do that in science. We're getting to the point where our desktop OSes are so complicated that we're forced into the same strategy as the scientist trying to discover the laws of nature. If the complexity effect kicks in at 180,000 lines of code, pause to reflect what it will be like in NT 5 with over 30 million lines of code. (I don't have the number for MacOS X, but a good guess would be 10 million.) The problem that we face is that it's going to take more hours than we care to spend building an accurate model of the inner workings of our new OSes.

What we're going to end up with is people who have a few hundred, not tens of thousands of hours of expertise, debating the merits of MacOS X versus NT. It will be like monks in a temple in Tibet arguing about how many Angels can fit on the head of a pin. Actually, religion might be just the right metaphor here.

It's All Magic...

...according to Arthur C. Clarke's Third Law. And that's exactly what we have today. No more 2K ROMS. No more OSes that can fit in 64K of RAM. The operating system of today takes many hundreds of man years to write and is, for all practical purposes, magic.

A few weeks ago I encouraged you to learn all you could about WindowsNT so that you could earn some credibility with management. That's still good advice. But it's one thing to learn enough about an OS to make intelligent business decisions regarding implementation, and it's quite another to, with a few hundred hours of study, make { scientific, technical, religious } [choose one] assertions about these new OSes. You can safely skip that part.

I would say that if you want to truly become an expert in the MacOS X and Windows NT systems, be prepared to devote most of your future either studying it or writing applications in order to learn about it.

Otherwise, pick the OS you like, use it, and get on with your life.

Copyright 1998, John Martellaro