Articles / It's Always the User's Faul…

It's Always the User's Fault

Here I am, checking a new Web application for bugs. I am one of five people who will use this software, and all five of us have found bugs or missing features. As requested, we email our bug reports and feature requests to the development team, and what we hear back on almost every bug report is, "It's your fault. You didn't do [insert action here] correctly. It worked fine for me!"

Sometimes, dealing with programmers is a hair-tearing irritation, and this is one of those times. At one point on this particular project, for example, I noticed that some highly necessary online forms weren't visible.

Response: "You didn't scroll far enough down the page."

My mental answer: "Excuse me? Are you really saying that after five years of using similar Web site content management systems, I haven't learned to scroll down a page to see all of it?"

The same missing forms were noted by three separate users in four browsers running on two different operating systems, which overcame the second excuse, that it was a problem only with my particular browser. I held my temper and calmly told the development team leader that it wasn't just me or Linux or Netscape, so why not take another look, huh, just to make me happy?

We went back and forth a few more times. Finally, grudgingly, the programmer responsible for that page and the functionality behind it looked again, and somehow, suddenly, he noticed that, yes indeed, those forms were missing, just like the dumb users had said all along.

Quit With the Excuses, Already

In the example above, it took four days to convince the development team that a problem existed. Fixing the problem took half a day, and then we, the users, got snapped at by the programmers because we hadn't started testing the software a month earlier, when we were originally supposed to start looking it over. Excuse me? How could we have looked at it when the login page didn't work, which was the first bug we reported? Not that reporting it did any good at first; before that bug could be fixed, we had to go through several rounds of "You're not doing it right" accusations from the developers. We are people who work on the World Wide Web all day long. We don't know how to put a username and password into an online form? Oh, come on!

This is not the only software project I've seen in which the amount of time spent denying that any problems existed far exceeded the amount of time it took to fix them once the programmers admitted that the users -- just maybe -- knew what they were talking about. It is hard to stay calm and courteous toward software developers who seem to spend one third of their working time making excuses, one third of it working, and one third of it complaining about how they are being pushed too hard.

Suggestion to programmers: You can double your productivity by cutting out the excuses and user-blaming, and still have plenty of time to bitch about how hard you are being forced to work. Actually, if you doubled your productivity, you wouldn't be behind schedule and getting pushed at all, so you could cut your bitching time, too, and spend some of it on other, more productive activities -- like checking freshmeat at least five times every day.

Customers, Not Users

I have a boss-level sysadmin friend who will not allow programmers or junior sysadmins who work for him to refer to "users" at all. He calls them "customers", and expects everyone in his department to do the same.

When you think about it, users really are customers, even if they work for the same company you do. If they weren't busily doing whatever it is they do (in between goofing off, of course), there would be no reason to have computers in the building -- or programmers or sysadmins, either.

Even in a Free Software project, the idea of treating users as customers has its good points. For one thing, with a little patience, today's low-level user can be turned into next year's skilled bug-spotter, documentation writer and editor, or multi-system compatibility tester who can help not only you but many other Free Software developers. And last I looked, most Free Software developers still need to eat, and usually have some sort of job (unless they're students, in which case they will have jobs sooner or later), and learning how to deal with users... I mean customers... nicely in a Free Software situation is excellent training for doing it in a work environment.

Why Bosses Have Pointy Hair

PHBs aren't born that way. Their hair gets that "horned" look only after years of hearing excuses and denials from programmers and engineers. Hair-tearing causes points and baldness. If you don't believe me, get into a management job that requires constant contact with software developers, and wait a while. One morning, you'll wake up, look in the mirror, remember this little story, and realize that I told The Truth.

Luckily, I don't deal with programmers very often, at least not as a user... I mean customer... or boss.

Perhaps that's why I'm closing in on 50 and still have a full head of non-pointy hair.

Recent comments

08 Dec 2001 13:19 Avatar nightwriter

The problem is more than bad communication.
The problem. Well sorry Roblimo. It's yours. Note
I'm not a developer. Instead I'm a project
manager. Frankly. you blew it. Why. YOUR NOT a
member of the development team. You DIDN'T
clearly state the specs for the project and then
verify that it was understood, and finally. These
developers still have jobs. In the case of
something as small scaled as this job apperantely is
you need to better communicate the needs in a
clear concise and yet detailed enough manor that
the developers can get there "heads" around the
concept. From day one you should have planned a
set of "tests" that the project needed to pass
before acceptance. Simply saying that it needs to
work is not an acceptance test. What exactly are
the conditions that it will be used under. How
should the UI be layed out. (sorry for the next one
freshmeat) A great example of bad UI is the page
we are on. Unless you know that clicking on "not
logged in" will get you to the login page you can't
find it! Eliminate the words simple, simply, obvious,
and just from all conversations. If the user can't
do it, or the programmer doesn't understand the
request it isn't simple or obvious. Understand
where this project fits into the programmers duties.
If this is "an oh and can you do this too" project
you have a gaurantee of poor effort and result.
Once you as a manager understand the level of
importance of the project then you need to convey
this to the programmers. Often the problem is one
of percieved importance. If you are gripping about
a project to be used by 5 people and they are
under the gun for a project to be used by the
world... guess what. You lose. Again let me state
the importance of a clear spec on the project. "I
want something that does this" is not a spec.
Specs should include but not be limited to:

1. Language(s) to be used. C may be cool but
browsers don't read it.
2. Layout of UI
3. Terms for buttons
4. Color Scheme
5 detailed description of usage
6. criteria for test and acceptance.
7. Usage conditions (Linux and Mac .... Browser or
X windows etc.)
8. Milestone dates.
9. User and programmer POC's
10 Terms for making changes to the spec.

In addition as a manager you need to learn the
sandwich theory. Compliment, complaint,
Compliment. If all they hear from you is bitching
your voice will quickly have a band block filter
applied to it and no one will be willing to listen to a
thing you say.

Finally and unfortunately, as a manager you need
to be willing to fire a programmer. Sorry folks this
isn't a pleasent or fun thing to do, but
occasionally needed. If the programmer
can't/won't do what is needed.... politely can
him/her. Some people won't work to spec, always
have go off on their own tangents and refuse to
meet deadlines. Let them work for the
competition. They are a disruption not only to
your project, but often they also bring down the
quality of life for your other emplyees as well.

11 Nov 2001 23:00 Avatar kitasumba

Re: Most of the time, it _IS_ the users fault.

> Bullshit. Please get a clue before
> making these blind comments. You
> obviously know absolutely nothing about
> the hardware in question, and thus have
> no valid basis for your utterly
> misinformed and inaccurate comments.
> Yeah, being able to probe attached panel
> information from the device would be
> nice, and would save headaches when
> dealing with inept users.. but this
> isn't a dream world, and not all
> hardware works in such a nice fashion..
> this particular controller especially
> does not. Next you'll be telling me that
> non-pnp ISA devices can deal with their
> own resource management because you
> think it *can* be done. Please get a
> clue. Write some code, and stop talking
> out of your ass about things you know
> nothing about.


This is pure ACID! You should step down from that throne of kernel kingdom for a while and listen to (not necessarely follow) some advice by those humble humans.
So my ignorant advice is: remember XF86Setup? If the configuration does not work out the prog falls back. That is, you setup a console configuration tool (if without the driver you cant run even console, then you MUST fork the driver in 4 different ones making less confusion among users). This tool starts the configuration (modprobe was very well prompted by someone) if does not recieve user confirmation within a certain timeout passes over to the next one up to 4, if it still didn't get no confirmation it exits failing and printing an error message repaiting that the user should confirm upon success or consider the fact that the driver might be inapropriate. No hardware probing needed anytime...
Now flame me...
I've got plenty of room down here at /dev/null

04 Nov 2001 20:58 Avatar farnz

Ways for a developer to keep it friendly
When I was doing embedded systems work, I
occasionally had to deal with bug reports.
Invariably, the first bug report I would receive (from
a technically competent engineer) would be along
the lines of, "I plugged it in, and it doesn't work
properly".

Stage 1 was to find out what the setup was, and try
and duplicate it.

Stage 2 was to get the engineer to talk me through
the problem, until I duplicated it, or he spotted a
mistake. If I duplicated it, the immediate reaction from
me was "OK, I see the bug here now. I'll try and find
it". This is the hardest stage, as slight differences
can cause problems.

Stage 3 was to find the bug, or a workaround.
Immediately I had done so, I e-mailed the engineer
concerned and either just told him I knew what was
wrong, or give him the workaround.

Stage 4 was to fix it, and issue the new software *to
the engineer concerned*. This ensured that the bug
was fixed; if it wasn't, go back to Stage 1

Stage 5 was to pass the new version past QC. If
they were happy, issue the version to the factory. If
not, go back to Stage 1.

In the end, I rarely got an irate engineer the second
time he found a bug, and I usually got the bug fixed.

31 Oct 2001 13:34 Avatar chronostachyon

Re: Most of the time, it _IS_ the users fault.

>
> % Why not just make the
> configuration
> % probe option that asks the user
> % questions till the display works.
> I'm
> % sure a user will be happy answering
> no 3
> % times and yes once to get a display
> that
> % works.
> %
> % eg Prog tries Driver 1. Asks user
> if
> % it works. Yes - save it. No - try
> next..
> % 4 times isn't an issue. But if your
> LCD
> % base got larger another way might
> have
> % to be thought of.
>
> Keep dreaming. This is a kernel
> driver, it doesn't do keyboard input.
> Instead, an option for panel type is
> provided which is the only clean way to
> deal with this. If the device was
> intelligent, this wouldn't be a
> problem.. on top of this, the device
> doesn't throw an error if a panel isn't
> hooked up.. so it really makes no
> difference what type the controller
> thinks its dealing with. It's up to the
> user to know what they have hooked up to
> it if they want it to work properly..
> this is a fairly common thing, and
> trying to think of stupid hacks to get
> around it is not a proper solution. Not
> all hardware is as friendly as it could
> be.. that's life.


What about a pseudo-file in /proc to change the panel type at runtime? If the driver could support that, then it would be easy to write a userspace tool to guide the user through finding the right setting. If not, you could even write the config tool to just run "modprobe", ask if it works, then call "modprobe -r" if the user answers in the negative.

26 Oct 2001 11:14 Avatar bkorb

Re: Most of the time, it _IS_ the users fault.

> If you had bother reading anything of

vitrol aside, consider the possibility that it is a hardware
design issue. Self-identifying hardware technology has
been around for a while now, ....

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.