The Veteran Neophyte: Manual Labor

JIM MENSCH

As a 14-year Apple veteran, why would I be writing a "neophyte" column? It's true that I've written system software for many Apple computers and I've been in every tech support capacity that Apple has ever dreamed of. I'm writing this because I'm in fact still wet behind the ears; I learn new things every day here at Apple. Most of what I learn involves problem solving and debugging. I believe that creative problem solving is the one trait that separates a great programmer from an average programmer. Great programmers must hone their problem-solving skills all the time, whether at a computer or not. In fact, sometimes examining how day-to-day problems are solved can help us develop proper coding and debugging skills at work. Here I'd like to relate a little fable to illustrate this point (the names have been changed to protect my automotive pride).

A FABLE

Bob and Stu were working on a primo 1963 Dodge Dart that they had just bought. It was a classic: push-button transmission, cherry upholstery, straight body. A classic car with a classic problem: it had been run dry of oil and the engine needed to be rebuilt. Flush with confidence (having just completed an engine rebuilding course at the local community college), Bob said, "No problem, man. Let's rebuild it ourselves; how hard can it be?" That, I suppose, was the first mistake.

So, Bob and Stu set out to rebuild the engine, using all new parts. A scant two months later, the ten-hour job was finished. Finally they were ready to install the engine. Struggling to get the 1000-pound engine into the car and onto two very small bolts that hold it at an angle too obtuse to allow it to drop in straight, they were cussing and cutting themselves constantly.

After a while it dawned on them that things were not going as planned. In a moment of brilliance, Stu said, "Hey, what does the manual say about installing this thing?" The manual! Every good car mechanic has a manual and follows it. Why didn't I -- er, Bob -- think of that? Reading the manual, they found that the torque converter (a big heavy round thing with teeth on it) was supposed to be mounted not to the engine but to the transmission!

They pulled out the engine and struggled for an hour to get the converter mounted to the transmission. After this the engine went in relatively easily (with the help of Thom the helpful Brit). Having connected all the hoses, belts, doodads, and whatnots, our intrepid pair looked at each other with giddy anticipation. "Could it be that we're ready to start this thing?" they wondered. So they tried to start it -- and they failed to start it. Just as with every major programming project, they had put in countless hours, and when the time came to fire the baby up, nothing happened.

It was time to debug this problem. "Hmm. Seems like a compression problem. Do we have compression?" asked Stu. "Yup, it's low, about 60%, but I guess that's because the engine hasn't been broken in yet," replied Bob. Were the plugs firing? Ground one side, turn out the lights, look for the blue spark: of course they were firing. Was the gas getting to the carburetor? Not yet, so they siphoned some up and tried again. Still no go.

So they started looking at the esoteric stuff. Was the timing chain on correctly? Well, we have compression, and it seems that we shouldn't if the timing is wrong. Three hours later, after Bob browbeat Stu into agreeing that the timing must be correct, Stu browbeat Bob into testing it anyway, since while Bob talked a good game it was always possible that he was wrong. They partly disassembled the engine and watched the little valve bits go up and down, and sure enough the timing was right. A victory for Bob, hollow as it may have been.

They continued to argue about what the problem could be, and finally decided to let it rest a while. This went on for weeks, until one day Bob remembered something that his teacher told him in class: a tablespoon of oil in every cylinder will get the seals sealing so that an engine could start. Could it be that easy? Could it be that the first thing that they had looked at -- the compression -- was in fact what was preventing the engine from starting? Bob put a little oil in each spark plug hole and the mighty engine roared to life! Our heroes stood dumbfounded at first, then quietly patted themselves on the back for such a fine job. Months after they had started their odyssey, they finally got the beast running.

YOU'RE NEVER TOO SMART TO READ THE MANUAL

The first thing to notice is that reading the manual was not the first step Bob and Stu took toward solving their problem. Neglecting to read the manual cost them hours of avoidable frustration and rework. Like Inside Macintosh, automotive manuals contain many hidden gems that are there for the asking. For instance, the shop manual didn't explicitly say, "Don't be a moron; the torque converter stays attached to the transmission!" but it did say, "Step 9. Remove torque flex plate screws, leaving converter attached to transmission."

Inside Macintosh contains many such tidbits waiting to be found. For instance, I was recently asked by a developer why a particular call to close a window wasn't causing the window behind it to redraw properly (it was leaving a desktop-patterned hole behind). Examining the problem a little further, we found that a resource that was needed had been purged and wasn't being reloaded. The code was smart enough not to crash when the purged resource was discovered, but it didn't seem to be able to reload the thing. As it turns out, the developer was using a rather strange strategy for manipulating the ResLoad attribute of the Resource Manager. He was turning it off when he wanted it off but not turning it back on again right away; instead he would turn it back on when he needed it on. I pointed out to the him that this was the problem, and he said, "I've been programming the Mac for almost 10 years and I've never read anywhere that the Window Manager assumes ResLoad is TRUE!"

While he's right about this on the surface, if we look we find that Inside Macintosh warns in the SetResLoad description that "If you call SetResLoad with the load parameter set to FALSE, be sure to . . . set [it] to TRUE as soon as possible. Other parts of system software that call the Resource Manager expect this value to be TRUE." (This has been in there so long that Caroline Rose wrote the first draft of it!) Since the WDEF is system software, it assumed that ResLoad would in fact be TRUE. After I pointed this out, the developer decided it was time to break out those manuals that had been collecting dust for so many years, and revisit some of the documentation he thought he had remembered.

YOUR FIRST INSTINCT IS USUALLY THE BEST

Another lesson to learn is that when problems arise, don't spend hours plodding through esoteric logic. First think, "What's the most obvious cause of this problem?" You might recall that Stu was right when he suspected a compression problem. By discarding the obvious without first examining it fully, we risk costing ourselves days of work only to find out that we were right all along. As a seasoned programmer, you'll learn that you can get a feel for why a problem exists. You may not have any ready logic to explain why an event occurred, but you might have a feeling anyway. Go with that feeling. The obvious things are the easiest to check (but don't make it too easy and stare past the real trouble). They're also usually the quickest to fix. Looking there first can save time, effort, aggravation, and lots of cussing. In my 14 years of problem solving for Apple, I've found that the simple, obvious solution is right 90% of the time.

CONFIRM YOUR LOGIC WITH REAL EXAMPLES

Why did Bob and Stu retest the timing, anyway? Experienced troubleshooters, they realized that simply arguing about a point may lead to a conclusion, but any conclusion that can be tested should be. Logic dictates that the cam shaft can be 180deg. out of phase (for every rotation of the cam shaft, the crankshaft rotates twice and thus will be in the same position at 0deg. cam rotation as 180deg. cam rotation), but you should check it anyway if you're stuck. It's easy to get your logical conclusions backwards and get your crankshaft 180deg. out of phase. On a car this might result in outright failure, while on a computer it can mean more insidious things.

I recently needed to use the Power Manager to control screen dimming, drive spindown, and CPU sleep. All of the calls had a "get" function that returned a Boolean, TRUE if the feature was on or FALSE if it was off. Strangely enough, two of the "set" calls required a value of TRUE to enable the feature but one required TRUE to disable the feature. I spent hours looking at the complex logic of IF statements before I simply watched it all go by in MacsBug and noticed that I was sending a TRUE value to a call named Disable. Going back through my logic again brought the error right out.

BACK TO WORK

If you've learned anything from the above tale, good. Remember, manuals contain quite a lot of information and they're a good place to start. Also remember that this isn't rocket (or automotive) science. Think simple thoughts; don't create extra work for yourself.

JIM MENSCH (mensch@applelink.apple.com, AppleLink MENSCH) has spent the last 14 years as a wage slave at Apple. Before that he did real work that involved cleaning and lifting and toting stuff and working with tools. While his mother is his real inspiration in life, he looks to the relaxed masses for guidance. An avid book collector and cook, he has absolutely no time for computers when he's not at work. His personal motto is "Eat more beets."*