Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 7 Issue 1, Winter, 2003
Copyright (C) 2003 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist and Rapid Learning: Secret Weapon of the Successful Technologist.

[ Troubleshooters.Com | Back Issues | Linux Productivity Magazine ]

If the only tool you have is a hammer, you tend to see every problem as a nail. --  Abraham Maslow


Editor's Desk

By Steve Litt
Our air conditioner broke, so we brought in a heating and air conditioning tech. Watching him work was a pleasure. He was knowlegeable both in technology and in Troubleshooting Process. And his use of tools was outstanding.

He had a single tool pouch with almost all the necessary tools and meters. As he worked, tools came out, and tools went back in. He didn't scatter tools around. Absolutely no time was lost looking for tools, nor cleaning up at one work area before moving to another.

Due to price concerns, we had another company actually do the work. They sent in a tech to evaluate the situation and I watched his tools handling. Once again, excellent. At all times he knew the location of every tool. He traced the problem down to a bad outside unit and ordered it.

A team of two techs came with the outside unit. Their tools were different, but their toolsmanship was once again meticulous.

I compared the tool handling of these experts with mine. At Pacific Stereo, my bosses regularly criticized my housekeeping and organization of my tools. Realistically, I'd say my tool handling cost me 10 to 15 minutes per repair. Looking back I realize the only thing that kept me afloat was the fact that I could diagnose at double or triple speed compared to the other techs. I used the Universal Troubleshooting Process as a crutch.

Is it any surprise that I later went into software development? All my tools were neatly organized on my hard disk. It's much easier to keep everything neat on a hard disk than on a service bench (and certainly than in a dark and dusty attic). But even in the software field, my tool handling was less than exceptional. I almost never used a debugger, instead substituting diagnostic printf's with recompiles. I never really mastered all the power of any editor (until I mastered Vim). Even my use of computer languages revealed a lack of toolsmanship. Although I've programmed professionally in over 10 languages, in every language I used a subset of its capabilities. And yet with all of this, I was usually the most productive programmer on the project.

Sure, my contemporaries worked wonders with debuggers, editors, and language features. But with my Universal Troubleshooting Process and the software design processes I learned at Santa Monica College, I still finished first. So why complicate my life learning debuggers, editors, and language specific algorithms?

That question was answered when I saw the toolsmanship of the air conditioning technicians.

This Troubleshooting Professional issue is devoted to toolsmanship. Its benefits and limitations, and how to achieve it.

So kick back, relax, and enjoy this issue of Troubleshooting Professional Magazine. Now more than ever, if you're a Troubleshooter, this is your magazine.

Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Toolsmanship and Bottleneck Analysis

By Steve Litt
Isn't it interesting that I outperform other technologists with far better tools skills. What's the explanation?

The explanation involves bottleneck analysis. A person troubleshoots as slowly as his worst skill. I'm slowed by my toolsmanship. But my tool use skills are a model of efficiency compared to the average person's use of diagnostic methods.

Even today, about 50% of technologists troubleshoot by trial and error. It's true that I can lose 10 minutes looking for a tool, but a trial and error Troubleshooter can lose an hour or even a week using diagnosis by serial replacement.

What about the other 50%? I'd estimate 40% of them troubleshoot methodically on a sporadic basis, but it's hit and miss. They lose more time than they could make up with even the best toolsmanship.

That leaves the 10% who rigorously use a valid Troubleshooting Process. They're my competition. Assuming they know the technology, the 10 minutes I lose looking for a tool can cause me to fall behind.

The rules of bottleneck analysis apply to Troubleshooting productivity. You troubleshoot as slowly as your least developed skill. The trial and error troubleshooter cannot possibly catch up using excellent toolsmanship and product and techology knowledge. Giving such a person more technology training or better tools is like giving a 400 pound rider a lighter bicycle. The weight of the bicycle is a tiny fraction of the overall problem.

How different things become when the Troubleshooter uses valid process and has adequate tech knowlege. For such a Troubleshooter, diagnosis becomes so quick that activities such as disassembly and reassembly, physically placing diagnostic tests, and the like become a major chokepoint. For this ninja Troubleshooter, gaining an extra minute with improved Troubleshooting Process cannot begin to overcome a 10 minute search for the right tool.

Does this mean a Troubleshooter should put off acquiring tool use and handling skills until he's achieved superior diagnostic performance? Not at all. The toolsmanship habit isn't learned overnight, and once the technologist has achieved superior diagnostic throughput, she doesn't want to get stopped yet again by inferior tool use.

So the bottom line is this: superior tools and toolsmanship won't begin to rescue a Troubleshooter deficient in Troubleshooting Process. But once Troubleshooting Process and tech knowledge have been removed as bottlenecks, the new bottleneck is tools usage. At that point, productivity increases proportionally to increases in tool usage skills.
Steve Litt is the creator of the Universal Troubleshooting Process.  Steve can be reached at Steve Litt's email address.

Improving Your Toolsmanship

By Steve Litt
Here's where the rubber meets the road. How can YOU benefit from this magazine?

So far you've read several feelgood tools articles, and you've read that in fact my toolsmanship isn't top notch. So how can I teach you? I could always say "do as I say, not as I do". But we all know that's lame. Much better advice is to do as the tool experts in in this magazine's articles -- the air conditioning techs, The Artist, Mr. BabyProofer, the Pacific Stereo technician, and old fat John. And if you read the Bringing Consistency to Variation article, you'll find that even though I sometimes spend 10 minutes searching for a socket or C clamp, in my own way I'm an excellent toolsman.

So I'll interpret the acts of the air conditioning techs, The Artist, Mr. BabyProofer, the Pacific Stereo technician, and old fat John. And as you read, think of ways you can use this information to improve your own work.

The Artist is a complete role model for toolsmanship. As you remember, he produced four high quality paintings per hour using the following three activities:
  1. Formulate your goal
  2. Organize and care for your tools
  3. Perform riffs with your tools
Let's discuss 2 and 3 first, leaving 1 for later...

Organize and care for your tools

Ask any tradesman and he'll tell you your tools are your livelihood. Tools are expensive. Even cheap tools are expensive, because you keep replacing them when they break. If you use tools on a regular basis they must be cared for, they must not be lost, and they must be accessible.

Preserving your tools is a matter of habit. If you're in the habit of putting your voltmeter in a specific slot on your toolbelt, you'll never leave it at a jobsite. If you're in the habit of cleaning your paintbrush as soon as painting is complete, it will never become hard with paint. If you're in the habit of coiling power cords before putting away your equipment, you reduce the risk of having them drop and break.

It's a good policy not to loan professional tools. I don't mean you shouldn't loan the neighbor a rake, but if you're a mechanic you shouldn't loan him your spark plug wrench. Most people don't take good care of other people's equipment. And even if they do, loaning the equipment increases the risk that it will become lost.


Watch all master toolsmen and you'll see a common trait -- instant access. The right tool seems to magically appear in the toolsman's hand. No digging around, no searching, no dropping work materials to reach for the tool. If diagnosing and repairing a car requires 50 tool tasks (I think that's a reasonable number for a simple to moderate repair), imagine the difference between a technician requiring a minute per tool access and a technician requiring a second per tool access. I count it as 49 minutes difference. The marketplace will bury the technician requiring an extra 49 minutes per repair.

Of course, nobody gets every tool in 1 second, and nobody requires 1 minute for every retrieval. But the great toolsman completes many tool accesses in less than a second, without taking his eyes off the work. And the poor toolsman might make several accesses in a second or less, and then blow it by spending 10 minutes hunting down a misplaced tool, or worse, spend an hour at the store buying a new tool.

Two factors determine the quality of tool organization:
  1. Knowing where everything belongs (and putting it there)
  2. Prioritizing
Two air conditioning technicians replaced our outdoor unit. The master technician brought a torch, lots of plumbing, and 2 or 3 toolbags. He was so familiar with the placement of his tools that he was able to tell his assistant to "get the meter out of the side pouch of the toolbag by the bush". Ellapsed time -- 2 seconds. Imagine how different it would have been if the assistant had to search all the bags, and maybe search the bushes too.

Efficient toolsmen know the location of their tools at all times. Each tool has an assigned place, and the tool is always returned to that place. And when circumstances prevent returning it to the assigned place, they make a point of remembering where it is.

Knowledge of location is enough when you have only 5 tools. With 5 tools, a simple toolbelt is all you need. But most workers use 50 tools. Or 100. Or more. The reason is simple enough. You could probably complete all necessary tasks with 5 or 10 tools, but it would be painstakingly slow. Imagine accessing the sparkplugs on the firewall side of a transverse engine without a flexjoint wrench, the proper extension, a good light, and maybe a mirror with a clip. Yes, you can do it, but it could take an hour. If a job takes an inordinate amount of time, there's usually a tool that can cut the time by a factor of 10 or maybe even 100.

So those of us with anything but the simplest jobs must work with many tools. Too many to efficiently access from a toolbelt. Prioritization is required...


Your objective is to reduce average tool access time to less than a second, and do it without taking your eyes and one hand off your work. If your toolbelt holds 100 tools, that's not going to happen. You'll feel around for several seconds, likely dropping some tools, before accessing the right tool.

So with 100 tools you'll not be able to make every tool access under a second. But using the 80%/20% rule, by putting your 20 most used tools in your toolbelt, with the other 80 tools neatly organized in a nearby toolbox, 80% of your accesses will be under a second. This simple 2 level prioritization boosts productivity. But you can do better.

In real life you'll prioritize your tools into more levels. Your top couple tools will be in your pocket, or in a special pocket of your toolbelt, for incredibly quick access. Other tools will be in less accessible parts of your toolbelt.

If you have lots of tools, you'll probably have multiple toolboxes for the 80% of your tools not in your toolbelt. Perhaps the toolbox for the more common tools will be arranged for quick access -- maybe as quick as a second if the toolbox is next to you as you work. Toolboxes with lesser used tools are arranged for findability, even if such findability delays access. Or perhaps the least used toolbox will simply contain a scramble of tools. If you access its tools only 2 or 3 times per day, that's not a productivity problem.

If you're a travelling service person, many of the least used tools remain on the truck, where you can find them if you need them, but it could be 5-15 minutes access.

The bottom line is that with a little planning, you can drop your average tool access to a second, no matter how many tools you have.

Thinking Ahead

Tool prioritization takes on a whole new tint when you work on a ladder or in a small attic. Handling a 60 pound toolbox on a ladder is usually undesirable. Likewise, you don't want a bulky toolbelt in a tight crawlspace.

In such cases, the hot tip is to think ahead at all the tasks you'll perform in the "hostile environment", and pack the tools you'll need for those tasks. Then put them in your pocket or a small toolbelt, and go to work.

Most tree surgeons work in pairs or threesomes. If the guy in the tree needs a tool, the others put it on a rope and the guy on the tree hauls it up. But we hired a tree surgeon who worked alone, and it was educational. He spent 40 minutes on the ground preparing all his tools. He checked the cleats on the side of his boots. He checked his two waist belts. He checked his saw, and made sure it was full of fuel. The dead tree was 110 feet high. How would you like to run out of gas up there.

With all the tools present and checked, he headed on up. At major branches he'd detach one of his waist belts and put it around him over the branch, then detach the one under the branch and keep going.

When tree surgeons cut down a pine tree, they cut down the dense part at the top as a unit. In a team effort, the guys at the bottom pull it to the side with a long rope, so that when the tree guy saws it off, it falls harmlessly to the side. What would our lone wolf do?

He tied several loops of rope to one branch, and then to a branch below it. I mean many, many ropes. Then he sawed the trunk between those two branches, and the top of the tree fell away, and then got hung by the rope. The tree shook like a 9.2 earthquake, but the tree surgeon hung on, thanks to his 2 waist belts and his boot cletes. He untied the rope and the entire top of the tree crashed to the ground.

The rest of the job was just a matter of sawing off 3 foot sections of the trunk and dropping them down, or sawing off the branches he'd used as perches on the way up.

I was in awe of the planning that went into this job. I think he knew every step of the job before he took his first step up the tree. I don't think a single decision was made while in the tree. This planning enabled him to bring exactly what was necessary, without hauling extraneous junk up 110 feet of pine tree. This type of planning makes all the difference when working in less than ideal circumstances.

Perform Riffs With Your Tools

Single second access does no good unless your tasks are performed quickly. That's where riffs come in. If a job is divided into 50 tasks, it's a good bet that 45 of those tasks are things you've done many times before. These should be done quickly, from habit. They're riffs.

Using a ratchet wrench is a simple example. You start by seating the socket extremely well, bracing the center with your left hand, and really cranking down with your right hand, all the while taking care that if the bolt loosens suddenly, you don't bang your hand on something. Once the bolt is loosened, you either twirl the wrench or ratchet it, depending on how much room you have. If you ratchet it, you might provide some resistance with your left hand so the backratchet action doesn't retighten the nut. At some point of looseness you'll put down the wrench and loosen it by hand, because that's quicker. But before it comes completely off, you'll make sure to prevent the bolt from falling to the ground or into the car.

Riffs must be quick, automatic and brainless -- based on months or years of practice. They're habits. Make a strong effort to preform the same tasks the same ways every time.

On the flip side, always be on the lookout for ways to improve existing riffs, and invent new riffs to fill a vacuum or replace other riffs. By far the easiest way to improve riffs or acquire new ones is to watch others work. When you see someone cut 30 seconds off your time on a task, see what he's doing, evaluate it, and incorporate it into your work. Often the better riff will involve a different tool. If so, use that tool. If you don't have it, buy it. Remember the story of the drills at Pacific Stereo?

How do you walk the tightrope between maintaining habitual riffs and improving them? Simple. Evaluate which riffs could use improvement. A 1 second task needs no improvement unless you do it hundreds of times in the course of a repair. On the other hand, a 5 minute task in an hour repair is definitely a candidate for improvement, so be on the lookout. If you ever find yourself angry and cursing at a particular task, that's a sure sign you need  a better riff, possibly involving a different tool.

Long ago I had a 1982 Buick Lasabre with the fuel filter built right into the carburetor. Every time a mechanic changed that fuel filter it was a 40 minute operation. Succeeding mechanics increasingly stripped the threads of the fuel filter housing, until finally I had to have the carburetor removed and re-tapped. Finally I took the car to Gary's Unocal in Reseda, and Gary showed me the right way. He had a special wrench he put on one hex, and he put a normal open end wrench on the other, loosened, pulled one end back, replaced the filter, carefully re-threaded by hand, and tightened. Ellapsed time -- 5 minutes with no thread stripping. Riffs make all the differences.

Riffs Drive the Tools

Because riffs use tools, one might surmise that tools drive the riffs. But it's the reverse. Riffs drive tool usage.

Take the case of Pacific Stereo. With over 10 screws per stereo, we all got very good at manipulating hand screwdrivers. But "skinning" and reassembling the case continued to require about 5 minutes -- there was only so fast we could twirl a screwdriver. One tech recognized the inadequacy of his screw removing riffs, and devised a better riff based on an electric drill.

At the factory, "old fat John" realized that the gloved hand riff took too long, and went on the lookout for a new riff. His alerted mind soon focused on using a board as a tool to support an improved riff. Mr. BabyProofer didn't carry his two drills as a status symbol. They were tools to support his lightning quick riffs.

Access Speed vs. Riff Speed

As a bicycle mechanic (between my factory career and my stint at Pacific Stereo), I used an adjustable wrench for all nuts and bolts. Adjustable wrenches can be incredibly slow -- especially in tight quarters such as the angle adjustment nuts on old-fashioned seats. I tried using a ratchet and sockets, but gave it up. The time I saved loosening and tightening was more than consumed by the time required to locate and replace sockets on the wrench. "Universal" tools convey a heavy benefit in access time, even if they're not riff-efficient.

Hindsight is 20/20, but if I had my bicycle mechanic days over again, I'd have followed Mr. BabyProofer's lead and bought multiple ratchet wrenches, each with a different hex head. And I've had used a tool pouch. I'd have picked the top 4 most used hex heads, and I'd have color coded them. That way I could have gotten 1 second access and yet benefitted from ultra-quick tightening and loosening.

Recently, as a recreational bike rider, I've encountered a problem. For years I've carried all tools in a tied up bluejean leg. That works well for rare, intense tasks like changing flats. But lately I've had increased need for on-ride brake and derailleur adjustments. Crowded with tools, the fastest access method is to untie the bluejean leg and spill all the tools on the ground. There are about 30 tools.

Spilling and replacing the tools takes 5 minutes. That's not much of a penalty in a tire change, but it changes an adjustment from a 1 minute to a 6 minute job. So I purchased a handy-dandy 17 in 1 Crank Brothers tool assembly with all size allen wrenches, and a philips and flat screwdriver. I'll add a spoke wrench, and then put them in a tiny seat pouch for quick access on a ride. For more challenging jobs, my bluejean leg will be available.

Choosing Tools and Riffs

Watch an expert at work. See what he does with mirrors. See what he does with coathangers. With lights and magnifying glasses. With flex-shaft wrenches. With power tools.

Watch the expert with his meters. See the various clamps and probes. See him use an icepick to make contact with painted or oxidized surfaces. Notice the induction ammeter he uses to remove the necessity of disconnecting wires.

Special use tools abound for the person with riffs to use them. Reverse drillbits can remove sheared off bolts. Taps can rethread messed up threaded holes. Various lifting devices can hoist heavy objects. Magnets can be used to retrieve otherwise irretrievable steel objects. Magnetized screwdrivers can be used to thread screws where you'd otherwise need a half hour disassembly and reassembly. POST (Power On Self Test) cards are available for computers to determine the problem in a no-boot, no-video computer.

Sometimes cheap tools replace expensive tools. Upon moving from Pacific Stereo to George Meyer TV I discovered George Meyer had no Variacs for current limiting, and didn't want to spend the money to purchase one. No problem -- I rigged up a series lightbulb. I also replaced a hard to use distortion analyzer with my ears to determine if a sine wave was distorting.

Riffs are quick habits, and should be done the same way every time, UNLESS the current riff is difficult, dangerous, frustrating, expensive or time consuming. If the current riff isn't efficient, look for a new riff. Watch others at work. Ask acquaintences and ask on the Internet. Look through tool catalogs. If you have trouble with the task, you're not alone, and probably somebody sells a tool to make quick of the task.

Formulate Your Goal

Back to The Artist's methods, remember he started by formulating a goal. On first impression, formulating the goal has nothing to do with toolsmanship. But closer scrutiny paints a different picture. Your goal determines what tasks you'll perform, which in turn determines what tools you'll need. And unless you've been given a blank check and infinite training time (as well as an infinite brain), your tools and riffs determine the goals you can take on.

It's no accident that The Artist didn't paint football players or skyscrapers. He had no football player or skyscraper stencils. He had no riffs for football  players and skyscrapers.

Correct goal formulation is your response to finite tools and riffs. The narrower the range of goals you persue, the tighter you can make your riffs, and the more you can slaughter the competition. It's marketing 101 -- pick your core competancy and specialize.

It's not quite that simple, as any blacksmith or Cobol programmer can tell you. When the marketplace walks away from your core competancy, your range of goals must change. If you're paying attention, such changes can be slow and incrimental. Estimate future markets, decide on your goal range, and obtain a few additional tools and riffs to accommodate that goal range. Leverage your existing tools and riffs to the extent possible. Rapid Learning techniques are your friend.

But what if, by its very nature, each job you take on is different? With such a wide goal range, how can you acquire tools and riffs? Welcome to my world...
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist . He can be reached at Steve Litt's email address .

Bringing Consistency to Variation

By Steve Litt
On an average day I'll program in 2 different languages. I've had many 4 language days. In an average week I'll troubleshoot computers, networks, and maybe 5 different software applications. I regularly design magazine articles, books, and course material. I perform sales activities.

On the surface this would appear to require such a broad set of tools and riffs that depth would be impossible, and if depth is impossible, I would lose in the marketplace. But this is just a surface appearance.

The trick is to find common denominators in all this work, and master tools and riffs consistent with those common denominators. Faced with the necessity of fixing mechanical, electronic, networking and software devices, I devised the Universal Troubleshooting Process, a system independent tool for troubleshooting. So no matter what I'm fixing, here's my list of major riffs:
  1. Prepare
  2. Make a damage control plan
  3. Get the symptom description
  4. Reproduce the symptom
  5. General Maintenance
  6. Narrow the root cause scope
  7. Repair or replace the defective component
  8. Test
  9. Take Pride
  10. Prevent future occurrence
Works on anything. What happens if a problem stumps me or causes me to panic or become angry? No problem, I've seen that situation before, and I know the riff. The riff uses a tool called "The Troubleshooter's Mantra", and consists of simply asking myself "how can I narrow this down just one more time?". Computers, networks, software, source code, electronics -- it doesn't matter -- if I'm fixing it, these are my tools and riffs.

I write software, magazine articles, and books. What's the common thread? Design. All of these things must be designed in order to come out right. I have two design methodologies -- functional decomposition for structured program design, and entity relationship diagrams for OOP programming. And lucky me -- functional decomposition can be used to design books and projects. Luckier still, I have a software tool, an outline processor called VimOutliner, that's perfect for functional decomposition.

On the surface it looks like my activities are disparate. But on closer scrutiny I do two things over and over again -- design and troubleshooting. And I've obtained tools and mastered riffs for these two activities.

You might observe that there's more to writing programs or books than design and troubleshooting methodologies. There are computer languages to master, including every language's little tricks and shortcuts. There are debuggers to master -- often one debugger for each computer language. There are editors to master, and often editors are integrated with the development environment. Your observations are correct!

So now you know why I'm regularly accused of writing Perl, PHP, Python and C++ with a C accent. C is my native language, so I regularly use C algorithms, often increasing the line count of my programs. If you've seen me debug, you know I seldom use debuggers. With so many language dependent debuggers, diagnostic printf's are easier for me.

Remember the discussion of Access Speed vs. Riff Speed in the Improving Your Toolsmanship article? When accessing (meaning learning) specific debuggers is too time consuming, I use the one size fits all tool, diagnostic printf's. When accessing specific optimal language syntax is too time consuming, I use one size fits all algorithms. What I lose in riff speed I gain in access time. And remember, I have the huge advantage of consistent design and troubleshooting tools and riffs, putting me way ahead of the crowd. So if you read my plain-vanilla code, rest assured there's method to my madness.

Besides my methodologies, I also have advantages in content creation software. I can make the Vim editor walk and talk. My VimOutliner software is the world's fastest outline processor, and I know it intimately. When it comes to the Mozilla Composer WYSIWYG html creation tool, there are few faster than me. And I've recently become adept enough at LyX to write a 117,000 word book in LyX (Troubleshooting Techniques of the Successful Technologist).


If you're lucky enough to perform the same type of work every day, take advantage of that fact to go deep with your tools and riffs. But if your work varies so much that the quantity of tools and riffs exceeds your ability to go deep with them all, find the commonalities in your various jobs and then form riffs to handle those commonalities, and tools to support those riffs.
Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Intangible Tools

By Steve Litt
Most of this Troubleshooting Professional issue has focused on tangible tools -- wrenches, screwdrivers, meters and the like. And we also covered the intangible tools called The Universal Troubleshooting Process, functional decomposition and entity relationship diagrams. There are many, many more intangible tools in the software world.

Text editors, outline processors, word processors, html authoring tools, xml authoring tools, debugging tools, web browsers, menuing programs, communications programs such as email, newsgroups and instant messaging, financial software, in-house productivity and ERP programs, and much, much more.

In once sense access to software is instant. Unlike a toolbox, a hard disk can hold thousands of software tools neatly sorted. You'll need a menu system configured to quickly run the software tools. Often used software is usually closer to the root level of the menu. The menu itself must be fast. I use UMENU, an Open Source keyboard-only menuing system (links for download in URL's section).

Another aspect of access is the time it takes to learn a tool. With most hand tools that time is negligible, but with software it can hours or even weeks. This learning period often causes people to use "one size fits all" type software tools, an equivalent of the adjustable wrench. At one time I used Microsoft Word to write letters, books, and outlines. Now I use the Vim editor as the engine of my outliner (VimOutliner), as a source code editor, as a phonebook, and to write simple documents.

Riffs with software tools are almost infinite. Your fingers learn the necessary keystrokes, or the required mouse strokes. There are often several different software tools to accomplish the same things. When riffs start taking more than a few seconds, or when they start being hard to remember, different programs can be combined with a script to accomplish a task that each piece alone couldn't have. This is particularly true in command line rich operating systems like UNIX, Linux and BSD. But thanks to the marvels of scripting languages like Perl and Python, you can create substantial scripts in primary GUI operating systems like Windows using the Python or Perl languages freely distributed by ActiveState (URL in URL's section). If you're a Macintosh user, and if you have OS/X, you're in luck because OS/X is BSD Unix under the hood, so you can install Python or Perl for UNIX on it.

As a touch typist, my personal observation is that keyboard-based riffs are much more productive than mouse based riffs except in drawing programs. Many pieces of software make efficient use of the keyboard. So if you're a touch typist, seek out those keyboard friendly programs. Once again, if you'd like a keyboard driven menu program, the UMENU program with the EMDL menu authoring system is an excellent choice. Both URL's are in the URL's section of this magazine.

Between your menu program, the software you use, and the scripting you do, you can achieve incredible productivity with your software, often increasing productivity by more than a factor of 10.
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached at Steve Litt's email address.

The State of Troubleshooting Address

By Steve Litt
With respect to Troubleshooting, 2002 was more evolutionary than revolutionary. Troubleshooting Process continued making inroads into corporations, in large part assisted by Troubleshooters.Com. Nevertheless, there's plenty of room for improvement in employee rank and file.

We Troubleshooters are still losing the battle with complexity. Although complexity has increased in the auto industry, at least quality and diagnostic tools have kept pace. Casual shadetree mechanics have pretty much been rendered obsolete, but the state of auto repair and reliability is probably as healthy as ever.

The Windows operating system was the greatest source of complexity in previous years, but I've heard that Windows XP is at least more reliable than its 9.x and ME ancestors. The bad news is that Microsoft appears to be increasing complexity along with the reputed reliability increase. After being granted a legal monopoly by the Justice Dept, they appear to be packaging more and more into their operating system and their other applications. This includes plans in future Windows versions to include "Digital Rights Management" (DRM), a copy protection scheme whose advertised purpose is to reduce "piracy" and other theft of intellectual property. However, DRM can also be used to reduce interoperability, needlessly complicating system integration, and even such mundane tasks as backup and system synchronization. If you're in a position to choose software products, please keep this in mind.

Automation Assisted Troubleshooting Process (AATP), which I formerly called "Era 4 Troubleshooting", has been too expensive to implement universally. AATP has made inroads in the military and the automotive industry. But until AATP authoring becomes more affordable, universal adoption will not happen. That's too bad, because the AATP tool has the potential to create incredibly quick and effective riffs.

Troubleshooting Professional Magazine certainly changed this year. After years of supporting the dual audience of Troubleshooting Process experts and Open Source advocates, TPM spun off a new monthly magazine, Linux Productivity Magazine, while Troubleshooting Professional became a quarterly magazine publishing all troubleshooting all the time. In my personal opinion, both magazines became much better now that each is free to focus on its core audience.

The 2002 economy was horrible for technologists of all stripes, and there was no magic bullet to avoid the unemployment line. Certainly security expertise is helpful. Troubleshooting productivity is also helpful. Before they turn out the lights and shut the doors for the last time, even the most financially distressed companies need people who can quickly and correctly solve technical problems. That's our silver lining.

I don't expect the economy to improve in 2003. Believing that the populace thinks only of foreign affairs, the powers that be don't see the economy and incredibly bleak employment picture as a problem. The voters will let them know they're wrong in 2004, at which time the economy will improve, but we still need to survive 2003. As a Troubleshooter, you want to hone your Troubleshooting skills, and also transition your technical skills to those of most value in the current marketplace. With the current economy, company paid training is rare, so you'll need to use Rapid Learning techniques.

Recessions and depressions are times of repair rather than new purchases. Try to position yourself as the person who makes new purchases unnecessary. And please try to remember the long term -- neither boom times nor recessions last forever. Hang in there.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist . He can be reached at Steve Litt's email address .

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Troubleshooting Professional Magazine must be licensed with the Open Publication License, which you can view at At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Troubleshooting Professional Magazine, you must decline the option to prohibit commercial use, because Troubleshooting Professional Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2001 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at (wordwrapped for readability at The latest version is presently available at

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version.


All trademarks are the property of their respective owners. Troubleshooters.Com (R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue