ed's profileThe Adventures of MrEdPhotosBlogLists Tools Help

Blog


    July 06

    Lessons from Glenn Miller

    I just finished reading an old book I found at our public library: “Glenn Miller and His Orchestra” by George T. Simon. It was an excellent read … although it did not have a happy ending (he died in a plane crash on his way to Paris). Glenn Miller was born into a poor family but at an early age he developed an insatiable desire to succeed. He became extremely competitive and simply had to be the best at everything he did—whether it was playing baseball, or learning to play the violin he never settled for second place.

    The interesting thing about his story, is that Glenn Miller was not a particularly talented musician, he was merely adequate. But he made up for his lack of ability with drive, determination, and refusal to settle for mediocrity. In the end, he invented what has become known as the “Glen Miller Sound” in which the melody of a song is repeated through the use of a special combination of woodwinds.

    Glenn Millers lasting contribution came through his orchestra, and his unique arrangements of songs.  Because of his drive and determination he was the consummate organizer. His rehearsals were prodigious, but the Glenn Miller Orchestra evolved into a well oiled machine that was able to enter a recording studio in the morning, and depart in the afternoon having completed 8 successful takes. Contrast this with the months of studio time it takes the average rock band  of today.

    July 02

    A wolfean approach to troubleshooting

    One of the things I have enjoyed about not traveling every week, is going to the library. In the past, when I would fly home on Saturday evening, and leave on Sunday morning, there was no time to do much of anything, and a trip to the library was out of the question. Now however, the scripting wife and I take weekly trips to the library. Our public library has a great collection of Rex Stout novels. Rex Stout is most noted for creating the detective Nero Wolfe. One of Nero Wolfe’s trademarks is that he never leaves his house. Instead he has an assistant named Archie Goodwin  who goes out and gathers the information. Nero has Archie relay all of his findings, mulls over the information and then has a big meeting with all the suspects (and often the police as well) where he solves the case. The amazing thing in all of the novels I have read to date (maybe 1/3 of his collection) is that in nearly every case, everyone connected with the case arrives at the wrong conclusion.

    I believe we can all learn from Nero Wolfe when it comes to troubleshooting. Often when I was in consulting, I would be called to a customer to solve a problem that they had worked on for weeks. The difference between my approach and theirs is they generally started with what they could see. I remember one problem where the customer was having problems printing from their Word document. She had wrestled with the problem for weeks, even to the point of uninstalling Word and reinstalling it. When she came to her desk, I was updating her video driver and she got upset and yelled, “What are you doing? The problem is with Word not my video driver.” To which I calmly replied, “the print subsystem uses the video subsystem in conjunction with the WYSWIG print functionality of Office Documents.” The network administrator had focused on the problem and had assumed the solution. “I can’t print from Word, obviously the problem is with Word.” I on the other hand, looked at the environment: what components are part of the print subsystem.

    This is the same thing that Nero Wolfe does. He looks at seemingly unrelated aspects of the case, and finds the relationship between them. He does not leap to the first seemingly obvious solution. In fact, he does not arrive at the solution until all inconsistencies  have been ironed out. Once that is done, the case solves itself. In troubleshooting, once all the dependencies of a subsystem have resolved, the component that sits upon top of the subsystems will generally begin to work. As computing solutions become more intertwined, and complex is is more important than ever to begin troubleshooting by examining the components of the system in a systematic manner.