A more personal illustration of instrumentation is the time card. During my consulting engagements, my clients require that I keep track of my time. After all, they want to ensure I am using their money wisely. So, I must take extra steps to ensure my time is recorded properly. At the end of each month, I give my monthly activity calendar to my administrator. She extracts the time I spend for each client and summarizes it in a way that is useful for billing purposes. For example, the summarization may show that I spent 15 hours working on the Zeppo project, 25 hours on the Dingbat project, and 4 hours on the Tucson project. The only way the billing information can be created is if I allowed my activity to be instrumented. These extra steps-the instrumentation of my day-are what allow my time to be summarized and useful for billing purposes. Without me taking the time to record my activities, there is no way for anyone to know where I spent my time-including myself! So instrumenting my workday is not only useful, but it also required.

Instrumentation may seem simple enough, but there is more to it than is usually apparent. In fact, instrumentation can even lead to an incorrect diagnosis! Let's see how this can happen.

Assume a software product has three modules: A, B, and C. The software was running slow; no one seemed to know why. So, the development manager decided it was time to instrument the code. As shown in Figure 2-1, the developers inserted simple timers into each module. When the module began, a starting time was gathered; upon exit, the finish time was gathered.