This issue of Troubleshooting Professional explores several subjects. In the article Troubleshooting..the Beginning Years., electronics expert Alex X talks of his early Troubleshooting experiences in, of all things, accounting. I follow that up with Why Accountants Make Great Troubleshooters?, and Model of Accounting Theory which discuss this interesting "extra skill" of most accountants. And then there's last month's controversial magazine, which drew much well deserved praise and much well deserved flames. See Retractions, Apologies and Policy Changes, as well as Letters to the Editor.
So kick back, relax, and read this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!.
Being a great Troubleshooter doesn't make one a good (or even adequate) reviewer. I found that out the hard way in the aftermath of last month's product reviews. One vendor took me to task for reviewing his 2 year old product in the same article as other vendors' modern production versions. He called it *Not Acceptable*. My initial reaction was "hey, I warned the reader I was doing this. I told the truth".
But the more I thought about it, the more I agreed with the vendor. No matter how many caveats I included, the comparison is still not fair. Nor was this my only sin. Besides several cases of comparing old versions with new ones, I compared beta versions with production ones, and I evaluated programs I had used for only a day or two. The fact is, most programs have irritating quirks for which time and usage teaches you workarounds.
I used to envy those reviewers in InfoWorld who got paid just to play with software. No more. Those guys earn their money, and it's a very rare skill. The reviewer must have the discipline to be even-handed, not let his or her feelings get in the way, procure the latest versions, work with the vendors, and follow a specific testing process. They must have a test machine devoid of other software that might cause conflicts.
I'm a Troubleshooter, not a reviewer. In most cases, in the future I'll be restricting my activities to recommending exceptional products, and giving tricks and tips on the use of specific products. In those rare cases when I actually review a product, I will alot the necessary time and resources to do it right.
I'm sorry for the quick and cursory manner in which I did last months reviews, and in the interest of fairness, have removed all negative reviews from the May magazine, since many of them were misleading.
Fresh out of high school I found myself working the graveyard shift at a large motel. Little did I realize that I was about to learn much more than the duties of a night auditor.
The date was 1976 and my tools consisted of an adding machine ( initially, I had to use 'pull the crank' technology ), cash register tapes and piles of guest room cards, restaurant and bar checks, credit card receipts, etc. The necessary reports never balanced initially, so I was forced to find the reasons why.... without the benefit of technology as it exists today.
Because the motel tasks were repetitive, I discerned patterns in the data:
1) Did so-and-so work in the bar this evening? If yes, then don't even try to use their supplied guest check data, recalculate all and discard the original values.
2) Is the out of balance value of the room register divisible by 28.89? If yes, then some Desk Cluck (misspelling intended) either over or under posted to the main register as this is the base price of a single room rate.
3) Is the out of balance value off by $90.00, 9.00, .90 or .09? If yes, then someone probably transposed two numbers. Try it...
12.34 - 12.43 = .09 12.34 - 13.24 = .90
As time passed, I became restless. With the motel's 24 hour coffee shop, and countless other late night activities going on all around me, I felt compelled to get paid for what I knew. needed to get out from behind my desk and live a little. I needed to balance the books fast and accurately.
Soon, after fine tuning my troubleshooting skills, I found that I could balance and finish my reports within minutes after the bar closed. I could then enjoy the nightlife. Or so I thought..... until other trouble needed shooting.
TROUBLE - A long-haired biker type enjoyed late night breakfast in our coffee shop one time and turned up short on cash to pay. SOLUTION - I ended up being the recipient of a real 'hells angel' zipper pocket style wallet complete with swingin' chain and all sorts of personal wallet contents for the cost of a cheap breakfast.....I will admit that this solution was aided by the local police visiting us for free coffee at the same time.....
TROUBLE - Motels regularly overbook (at least we did twenty years ago). A guest actually taught me this technique when he caught us without a room to match his confirmed reservation. Keep in mind that this was back when answering machines were not commonly used. SOLUTION - Ask the desk cluck for the general managers full name. Then ask for a phone book. Then ask to use their phone. You get the picture.. I believe similar results could be obtained today by asking for the general, assistant, or food and beverage manager as all of these folks should be able to get you a complimentary (FREE!) room at a comparable motel for the asking.
TROUBLE - Credit card use and abuse was as prevalent then as now. The tools available to check the integrity of those cards consisted of individual booklets printed with small text on tissue thin pages like a phone book, for each of the major cards in use. These were filled with tens of thousands of 'bad' card numbers. Our guests really did not like to wait and be subjected to the manual card verification process. The task was handed to me. SOLUTION - Not wanting to look up 200 card numbers every night, I put troubleshooting logic to the task. I enlisted the help of the Desk Clucks to verify expiration dates and mark the room card of any suspect cardholders. The resultant process went something like this:
1) Has the card expiration date passed? Goto Step 5.
2) Is the guest suspect? Goto Step 4. Suspect guests are defined by the following criteria:
a) driving a rustbucket on wheels, yet paying by AMEX
b) pawing through a pile of cards and having trouble deciding which one to use
c) carrying a card in their hand when approaching the desk rather than removing it from a wallet or purse
d) charging everything from 3 squares a day to the evening newspaper directly to the room
3) Inspect the card imprint. If the card has a recognizable corporate name on it
5) Card is Bad! Leave note for desk supervisor and mark room card for alternative payment.
One interesting side effect to this initial career choice turned out to be a addiction to mechanical pencils and scratch paper.....
In the above article, "Troubleshooting..the Beginning Years.", Alex X gives some tips on troubleshooting in accounting. His checks on working in the bar, $28.89, $90.00, $9.00, $0.90, and $0.09 were excellent examples of Universal Troubleshooting Process Step 5, Do the Appropriate General Maintenance. And his credit-card checking algorithm was an excellent example of evaluating likelihood in Step 6's triple tradeoff, Ease vs. Likelihood vs. Even Divisions.
Alex's article debunks that old myth that "Troubleshooting is for Techies". That myth is responsible for myriads of stalled cars, incorrect medical diagnoses, non-functioning computers, and (relatively) low salaries for Troubleshooters.
Most accountants are great Troubleshooters. I see it in my work as a computer programmer. When an accountant gives me a symptom description, it includes not only the symptom, but what's getting added to what and why that's wrong. Usually all I have to do is find the part of the program that does the addition the accountant tells me about, and the problem is obvious. But why are accountants such good Troubleshooters? Read on...
One explanation might be the exactness of the Model of Accounting Theory. This model, which resembles the Mental Model of a machine. Note the level 1 items progression from general to specific, starting of course with the Objectives of accounting. This model is the very foundation of accounting, and the Generally Accepted Accounting Procedures (GAAP), which accountants are taught from morning to night in school. With such continuous training in such methodical thinking, it's not surprising accountants are better than average Troubleshooters. Below are my notes on the Model of Accounting Theory, as taken from my class notes in an accounting class.
Below are my notes on the Model of Accounting Theory, as taken from my Intermediate Accounting class notes at Santa Monica College. My experience has been that once you understand this model, Financial Accounting (but not Tax Accounting) is logical and intuitive. Is it any wonder that with this model as a starting point, accountants make excellent Troubleshooters?
We at Marketwave sincerely appreciate your writing about Hit List Standard in your magazine, although we have some concerns about the content. In specific, you state that the program has bugs, which is certainly not the case.
In regards to the FTP problem you were experiencing, had you simply emailed or telephoned technical support (or even visited the tips and tricks page accessable from the main help menu,) you would have been instructed to add an additional slash after the ftp.mycompany.com//, which takes care of what is probably your relative path to your log files. In addition, you mention that FTP is not the best way of accomplishing log transfer. For beginners, this is only necessary if you are running a UNIX or Mac server. Secondly, if you are running a webserver, you are certainly not running it over a "phone line," rather a leased line such as a T1, which makes FTPing the log files insignificant to the task. (FTPing a 10 meg file over a T1 takes only a minute or two.)
In addition your mention of .dll conflicts has absolutely nothing to do with Hit List, rather that you installed Hit List 2.5 and Web Trends on the same machine with a few other factors, and WebTrends' version of the graphing control (which is a different version of the same control) trampled on Hit List's .dll's. We have documented this happening 3 times out of 10,000+ registered copies of Hit List Standard 2.5. Had you used Hit List 3.0, this problem would have been impossible because 3.0 uses a different graphics engine.
Finally, you mention that Hit List can't be used for multiple sites. This is quite the opposite, considering the one-touch generation of reports for multiple virtual servers, ability to create multiple databases and in the newest version, Hit List 3.0, an additional Virtual Server Manager. Our research shows that over 95% of our customers use Hit List Standard for multiple sites.
Again, we feel it is important that writers to continue to review our products, and appreciate your time in doing so, but would ask that in the future you contact us at (206)682-6801 regarding our product so that we can give you the same support that we offer our customers (and potential customers.) Saying there are bugs in the product when that is not the case is an unfair representation of our product, and we hope that you will consider writing a follow-up that addresses the realities of these issues.
Sincerely, Sam Barer Director, Electronic Marketing Marketwave
We anticipate two to five articles per issue, with issues coming out monthly. The next few issues we'll be looking for articles on how to bring the Troubleshooting Process to all areas of business and society. This can be done as an essay (like the articles above), with humor, or with a case study. A Troubleshooting poem would be nice. We are *not* looking for ultra-technical or system-specific articles in the next few issues. 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):
After that paragraph, write the title, text of the article, and a two sentence description of the author.
http://www.iserv.net/~alexx/ is Alex X's website.
http://www.troubleshooters.com is Steve Litt's website.
http://www.troubleshooters.com/ustep5 contains step 5 of the Universal Troubleshooting Process, "Do the Appropriate General Maintenance".
http://www.troubleshooters.com/ustep6 contains step 6 of the Universal Troubleshooting Process, "Divide and Conquer".
http://www.smc.edu is Santa Monica College's website.
http://www.stoopidsoftware.com: Home of the Gomer HTML editor.
http://www.adobe.com/prodindex/pagemill/main.html: Pagemill for Windows download page.
http://www.microsoft.com: Makers of Frontpage, MS Word, MS Paint.
http://www.wbmedia.com/publisher: Home of Web Media Publisher Pro 2.
http://www.sausage.com: Home of Hot Dog Pro.
http://www.marketwave.com: Home of Hit List Standard
http://www.netgen.com/products/net.Analysis/Desktop/1.1/: Home of Net.Analysis Desktop