The customer is (almost) always right
Paw Prints: Writings of the maddog
There is the old adage that “customers are always right”, and while this is true 99.999% of the time, I have run into at least one situation where the customer was wrong.....
It was in the late 1980s, and I was working for Digital Equipment Corporation. We had gone to a DECUS convention, where users of DEC's equipment would go to learn more about using these wonderful machines.
We had produced a version of Unix called Ultrix for our PDP-11 line of computers, and several releases of this had already been shipped, proving itself to be a solid implementation of Unix.
At the event we had a reception, with finger food, beer and wine and I was standing there, munching some chicken wings and drinking a beer when a customer walked up to me and said:
“I think your Ultrix system really stinks.”
He actually used another word than “stinks”, also beginning with an “s” and ending with a “k”, but this is a family-oriented blog and we don't want to put anything bad here.
A little amazed at this attack, I politely asked him what the problem is. He told me that the system was really slow, and he could barely put ten users on the system.
I asked him to describe his system, and he told me that he was using an LSI-11 as a main CPU module, two RK05 disk drives and one quarter megabyte of main memory.
I started to feel my anger rise.
The LSI-11 was the slowest PDP-11 DEC made. It was basically designed to be a controller system, not a time-sharing system. The RK05 (2.4 Mbyte) disk drives were also painfully slow, and I think you will agree that ¼ Megabyte of main memory is not a lot for ten users.
I called over the product manager for the Ultrix-11 operating system. The product manager was also drinking a beer and eating a chicken leg when I said to the product manager, “I really want you to hear this customer's complaint”, and I asked the customer to repeat his configuration for the product manager.
At the end of the customer's spewing, I turned to them, and said “You as__ole, you have put Ultrix-11 on the smallest, slowest machine in the world and now you are criticizing the operating system. Why don't you put it on a decent size machine and see what it can do.”
At the word “as__ole” the product manager spit out his chicken wing and sprayed beer over the floor and the customer looked at me, at first with shock in his face, then sheepishness:
“You are right, I am an as__ole.” and walked away.
As I said, 99.999 per cent of customer are right, but sometimes they are just, plain wrong. It is your job to determine when they are right and wrong and how to rectify the situation.
Jargon file as an example of non-biased commentary?Hello Stéphane,
>Usually, when a customer complains because some software is painfully slow the seller answers that >it's the customer's fault because "the hardware you are using is not powerful enough".
>What was that "slow" LSI-11 ? If it's during "the late 80's" it's probably an 11/23 or above
The LSI-11 was the system board that was used to create the PDP-11/23 system. The PDP-11/23 was THE SMALLEST AND SLOWEST of the PDP-11s. As I said, the LSI-11 was created at that time to mostly be a "controller", not a general purpose system. However, for one or two simultaneous users it could typically "do the job"...not the ten that this customer was trying to put on the system (accentuated by limited memory and small, slow disks). Remember that this was pre-windowing graphics, and only had the command line and "dumb" terminals.
The real issue was address space, and as a system that did not have separate instruction and data space, the operating system had to use "overlays" that would swap in and out as necessary for various pieces of functionality. This, of course, slowed the system even more. Even with all 15 overlays being full of instructions, the user could not have all the functionality of the kernel at one time....they had to make decisions about what parts to leave out at system gen time.
The PDP-11/70, as a comparison, was rated at 1 million CISC instructions per second, could handle up to four Mbytes of main memory, and had separate instruction and data space. At Bell Labs we typically put ten to fifteen engineers at one time on a system like that.
>The Wikipedia link http://en.wikipedia.org/wiki/Buglix still redirects to Ultrix, Ultrix being well
>know as a very bad implementation of unix. The interested reader should also take a
>look at http://www.jargon.net/jargonfile/b/buglix.html.
The "interested reader" should remind themselves that the jargon file is not necessarily the most accurate measure of non-biased commentary in the world.
First of all, there were two implementations of "Ultrix", one for the PDP-11 based on Unix Seventh Edition, and a 32bit version for the VAX based on BSD 4* versions. The one I was addressing in my article was for the PDP-11, Ultrix-11.
When we retired Ultrix-11, there were no outstanding level I or level II bugs in the system (i.e. no system crashes or functionality bugs left). There were, of course, bug reports on "desirables", but that exists for every system. We donated the source code to the University of California, Berkeley. Their response was "this is not bad code", high praise from them at the time....
As to Ultrix-32, I once visited the University of California Berkeley, and found that they were using Ultrix-32 as part of their academic (versus research) computing center. When I asked about why they were not using BSD Unix for this, the administrators replied that if you went out into the labs, you found out that "Ultrix stayed up, and BSD crashed".
Now I do not want any BSD fans to get their hair up on this. Remember that BSD was in RESEARCH mode. You should EXPECT that research would be doing the latest and greatest and that stability is a balance between advancement and use.
I stand by the points made in my article.
The customer is (almost) always rightBeen There
'He insisted. I felt cornered. "Look, the design is truly idiotic, it will break under normal conditions." His reply: "Oh, why didn't you say so then?" I learned my lesson.'
in my case - in spite of explaining that the system (underpinned by a database) was so poorly designed it could never work properly with more than about 300 users management rolled it out for 3000.
- in spite of explaining that database took 30 minutes to come down and back up management forced a 15 min SLA of problem resolution for all problems
And the look on their faces when, during the 'pep-talk' about how support must do better. I asked if they had read my final report on the system when I left the project.
No this was a real case of 'a****hole' customers - and as events proved ' slow learners as well' because they rolled it out to the 3000 and it cost them big money and lost customers
Don't blame the software, blame the hardwareUsually, when a customer complains because some software is painfully slow the seller answers that it's the customer's fault because "the hardware you are using is not powerful enough".
What was that "slow" LSI-11 ? If it's during "the late 80's" it's probably an 11/23 or above ?
The Wikipedia link http://en.wikipedia.org/wiki/Buglix still redirects to Ultrix, Ultrix being well know as a very bad implementation of unix. The interested reader should also take a look at http://www.jargon.net/jargonfile/b/buglix.html.
Been thereOnce I had to tell a customer that his design for a product was far from good. When the customer insisted that we implemented his design, I had to make it clearer for him that it wasn't going to perform as good as he thought it would. He insisted. I felt cornered. "Look, the design is truly idiotic, it will break under normal conditions." His reply: "Oh, why didn't you say so then?" I learned my lesson.
typoslowest in the world
MSBuild is now just another GitHub project as Redmond continues its path to the light.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.