Troubleshooting Professional

Volume 2, Issue 1, January 1998
Copyright (C) 1998 by Steve Litt

Contents

Editors Desk
Can you hear it in the wind?
If you're not part of the solution
Come the Revolution
The State of Troubleshooting Address
Auld Lang Syne
Letters to the Editor
How to Submit an Article
URLs Mentioned in this Issue

Editors Desk

By Steve Litt

Troubleshooting Professional Magazine turns one year old this month. The Troubleshooting revolution predicted in the premier issue (January 1997) has yet to occur. What we're seeing instead is a slow, steady evolution. More management interest in generic Troubleshooting. Fewer of the dreaded "blank stare" when answering the question "troubleshooting what?". Significant numbers within the management community are saying "we want you to teach our people troubleshooting, not machines".

The substitution of slow evolution for revolution is a good thing, because it minimizes the chance of backlash (also predicted in the Jan 1997 issue). This evolution is guaranteed by the growing complexity and shrinking time-to-market of products and technology. Industry's bottleneck is increasingly tech support now, and that bottleneck will enjoy more and more resources in the coming years.

So kick back, put your feet up, and contemplate where we've been and where we're going, And remember, if you're a Troubleshooter, this is your magazine. Enjoy!

Steve Litt can be reached at Steve Litt's email address.

Can you hear it in the wind?

By Steve Litt

It's all around us. Have you sensed it? Change is upon us, and Troubleshooting is not the same.

There was a time (January, 1997) when the voices were few. Voices speaking seemingly into an empty, unlistening world. Speaking of Troubleshooting as a Process, not as a property of the machine, nor as something you "just do". They were Troubleshooting's patriots, devoted to the vision -- a vision they've kept through years of rejection. Their time was coming -- they just knew it.

But their time hasn't come. It's been a year, and no revolution. Hit and miss troubleshooting still rules the land. Patriots still curse that most obnoxious phrase, "troubleshooting what?". And the blank stare you get when you answer "anything". They still preach their six step processes and eight step processes and ten step processes so similar it's spooky. And they still compromise for food, clothing and shelter. The revolution didn't come. But the funny thing is, people are starting to listen.

They listen, they hear, and they understand. Not many, but enough. And more every day. People with the money and power to force the change. People whose business depends on good customer service in an era of complex and feature-bloated products. People who see quite clearly the ultimate result of hit-and-miss troubleshooting. People whose jobs and careers depend on forcing the change. Troubleshooting training is being funded in budgets. It's being talked about at the highest levels.

Can you see it just beyond the next hill? Probably not -- the mountain's higher than we thought. But if you look back you'll see how far we've come. We'll get there -- just not as soon as we thought. We're still leading the charge. But now there are many more of us.

Steve Litt is president of American Troublebusters and Troubleshooters.Com, and editor of Troubleshooting Professional Magazine. He's also an application developer and technical writer. He can be reached at Steve Litt's email address.

If you're not part of the solution

By Steve Litt

Every movement has its opposition. Ours are called hit-and-miss troubleshooters. They troubleshoot intuitively, as their parents and college instructors taught them. They have the common sense to know that troubleshooting success is proportional to knowledge of the machine or system. They know Troubleshooting Process is just another program of the month -- one they don't need. They are secure in the fact that they can troubleshoot -- they do it every day. They laugh and curse at the Troubleshooting Revolution. And they're losing their jobs!

Of course, they're not losing their jobs because they don't use Troubleshooting Process. Oh, no! Layoffs, downsizings, consolidations, buyouts, mergers, corporate politics, re-engineering. And the big factor -- today's complex and quirky systems are almost impossible to solve, especially with the rate of technological change and obsolescence. These are the reasons. Aren't they? Of course they are! Aren't they?

But late at night, when sleep won't come, things aren't so clear. Of course it was office politics. Of course it was. There's no monster in the closet. Then, just for a second, a big red thing with three silver eyeballs and huge yellow fangs appears in the closet door. Didn't Stan down the hall survive the layoff? Didn't Stan use that silly Troubleshooting Process. And didn't he seem to solve problems quicker and more accurately, especially on the new, complicated technology? And with less customer upset? Then the common-sense adult wills the monster to disappear. Stan's not better. Oh no! It was office politics. Stan followed the program of the month. It's not about ability. Is it? IS IT???

Today, the person who is not part of the solution is part of the problem. Tomorrow he'll be part of the unemployment line. And that's how the world's quietest revolution will be won.

Steve Litt can be reached at Steve Litt's email address.

Come the Revolution

"We won't get fooled again". In their song of that name, The Who describe the futility of revolution. Futile because once the fighting is over, self-serving hacks replace the zealots and the new regime becomes as bad as the old. The plot of films and Twilight Zone adventures, it's true enough to have become part of our collective consciousness.

Do we need a revolution? Is knowledge of the machine or system so unnecessary? Is intuition so bad? Do we need to spend every second analyzing our process? Is this thing called Troubleshooting Process really a change? Haven't we been doing it all along? Was the old troubleshooting so bad?

No, it wasn't bad at all. It worked great with steam engines, rifles, and early cars. In its time it was revolutionary -- a vast improvement over its predecessor, straight observation, which was used to fix covered wagons and hand-operated printing presses. Intuitive, machine based troubleshooting worked OK with discreet component (tubes, transistors, and FETs) electronics, and with cars until 1980. With no well known alternative, it continued to be used, albeit ineffectively, on computerized equipment. But with today's machines a hundred times more complex than twenty years ago, the revolution is at hand.

We WILL get fooled again. And again and again. It's the way we progress. Each revolution builds on the last. Intuitive troubleshooting retained observation as a core component, adding tests to narrow the problem's scope. Troubleshooting Process retains the observation and tests, adding a formal process to preclude going in circles. Troubleshooting Process is capable of fixing the most complex of systems. Just one question remains:

Is it the revolution that fools us? Or is it the complacency that follows?

Steve Litt can be reached at Steve Litt's email address.

The State of Troubleshooting Address

It's January 1998, and "intuitive" Troubleshooting still rules supreme. But like the fabled Dutch boy, the old-guard have their fingers in the dike, praying to resist the heightening flood of technical complexity. And of course, the dike can't long hold.

The difference between troubleshooting Seventies machines and today's machines/systems resembles the difference between searching for a lost child in your back yard, versus searching for him in the Angeles National Forest. In the former case, it's necessary only to look around for a while and find. In the latter, you darned well better have a record of where you searched and what you saw, to prevent going in circles. A process is mandatory.

The progress we made in 1997 is that everyone realizes old-style Troubleshooting no longer works. Every trade publication screams of inadequate customer service. Every individual has a story to tell. The fact that something has to change is now old news.

The challenge is defining what to replace it with. Many are looking for the quick-fix, the easy way out, the magic bullet. They fall prey to the "expert systems" claiming to replace techs with phone clerks, or "diagnostic tools" which magically and accurately tell the tech what part to replace, or "programs of the month" extolling teamwork, diversity, and conflict resolution. Of course, all of this is necessary, but they're tools, not solutions.

Then there are the fast buck artists who figure they'll profit off the Troubleshooting Crisis with "platinum support" -- yearly contracts or 900 numbers or per-issue charges giving you no-hold support from intelligent Troubleshooters. This way, the worse their product, the more they profit. And the worse their rank and file help personnel, the more they profit. Take names of these companies, and vote with your pocketbooks when the revolution succeeds.

Last, but most, are those realizing the core component of any Troubleshooting replacement is *PROCESS*. Their advantage is that their solution works. In a free economy, eventually the solution that works drives out the snake oil and steer manure. Look to Troubleshooting Process for significant, continuing gains in the coming years.

Watch Your Back

Just as we seem to be scoring a solid victory with Troubleshooting Process, a new challenge looms. In many industries, especially computer software, feature-bloated mediocrity is becoming the norm. This mediocrity is accomplished through abandonment of modularity.

Witness the modern computer with any Windows operating system. All your separate applications depend on shared DLL's, and therefore depend on each other. Often as not, a symptom perceived in one application has its root cause in the installation of another, or in the operating system. The computer becomes a huge, monolithic mass of wired together components, reminiscent of an old tube radio with 500,000 tubes instead of 5. How can you troubleshoot something like that? How can you perform a narrowing-down process?

How can you build something like that, especially in this era of decreasing time-to-market? As we all know, scalability depends on modularity. When a large project is assembled out of many smaller, *independent* components, the project difficulty is proportional to the number and size of the independent components. But when the component are not modular -- when they must know about each other, the project difficulty is proportional to the *relationships between components*. With today's philosophy of complete component entanglement, the project difficulty grows *exponentially* with the size and number of components.

Then there's the little problem of the development tools being used for software today. Have you taken a close look at MFC (Microsoft Foundation Classes)? Instead of following Java's lead of distinct classes for forms, fields, etc, they have the Three Musketeers: a View object, a Frame object, and a Document object, all needing intimate knowledge of each other. Then there are the ubiquitous Pen objects and Device-Contexts. And that bizarre creature, the Document Template (which isn't a C++ template at all). Every object knows every other object's business -- no encapsulation here. How bout that cute bunch of "Better Not Edit" macros (Stroustrup says macros are inadvisable in C++) with which Microsoft replaces the Windows Message Loop?

Of course, MFC apologists would say their implementation allows complete access to the underlying operating system. MY POINT EXACTLY! As an application programmer, my job is to automate the problem domain, not dink around in the bowels of the operating system. The user interface should be a no-brainer, not an all-consuming task.

All this entanglement and complexity harkens back to the COBOL days when every variable was fair game for every procedure, and the goto was a badge of honor. The results, in terms of numbers of programmers, quality of product, and difficulty of support, are similar. So how do they keep pouring out new versions without going broke? To satisfy the worker-hours needed for entangled systems, they steal worker-hours from Quality Control, customer support, and documentation. The results are quite evident.

Nor is this a problem only for the computer users among us. In his Embedded Muse Newsletter, #10, Jack Ganssle mentions the possibility of embedded systems running Windows CE. No thanks! I'd rather my car's braking system not be programmed in Redmond. A GPF on my computer is an irritation -- a GPF while avoiding a child chasing a ball into the street is something else entirely. And how are tomorrow's mechanics going to deal with a car like this?

So, In Summary...

So here's my New Years prediction. In the short run, systems will continue their trend toward complexity and entanglement, creating a sellers market for trained Troubleshooting Process people. In the long run, the free enterprise system will win out, and no amount of marketing or monopolization will prevent an upstart company, marketing superior modular tools and products, from displacing the monolithic entanglement crowd. The result will be breakthroughs in the size and feature set of quality products, once again resulting in a huge market for Process trained Troubleshooters. Add to that the coming Y2K issue, and the future for good Troubleshooters is bright as can be.

Steve Litt can be reached at Steve Litt's email address.

Auld Lang Syne

In 1997, you sent in quite a bit of positive feedback on Troubleshooting Professional Magazine, but none on specific articles. Here are my picks for the five most readable articles from Troubleshooting Professional Magazine in 1997:

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. 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.

All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. 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.

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):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that this submission becomes the property of the publisher, Steve Litt, whether or not it is published, and that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.

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

URLs Mentioned in this Issue

www.troubleshooters.com: Steve Litt's website.

http://www.ganssle.com/tem/tem10.html: Jack Ganssle's Embedded Muse Newsletter, #10.

http://www.microsoft.com: Microsoft, the purveyor of Windows operating systems and the Microsoft Foundation Classes.