This is the title of a column by Jon Udell in Infoworld for August 28th, 2006. This article is definitely appropriate and can be appreciated by millions of end users and developers for that matter. We have been arguing in this weblog that debugging computer applications in the era of n-tier, heterogeneous,multi-platform systems has become devilishly tough.
Well Jon makes my case for me in no uncertain terms – but adds a new dimension – vitualization. This occurs more often in server setting but also can occur on the desktop and with Web Service or applet/plugin based Web client applications. For example, I have learned to dread “online demos” using collaboration software like Adobe Breeze, Microsoft Live meeting, Webex or similar software. Inevitably the software that runs perfectly well on Linux or Windows 2000 or Mac OS just does not translate across the ether with any reliability.
Well virtual systems where you are running Linux applications in Mac sessions or DOS applications in Linux X-Windows or the TCP Gerrymandered Net – Windows XP is running Oracle in a Mac OS/X virtual Window which in turn is going across the TCP/IP space to pull data from a Windows Server 2005 in a third virtual space on the same computer. Yes – it is as daunting a setup as those old breadbox circuit boards or the PBX backend kept locked up in the heel hole known as the Communication Room.
But note what Jon had going for him on the “silly little thing” of a bug that he finally managed to track down:
1)his own ability to track problems from hard core development experience;
2)a special relationship with software vendor;
3)so special he is able garner the time and attention of the lead developer;
4)the ability to devote substantial chunks of time and processing power on the bug;
5)ability to get a version of the app with special verbose bug tracking incorporated.
Now mere mortals like you and I will be lucky to get on the debug hotline a softare guru a)that can speak English; b) wont want to take down your Private info for the mteenth time; c)will have solicited your credit-card number before supplying any information; and d)the information that he/she does supply to you is a series of questions that clearly indicate he/she has hardly a hope-or-a-prayer of describing your problem to the next level-up of support technicians – forget solving the problem.
Now obviously, not all bugs and problems will have these duress points – you will be able to get a lot done with a second mind on the problem; however my (and I think also Jons) concern is that system support and debugging has with the trend to n-tier, virtual and Web Services taken a turn towards tougher – lots tougher. So choose your software vendors on this risk reducing set of guidelines:
1)they tend to deliver ultra-reliable code;
2)they are open source or substantially so;
3)they support pro-active bug/problem FAQs and forums on the Web where users do go to find out answers to problems. Pro-active means that support staff actively patrol the forum and step in to answer questions – a)that are easily dispatched yet no answers appear to be forthcoming or b)that nobody seems to have a handle on.
4)their software emits intelligible error codes from which a user can get some idea of whether they are making a dumb mistake or have a serious problem. This means the error code supplies users also with hints on how to fix the problem.
5)In the case of serious problems, the system is equipped either with configuration settings or switches/clicks within the error messaging which allows the user to emit appropriate dump code.
For the record, my own prefernces are 1), 4) and 3) in that order. I make really dumb mistakes from time to time and do appreciate software that gently remind me to check the project preference settings or back-up the workspace and then reload and see if the problem does not disappear. But what I really like is rock solid software – no bugs, no security exposures, and it delivers Energizer Bunny performance.
(c) JBSurveyer 2006