If you've ever had to develop speedy code, there is a good chance you are familiar with instrumentation. Instrumenting source code requires that additional code be inserted directly into source code, enabling measuring of specific activities. When the code is run, the analyst can then determine where time has been spent and focus on slow areas of the code.

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.