Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!limbo!taylor From: taylor@limbo.Intuitive.Com (Dave Taylor) Newsgroups: comp.sys.hp Subject: Re: HP Customer Support... Message-ID: <207@limbo.Intuitive.Com> Date: 1 Dec 89 06:25:15 GMT References: <203@limbo.Intuitive.Com> <1320019@hp-ptp.HP.COM> Reply-To: taylor@limbo.Intuitive.Com (Dave Taylor) Organization: Intuitive Systems, Mountain View, CA: +011 (415) 966-1151 Lines: 146 Doug McKenzie of HP's Pacific Technology Park site responded recently to my article in this newsgroup about the state of customer support in the computer industry, specifically that of HP. In his posting, Doug seems to have missed much of the gist of what I am talking about, and though I have since posted another article that clarifies my points (I hope!), I thought I'd delve into some of his comments anyway: > It seems what you're suggesting is that HP Support is terrible, [and] > the best in the business. That's exactly what I'm saying, though rather exaggerated a tad; I feel that the state of customer support in the Unix marketplace is far worse than it should be, and while HP is a front runner in the game, they too suffer from many of the same problems. What's worse, these problems are not only visible internally, but are just as bad for 'real' customers, people that are paying $$/month to have HP help them along. HP is doing a good job. They've got a very talented crew of people on board, many of whom I am priviliged to consider my friends and professional colleagues, but they're not "done"; there's lots and lots of room for improvement... > You found "hundreds of bugs", "NONE of them were ever resolved"? Are you > serious? With this 0% fix rate, I suppose your inescapable conclusion is > that no bugs ever found in HP-UX by anyone, are ever fixed. I can recall being in situations where I literally would spit out a couple of bug reports a day for a few weeks, when I was doing what I describe as "hitting the edge" of the operating system. I cannot recall, however, ever successfully having had ANY of them resolved. Further, I can only surmise that I wasn't being singled out for the "don't resolve" treatment, and if that's the case, well, then there are a whole lot of defects and enhancements that have never quite made it into the product or been otherwise resolved. And of course, my "inescapable conclusion" is simply that for me, the ratio of submitted to resolved bugs was quite low, and if I take into account the *time delays* between submission and hearing any response at all, well, then it gets very close to 0. I can recall in particular a bug I submitted against the TCP/IP sockets implementation on HP-UX 5.2 (I think) on an early 300 series machine. With the aid of a few other engineers we resolved that when opened using "fdopen" to have two streams, one for reading and one for writing, the file I/O stream buffer size and the TCP/IP window size conflicted so that I would get garbage if I were trying to push lots of information through quickly. We pinned that baby down to the size of the buffers, had a nice small sample program that demonstrated the problem, AND figured out a workaround (using the setvbuf() command, if I recall correctly). I can well recall that it was almost two months before I heard back from the Fort Collins Networking group, with the response that "it didn't fail on our machine, sorry." That was it. I called up some friends at the division and asked them to look into it further, sent them copies of the bug report, and lo and behold, suddenly one of the remembered that it was indeed a defect that they were aware of, and indeed they had a well known workaround to do with setting the stream vbuf to a specific size 2x the size of the TCP/IP buffer (or something like that). I then responded to the response to my bug report with further information including some further thoughts and hints on what might really be wrong, and about three or four months later, after the next rev of the operating system was released, I received another summary note stating "report closed: fixed by new release of operating system". That is not necessarily typical of the type of interaction one ends up having to get defects resolved, but on the other hand, just like with fleas in the carpet, when you hear about one, you can bet that there are twenty more hiding... And that is *not* what I'd call adequate and proper support. Whether internal or external, that's not the way to polish and produce the best possible product line for the happiest customers. > .. Customers hate it when a release is delayed, just as they hate it > when they find bugs. It's a matter of balancing timing with the > criticalness of the bug. Not really. It's a matter of viewing the whole thing as an "all or nothing" sort of game; what if HP implemented some sort of nifty useful binary patch utility and then sent out "incremental patches" to known and reported bugs? I mean, with the delays in the way the company (and other companies in the industry, to be fair) plans its OS releases years in advance, it's quite possible that a bug reported against the current HP-UX 6.5 release would not only not be fixed by 7.0 (since it's shipping already) and 8.0 due to timing, but it might not make it into 9.0 either since that'd be approximately TWO YEARS after the bug was reported and might be summarily resolved as "obsolete". That's a long time for a customer to wait... > I think your innuendo is that the bug "owner" is lazy, and this is > VERY UNTRUE, in my experience. I don't think this is the case at all, Doug. I think that *the system* is set up so that there is no motivation other than negative reinforcement (e.g. "too many outstanding bugs and you're in trouble") for programmers to become craftsfolk, and to ensure that the code they're responsible for is as free of bugs, defects, and problems as humanly possible. Just like with system administration, it's a negative feedback job. Further, no-one gets brownie points for having bug free code, but people DO get brownie points for having lots of bugs that they can resolve quickly. It's like some sort of Orwellian Pavlovian experiment or something... just like the problems with superficial application of code metrics; people learned to write statements that filled multiple lines, and learned to have more meaningless comments to improve their code "ratings"... [I can feel in my bones that I'm skirting a fairly heavy psychological, cultural, and sociological issue here --- sorta like Robert Persig -- but I shall try to refrain from preaching...] > Why is the SSB "infamous"? The SSB is infamous because it's lots of useful and vital information in a format that is almost completely unusable, and certainly one that does not encourage casual browsing by interested software professionals and others that might well want to know what's contained therein. Plus it doesn't come out frequently enough... - - - Anyway...this is becoming a most interesting discussion here in this newsgroup, and I hope that within HP (and perhaps with the support organizations of a few other big companies) they're further discussing what's going on here... I would be delighted if we could get some people from some of the support organizations involved too. Posting some statistics would be great information for us to chew on, like number of HP9000-related reports received weekly, breakdown of internal vs. external, average time to resolve, number and percentage still outstanding, longest outstanding and why, and so on... Unfortunately that's all company confidential. Which means that we might well all be blowing hot air and not actually destined to "get" anywhere with this conversation. Ah well. C'est la vie. From the edges of reality, -- Dave Taylor Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor