Troubleshooting Mac OS 9 was largely a set of black-box procedures. Recall this conversation, early in the computing experience of many Mac users: “Zap the PRAM, start up without extensions, and rebuild the Desktop.” Why? “Because it fixes a lot of things.”
Mac OS X is a beast of an entirely different nature. Rather than being a black box, it is, with a few exceptions, largely transparent. Rather than being closed, it is decidedly open. Rather than hiding from the user, Mac OS X’s underpinnings are very near the surface, albeit under a glossy exterior. This remarkable transition fundamentally affects the act of troubleshooting. Rather than a script or a voodoo-style procedure complete with incantations, troubleshooting can now be called a way of thinking. With vastly more data available, the administrator draws vastly better conclusions about the nature of the issue at hand.
In the end, the question has to be asked: “Does troubleshooting matter?” Does the process of troubleshooting matter at all, as long as the outcome ensures that what was once broken is now fixed? I would say it does. Transparent, controlled troubleshooting leads to understanding. And better understanding contributes to architectures and systems that don’t need to be fixed. So although understanding for the sake of knowledge is a worthy goal, it’s not something we can advocate in a business setting. Understanding in order to foster better-built systems and lowered support costs, is.