Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!caen.engin.umich.edu!conliffe From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Newsgroups: comp.sys.apollo Subject: Re: APR's and patches Summary: In search of ... A Commitment To Quality Message-ID: <42b6bc6e.b11a@falcon.engin.umich.edu> Date: 18 Apr 89 22:55:00 GMT References: <13047@watdragon.waterloo.edu> <331@tim.UUCP> <353@apcimsp.UUCP> Organization: U of M Engineering, Ann Arbor, Mich. Lines: 63 Tim, I believe most systems people have a simular blind spot with respect to the concept of patches and updates. To the systems developers, "its fixed in the next release, due out sometime in 6 to 9 months" is a satisfactory response. They know what is involved, what resources they have, and how the release blends with other marketing activities of the company. The consumer, however, quite often finds the problem as a fault in the originally delivered product, which was hidden from the potential buyer, but could have been well known to the developer well before the sale. It is a representation of some "misrepresentation", albeit common in the industry. Nevertheless, it is at a minimum frustrating; oftimes, costly to the ignorant consumer. Furthermore, "6 to 9 months" can be 20 to 25% of the development cycle of an entire automobile; many of your industrial customers cannot afford to wait that long. I know you try to avoid roadblocking customers, but problems with a system can be catastopic and abrupt (you're down), or mildly debilitating. It is the former that creates a drag on the progress of a customer, making us less productive. To link productivity with economic survival may sound a little harsh, but its real. The upshot is that while other vendors have their problems too, all of us lose if we don't attempt to do our best. (This is not a dig, but a case for considering the priority of customer support.) I have always assumed that "patches" were a company's attempt to bridge the gap between advertised and actual performance, fixing things that were "fixable" without a whole new release. Developers have no idea how maddening it is to work on a problem with your system for hours and/or days, only to find that it is a known fault in the system. To really piss someone off, make the problem one that was fixed two patch tapes ago, if the operator knew 1. the patch existed, and 2. it was available. Even then, calls to the hotline do not result in patch tape shipments; you have to be talking to just the right individual who is willing to send you the tape. I believe software maintenance is a chargeable service that helps me identify my or your problems with the software, and that may lead to enhancements to the software. Bugs, especially those known when the software is shipped, represent incomplete work on the part of the supplier. They may be completed later in the field via patches. Of course, not everyone will need the repair before the next release, so a public list of patches does not give away a chargeable service, but merely demonstrates a company's commitment to Quality and Customer Support. LONG LIVE A RECOGNIZABLE APOLLO. If you consider support in this vein, you probably will. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------