It's Always the User's Fault
 by Robin Miller, in Editorials - Sat, Oct 13th 2001 00:00 UTC

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.

Author's bio:

Robin "Roblimo" Miller is Editor in Chief of OSDN (freshmeat's publisher). In his spare time, he is working on a book, Build Profits Online, for Financial Times Press.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: Software Development :: Bug Tracking

 Comments

[»] The problem is more than bad communication.
by NightWriter - Dec 8th 2001 13:19:41

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.

[reply] [top]

[»] Ways for a developer to keep it friendly
by Simon - Nov 4th 2001 20:58:42

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.

--
-- Simon Farnsworth simon@farnz.org.uk

[reply] [top]

[»] RE: It's always the users fault.
by glbny - Oct 24th 2001 12:52:15

Ok...this is looong, but hopefully helpfull......
This discussion in general has been enlightening
for all of us, and I like the comments of Michael
McKinsey [ voice of reason.. ], Brian and Josh -
[sad downtrodden voices of the trenches 8-) ].
As someone who has written some code, and
had to also support it, I KNOW it can really stink.
In corporate settings the mindset of management
is: Hey, joe needs to close 20 calls in a day. It
is Weds. and he is far away from that..... They
don't wan't you to HELP the customer to fix or
document a bug that ONE person reported ( and
in all likelihood hundreds are complaining about ).
It will get fixed in the next release, if we can whip
the developers into next weeks' deadline! Sound
familiar. I will get to bug reporting software in a minute...
I have learned as a support person, you can achieve
HUGE success and get people to really help me
support them by doing a few things:

1. Zen (?) .....*be* the user, my friend.
Enlightentment will come from getting in
side their (also!) downtrodden heads.
Gently remind them that you may have a
slightly different config. than they do,
and that you can't SEE their screen, and
you need them to help you be reading it
verbatim to you. Really. Make them feel
like their participation is a BIG help. When
you do this kind of stroking, you can get
them to do backflips. Don't just repeat like
a robot "....once again, read me the
error message..." until you get what you
want....it can become a battle of wills -
This sends the customer the message
that you think they are children or less.

2. Humor - Disarm the combative. They
have a gun to the head. Their boss wants
X done yesterday. They have an ulcer and
a sick infant at home and NO sleep. If you
are not a funny person, then just make
pleasant small talk...... "hey, what state are
you in ? Howz the weather there ....? While
their 486 is wheezing its' way into your main
screen. When they see you are human, they
respond.

3. If you are the programmer or hardware
designer, then yes there just may be some
situations where the user does try to configure
the hardware/software incorrectly. You
may not have the solution TODAY. I know
that in one industry, we could not save the
field tech from using the wrong input voltage.
Today we can. Someone figured out how to
save them from not reviewing..... The solution
may be to have someone you know who is
technically challenged, give you feedback.
Perhaps color coding parts to make matched
sets seem obvious is a solution. Perhaps
a corresponding manual change is needed.
Or maybe technology will help like it did above.

4. [Near topic BUT important help for all of
us 8-)]
Bug software. I have seen some GOOD
stuff out there, and each piece has plusses.
Some is written in Java, alot in PHP. I won't
judge any on the dev.tools. I will say that
alot of the people who wrote it said that they
use it [ great ] .....but in the support arena
nobody seems to have done an end to end
integrated package. That is each package
addresses one of the following but not ALL:

A. Bug reporting/tracking B. Project Tracking
C. Timesheet/timetracking D. Billing
E. Symptom, Searching, and FAQ database.
[ What the user thought was wrong -
what we now know was wrong, what
were the symptoms, HOW we fixed it
all in one searchable database - why
should a user have to read a 100 page
FAQ hoping his problem really was
FREQUENT enough to get on? ]
F. REPORTS - Timesheets for each employee,
Time by project, blah, blah, blah.

As a sys. admin/support person, I have to
answer calls, fix bugs, teach, read tech stuff
and bill the time to the right place or project
[ inside or outside the company ]. I have
a FANTASTIC very simple tool for helping
me track my time, because I just click on
the activity that I am working on, and the
timer handles the rest, acumulating time.
One problem. The developer chose not
to really document the code, and I don't
have time to change/fix the parts I hate
like the reports..........BUT - The basic
interface is perfect - you know .....answer
the phone, it's Jane about project #345.
Click on the project number 345 button,
accumulate time to that. Hang up, go
back to project X, click on that. Simple.
AND they were smart enough to NOT
clutter it with other administrative parts
of the software [ or the config parts ].
( I wish it didn't clash with EasyCD
creator 8-( .....oh well. )

Anyway, it would be truly great if ALL of
this effort from individual projects could be
joined together to form one GREAT work.

.....man, I really got windy!!! Hope this
helps.

Enjoy.

[reply] [top]

[»] From both sides
by Paul K Egell-Johnsen - Oct 17th 2001 08:33:32

There is a lot of finger pointing in the comments, it seems the article struck a nerve.

The most important thing for a developer is to not get emotionally involved in the code or product. Its just a product, just a job. When someone complains in some way it is usually for a good reason. Not always a reason which you are to blame for, that is true.

The point is to meet every new customer who has a complaint with an open mind. Assume that the person is a person who isn't dumber or in any way inferior to you. Instead as a person who has different experiences and thus can't be expected to know what you know.

(Someone talked about code forks and stuff. Hopeless, bad attitude. Not eveyone is a programmer, and even programmers have better things to do than fix your damned bugs all the time.)

If a bug report is bad (and we all know that many are way out there), be sure to reply courteously and ask for more information, point them to the bug submission FAQ, and be sure to CC the reply to a repository.

If the bug submitter doesn't respond or help with the needed information you have your back covered, because you can say: "I took action. I asked for more information, and that information hasn't been forthcoming".

If anyone have a problem with that response, they should get a lesson in common courtesy.

(Do you think that a carpenter gets phoned up and told: My house has a problem, fix it? No, they get information about where the problem is and other information.)

I need to improve as a programmer when answering bug reports, I need to improve as a bug reporter when contacting some open source projects.

But Robin is right, the idiotic mind set that I'm in wrong or not enlightened because I submit a bug report is pretty annoying.

I hate it each time I have suggestion or a bug to the KMail people where I get the response "it isn't supposed to do that", "are you sure you are doing it right", "have you checked the earlier suggestions", "fix it yourself".

The last one is a laugh.

--
Paul K Egell-Johnsen Adaptive Design

[reply] [top]

[»] Helping people feel less stupid
by Richard Jones - Oct 15th 2001 06:35:39

Most people hate feeling stupid. If they've made a silly mistake they won't want to own up.
The first time they come to you with one of these is the most important. If you make fun of them or treat them as imeciles, they'll try to cover up even more the next time.
I try to remember sily mistakes I make so I can let them know they aren't the only ones who mess up.
That way they are more co-operative with responding to questions I ask the next time.
As always, relationships are key...

--
Richard Jones -Don't climb trees to look for fish

[reply] [top]

[»] My comments
by Aod - Oct 14th 2001 04:51:54

I have worked my way up from quality control/escellation, to tech. support, to programmer, to systems administrator, to head systems administrator, and finally (currently) CTO. I have seen it all, from all sides.

There is a communication problem. Most users do not have any idea at all what is going on in their computer at a programming level. They pretty much know that when they type X in, and click Y button, the resultant should be Z. So, when they relate their problem to the programmer, often the communication breaks down. The user can only offer to the programmer "I typed X, clicked Y, and the program did not do Z - it instead gave me this error." Okay, that limits the problem down to 1:1,000,000,000,000 different things that could have gone wrong at that moment in time, can the user elaborate? Usually, they cannot. There is no possible way that a programmer can even start to try to figure out what the problem is based on this scenario, which is the most common scenario in any company. Ever try to debug register dumps when a program crashes in windows? Not even Microsoft can debug register dumps on their own software, because depending on a lot of factors - including the phase of the moon - these register dumps are an extremely unreliable way to debug a program. Debugging a bug in a program under Windows is non-existant. There is no descent way to debug under Windows - short of using built-in breakpoints in your software and running it directly through a debugger. Nasty. Why Microsoft hasn't included better ways to debug software crashes is beyond me. Enter UNIX and UNIX-like OSes. I will not side for either, but I will say that UNIX has had programmers in mind since day 1 (in 1969). When a program crashes, it dumps it's memory heap into a file (core dump). This file is an exact replica of the memory image of the program at the time it crashed. This, coupled with excellent debugging software, makes debugging a program a piece of cake. Now, under a UNIX, or UNIX-like OS, when a person calls you up and says "I typed X, I clicked Y, and it did not do Z, instead it said: 'Segmentation fault (core dumped)'. Now the programmer can run a debugger on the core and see an exact stack-trace of what happened, find the function that the program failed at, and see what data was sent to it, and the events that led up to the programs demise. It does not matter if the program was something as simple as writing "Hello world" on the screen, or something as complex as an online database call reference ticketing system for a huge company. Either way, when that program crashes, it will produce a core dump, and the programmers have at least a really good lead as to what caused the crash.

I have also seen a good deal of problems caused by programmers simply not testing their own work. Unfortunately, it seems that a lot of programmers out there feel that if their code compiles with no errors and little/no warnings, then the program is fine. This is not the case at all. Compilers are smart, and take a lot of things into account, but there is no way that a compiler can keep you from making all mistakes possible in any language. In the case that you mentioned, that forms simply were not coming up when they should be. This would not have been a problem had the programmer simply tested his own work. I test every single facet that could go wrong in a program when I write one. The best person to know where every single fault in the program is, based on any number of circumstances, is the programmer who wrote the program themselves. The way I do things generally work very well for me. 1) I write just as much code as needed until there can be a stopping point. 2) I compile the the code. 3) I test the work that I did in step 1. 4) Debug/Fix any bugs that I find in the segment of code that I wrote in step 1. 5) Repeat until the program is fully written.

These steps may seem like common sense, but all too often programmers love to bang out the whole program as fast as possible. If they go back and try to test their software, there are so many different pieces that easily get skipped over when they are testing. I halfway blame our current education on this problem. Instead of teaching "Write a program that will do this.", we should be teaching "Write this fragment of this program that will ultimately do this, and concentrate on this fragment." Some colleges are finally starting to wake up to this idea, but it takes a lot longer to teach how to write and test fragments, rather than bang out the whole program as quick as you can. I have turned a few professors onto this idea, and they are teaching the "fragment" way.

We are done with the instant gratification of software. We have been instantly gratified, and there is no more that can be offered that we really need instantly now.

We no longer need "upgrades" that add a couple of features and fix a few bugs that should have not been overlooked to begin with. The only thing these "upgrades" do are allow you to sell more of your product so your 1st quarter earnings do not fall lower than what was projected.

Sorry that this post was so long, but this is how the market was, and is. There is no wonder why we have so many problems between vendors/users. And, there is no wonder why programmers have so many problems trying to figure out what has gone wrong with their program. There is no wonder why programmers write bad code, when our educational system does not teach how to write a good, well tested, program.

Hey, write it quick, shit it out, get it out there before the 1st quarter earnings report. We need to sell X million copies of Y software so we can meet our profit margin on form Z for that quarter. We'll fix the bugs later after we get the software out there. After all, these dumb Americans won't know the difference. This has been {A HUGE CORPORATION}'s motto for a long time, since the 80's. And we are still living up to this motto. Slowly people are starting to see this, but it's amazing the amount of people who don't. Even though this scenario has been played out by the same company over and over again. Then we look at this company, and we ask, how many changes have been made? From '95 to '98 - There were a few bug fixes, and the GUI got a minor facelift. From '98 to ME - There were a few bug fixes, and the GUI got a minor facelift. From NT 3.51 to 4.0 - There were a few bug fixes, and the GUI got a minor facelift. From 4.0 to 2000 - Well, same stuff. Except, there are a few new useful programs. However, they are all still buggy. We'll see. As far as XP - Well. Again, it looks like ME with a facelift. It also has a few new programs and such. Still buggy. I cringe at the idea of how many security holes are in this new OS that have not been found yet.

So, as I said up top. I see it from all perspectives, and I feel that I have a good understanding of everything that is going on out there. This is my take on it all, and I do feel that everyone should feel the same way. After all, why are we paying for software that has been out there doing the same thing for many years for free? 1 word - Marketing. It's too bad that most higher-ups in companies do not actually go out there and look for alternatives. The easy way out is to play into the market.

[reply] [top]

[»] What is this all about?
by Joris van der Hoeven - Oct 14th 2001 00:08:28

I personally do not recognize much of the above complaints. When I ask something as a user, I get a correct reply in 80% of the cases. Email I get from users of my software is again reasonable in 80% of the cases, and the user (almost) always gets a polite answer. If you do not believe me, try GNU TeXmacs, give me feedback, and find out yourself.

[reply] [top]

[»] Most of the time, it _IS_ the users fault.
by Paul Mundt - Oct 13th 2001 22:43:58

This isn't meant as a flame, simply as an observation. First off, for every competent user there's an infinite number of incompetent users, and guess which ones are the quickest to complain about "bugs"? As a developer, I often get feedback and bug reports about some application or driver and almost always the bugs are nothing more than the user either refusing to read documentation, or the user not understanding how something works. In my experience, less than 1% of bug reports are real problems at all (at least ones that aren't known about). As an example, I worked on an fb driver for an LCD controller on an embedded board that shipped in 4 different configurations. The controller itself wasn't capable of probing the panel type, and if you had the wrong type, it wouldn't work properly. (there were 4 different types it supported). This was documented over and over and over again.. even in documentation regarding bug reporting things were clearly stated that each configuration should be tried _prior_ to
sending in a bug report, simply to validate that it wasn't a misconfiguration issue. Upon delivering a board with the driver to someone else for testing, not 30 minutes later I recieved notification that the driver was broken, even after everything was outlined to the user. The issue? you guessed it, misconfiguration! And that wasn't the only time either.. I can count numerous other occasions that the same sort of thing happened.. this is not the fault of the developer, as is the first conclusion that the user seems to always jump to, but was in fact an issue of user incompetence, which happens far far more frequently then people like to admit. Often you get users complaining about something and then getting annoyed when your answer to them is simply to RTFM. While I can accept that that's not much of a useful answer, asking for help or complaining about something without even so much as reading documentation is far more aggravating (and reoccuring). Useful bug reports are incredibly valuable in producing a
better product, it's a shame that those are few and far between. Most of the time the user already believes they know what the problem is, and refuse to try anything else.. this does nothing but waste both parties time, and ignoring the user is the most productive thing to do in that situation. Other times, the user isn't competent enough to produce useful information, in which case it can be a large waste of time for both parties involved. (The whole trying to explain quantum physics to a goat thing comes to mind as an analogy). And yet other times, the user refuses to communicate with the developer, and then later on simply demands to know why said bug hasn't been fixed. Perhaps those few competent users out there might care to assist other users in providing useful feedback to developers instead of criticizing developers blindly. It's not like users are being warded off or have to do anything overly complicated to report a bug intelligently, or analyze the problem a little bit before jumping to needless
conclusions. It's just a shame that common sense and reading documentation is like kryptonite to the vast majority of users out there.

[reply] [top]

[»] Re: Most of the time, it _IS_ the users fault.
by Gianni Mariani - Oct 14th 2001 00:25:16


> .... even after everything was
> outlined to the user. The issue? you
> guessed it, misconfiguration! And that
> wasn't the only time either.. I can
> count numerous other occasions that the
> same sort of thing happened.. ....

Umm, I don't know ANYTHING about your product, but this comment smacks of person with blinders on.

Again, grain of salt required because of lack of knowledge about your product. HOWEVER, if I keep on getting users with misconfiguration issues, then **I** (the product designer) have a major problem. Configurations that cause problems must be disallowed, unless the user navigates 3 big fat warnings and then I'd probably also have the product email the customer support department with a warning that if the customer calls to auto reply with a dufus response. I exaggerate, however, the product should be difficult to misconfigure.

[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Paul Mundt - Oct 14th 2001 00:31:21


>
> % .... even after everything was
> % outlined to the user. The issue?
> you
> % guessed it, misconfiguration! And
> that
> % wasn't the only time either.. I
> can
> % count numerous other occasions that
> the
> % same sort of thing happened.. ....
>
>
> Umm, I don't know ANYTHING about your
> product, but this comment smacks of
> person with blinders on.
>
If you had bother reading anything of the above message, you would've realized what the thing in question was and why there were multiple configurations. Since you obviously are incapable of reading, I'll try and spell it out simply for you one more time.. the peice of software in question was a driver for an LCD controller. The controller itself supported multiple types of panels, but doesn't know anything about what's actually hooked up to it.. so there's no way to do probing.. it's up to the user to figure out what type of panel they have, and hand it off as an argument to the driver. It's documented, repeatedly, and not too many people have issues with it. Those that do are typically in the "incompetent user" class. You can whine and bitch about how a product isn't intelligent due to misconfiguration issues, but when that's the only thing that the hardware supports, your options are limited.

[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Gianni Mariani - Oct 14th 2001 00:46:08


>
> %
> % % .... even after everything was
> % % outlined to the user. The issue?
> % you
> % % guessed it, misconfiguration!
> And
> % that
> % % wasn't the only time either.. I
> % can
> % % count numerous other occasions
> that
> % the
> % % same sort of thing happened..
> ....
> %
> %
> % Umm, I don't know ANYTHING about
> your
> % product, but this comment smacks
> of
> % person with blinders on.
> %
>
>
> If you had bother reading anything of
> the above message, you would've realized
> what the thing in question was and why
> there were multiple configurations.
> ....
QED.

You certainly have a problem with the blinders.

Ask yourself this. Is there ANY conceivable way that (even though there are multiple configs) you could avoid misconfigs. Perhaps packaging differently (pre-configured), perhaps automatically detect the configuration, perhaps require no configuration at all.

If your answer is no, then get some help because there is always a way to require less configuration if any configuration is required. It may require work but it *can* be done. If it *should* be done is a different question.

If the answer is yes then discussion is over.

G





[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Noviota - Oct 14th 2001 00:52:31

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.

[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Paul Mundt - Oct 14th 2001 01:13:48


> 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.

[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Chronos Tachyon - Oct 31st 2001 13:34:00


>
> % 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.


[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Paul Mundt - Oct 14th 2001 01:09:38


>
> %
> % %
> % % % .... even after everything was
> % % % outlined to the user. The
> issue?
> % % you
> % % % guessed it, misconfiguration!
> % And
> % % that
> % % % wasn't the only time either..
> I
> % % can
> % % % count numerous other occasions
> % that
> % % the
> % % % same sort of thing happened..
> % ....
> % %
> % %
> % % Umm, I don't know ANYTHING about
> % your
> % % product, but this comment smacks
> % of
> % % person with blinders on.
> % %
> %
> %
> % If you had bother reading anything
> of
> % the above message, you would've
> realized
> % what the thing in question was and
> why
> % there were multiple
> configurations.
> % ....
>
>
> QED.
>
> You certainly have a problem with the
> blinders.
>
> Ask yourself this. Is there ANY
> conceivable way that (even though there
> are multiple configs) you could avoid
> misconfigs. Perhaps packaging
> differently (pre-configured), perhaps
> automatically detect the configuration,
> perhaps require no configuration at
> all.
>
> If your answer is no, then get some
> help because there is always a way to
> require less configuration if any
> configuration is required. It may
> require work but it *can* be done. If it
> *should* be done is a different
> question.
>
> If the answer is yes then discussion
> is over.
>
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.

[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Bitstream - Nov 11th 2001 23:00:44


> 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


--
The first thing a "thinking" computer will ask for is a dumb PC to make some calculations...

[reply] [top]

---

[»] Re: Most of the time, it _IS_ the users fault.
by Bruce Korb - Oct 26th 2001 11:14:04


> 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, ....

[reply] [top]

---

[»] Well, it depends
by Gianni Mariani - Oct 13th 2001 21:34:05

This discussion seems to have become far too generalized. Just a suggestion of a liitle more scope.

If a product will be used by few customers that can be trained and the usage load is small, it may be way too expensive to go messing with the product.

However, if the target user is grandmas and grandpas all over the world, the customer is always right.

In the example given above, about the missing page and all, the lead guy/gal probably needs an adjustment of attitude, however sending the lead's email account a HUGE BMP (okay a lightly compressed jpeg will do) of a snapshot of the missing form will help in the attitude adjustment. In other words, provide the evidence and the response from the developer changes.

The right answer is: it depends.

[reply] [top]

[»] Re: Well, it depends
by Gnea - Oct 14th 2001 00:55:06


>
> This discussion seems to have become
> far too generalized. Just a suggestion
> of a liitle more scope.
>
> If a product will be used by few
> customers that can be trained and the
> usage load is small, it may be way too
> expensive to go messing with the
> product.
>
> However, if the target user is
> grandmas and grandpas all over the
> world, the customer is always right.
>
> In the example given above, about the
> missing page and all, the lead guy/gal
> probably needs an adjustment of
> attitude, however sending the lead's
> email account a HUGE BMP (okay a lightly
> compressed jpeg will do) of a snapshot
> of the missing form will help in the
> attitude adjustment. In other words,
> provide the evidence and the response
> from the developer changes.
>
> The right answer is: it depends.
>
i'll have to go ahead and say that i agree with this
blatantly obvious fact 100% :) as human nature has
dictated, everyone is different - be it a radical or
miniscule difference - it doesn't matter what the
difference is; one can many times find patterns
between the users/customers/tech support/whoever
is having a problem to begin with/etc but one will
never truely know the answer to everything unless
they concede that no matter how many patterns they
pick up (both technologically and socially) that they
should always go in with a shield of some sort that
they should never assume. of course, this isn't a
perfect world but inch by inch....


[reply] [top]

---

[»] Missing a couple of points
by Brie Bruns - Oct 13th 2001 20:21:54

Well, here is one of the major problems I have seen. When was the last time a 'customer' or 'user' for that matter ever told you what they really did or didn't do, rather then telling you what you want to hear?

I do tech support every day I am at work. I spend on average the first 20 minutes of a conversation of a tech support call trying to get the customer to tell me what they really did or what the actual problem is.

Customer: "I cant get my e-mail, it suddenly doesn't work. It has to be your mail server"
Me: "Ok, first, what is the exact error message you are getting and can you browse the web fine?"
Customer: "Why should you need to know the error message, and yes I can browse the web ok, why would I not be able to?"
Me: "Let me ask again, what is the error message exactly as Outlook Express gave you"
Customer: "Oh, it said something about can't connect to the server with a bunch of other weird messages."
Me: "Ok, once again, what is the error message you are getting? Unless you tell me what it is, I can not help you"
Customer: "But you should already know the error message because your mail server is the problem!"

So it goes on for 20 minutes. Then the customer suddenly realizes he forgot to connect to the internet first, and he hadn't even bothered to try to browse the web. Its easy to blame the tech support guy for the problem you are having when in reality, 90% of the time its because of pure stupidity on the customer's part. The exact same stuff happened when I used to do programming.

Users would complain, bitch, and moan about things not working right or things being slow. But yet not one of them would want to help me try to find the problem, nor were they willing to pay me more money so that I could devote more time and possibly find someone else to help out. May it be a programmer, sysadmin, or tech support guy, they are the most under appreicated, and overworked people in the business. They take abuse from everyone else.

Other examples of abuse? A customer bitching because he got an error back from a field which was numerical data only, and he tried entering in text other then numbers. User bitching to a network admin because the user thought he'd mess with device settings under windows 98 and managed to render his system unbootable.

I feel very underappreicated where I work right now. Mostly because I take flak from everyone in our non-tech office on the other side of the island because they think all we do is sit there and twiddle our thumbs all day.

Maybe a little bit of understanding on the part of 'users' and 'customers' would go a long way to improving the attitude of sysadmins, programmers, and tech support people.


A word to managers, business owners, etc (all non-techie people). Next time one of them snaps at you for no apparent reason, think back of how you have treated them in the past. Almost guaranteed a simple "thank you" would make them feel alot more appreicated. I know from experence that the few times a customer calls me back on the phone and says thanks for the help, it makes me feel like the hell I go through is worth it.


My $0.02.

[reply] [top]

[»] Re: Missing a couple of points
by Josh Rollyson - Oct 13th 2001 20:32:57


> Well, here is one of the major problems
> I have seen. When was the last time a
> 'customer' or 'user' for that matter
> ever told you what they really did or
> didn't do, rather then telling you what
> you want to hear?
>
> I do tech support every day I am at
> work. I spend on average the first 20
> minutes of a conversation of a tech
> support call trying to get the customer
> to tell me what they really did or what
> the actual problem is.
>
> Customer: "I cant get my e-mail,
> it suddenly doesn't work. It has to be
> your mail server"
> Me: "Ok, first, what is the exact
> error message you are getting and can
> you browse the web fine?"
> Customer: "Why should you need to
> know the error message, and yes I can
> browse the web ok, why would I not be
> able to?"
> Me: "Let me ask again, what is
> the error message exactly as Outlook
> Express gave you"
> Customer: "Oh, it said something
> about can't connect to the server with a
> bunch of other weird messages."
> Me: "Ok, once again, what is the
> error message you are getting? Unless
> you tell me what it is, I can not help
> you"
> Customer: "But you should already
> know the error message because your mail
> server is the problem!"
>
> So it goes on for 20 minutes. Then
> the customer suddenly realizes he forgot
> to connect to the internet first, and he
> hadn't even bothered to try to browse
> the web. Its easy to blame the tech
> support guy for the problem you are
> having when in reality, 90% of the time
> its because of pure stupidity on the
> customer's part. The exact same stuff
> happened when I used to do
> programming.
>
> Users would complain, bitch, and moan
> about things not working right or things
> being slow. But yet not one of them
> would want to help me try to find the
> problem, nor were they willing to pay me
> more money so that I could devote more
> time and possibly find someone else to
> help out. May it be a programmer,
> sysadmin, or tech support guy, they are
> the most under appreicated, and
> overworked people in the business. They
> take abuse from everyone else.
>
> Other examples of abuse? A customer
> bitching because he got an error back
> from a field which was numerical data
> only, and he tried entering in text
> other then numbers. User bitching to a
> network admin because the user thought
> he'd mess with device settings under
> windows 98 and managed to render his
> system unbootable.
>
> I feel very underappreicated where I
> work right now. Mostly because I take
> flak from everyone in our non-tech
> office on the other side of the island
> because they think all we do is sit
> there and twiddle our thumbs all day.
>
>
> Maybe a little bit of understanding on
> the part of 'users' and 'customers'
> would go a long way to improving the
> attitude of sysadmins, programmers, and
> tech support people.
>
>
> A word to managers, business owners,
> etc (all non-techie people). Next time
> one of them snaps at you for no apparent
> reason, think back of how you have
> treated them in the past. Almost
> guaranteed a simple "thank
> you" would make them feel alot more
> appreicated. I know from experence that
> the few times a customer calls me back
> on the phone and says thanks for the
> help, it makes me feel like the hell I
> go through is worth it.
>
>
> My $0.02.
Agreed. Still, that doesn't excuse a programmer,
technician, support rep, etc from blindly assuming
that a problem is a customer's fault without
so much as trying to verify the complaint or
request more information from the user.

IMHO thats as ALMOST as bad as the user that
refuses to give you all the details.

[reply] [top]

---

[»] Re: Missing a couple of points
by Brie Bruns - Oct 13th 2001 20:48:24


> Agreed. Still, that doesn't excuse a
> programmer,
> technician, support rep, etc from
> blindly assuming
> that a problem is a customer's fault
> without
> so much as trying to verify the
> complaint or
> request more information from the
> user.
>
> IMHO thats as ALMOST as bad as the
> user that
> refuses to give you all the details.
But, as you should know, when the customer tries to avoid a question, it almost always means they are hiding something. Perfect example from a few weeks ago. Customer wouldn't tell me what has been done with his laptop around the time it stopped working. We later find out after forcing his hand that he dropped it.

Good tech support people try to get as much information from people as possible before telling them what is wrong. Its not their fault if the customer refuses to mention that he dropped the laptop, insists that he is connected to the inernet when he isn't, etc. Not being in front of the system that is having problems makes it a requirement that we rely on the customer to tell us what is going on. Most times, what the customer says is going on isn't what truely is.

Just because a customer pays for service doesn't mean they are entitled to attacking and abusing the support people. In the past, at another ISP I worked, we were forced to get rid of several customers due to their abusive habits towards the staff (including one who striked a women I was working with when we went onsite to help them). Unfortunately, they will just move on to abusing some other rep somewhere else and there isn't much that can be done about it.

I know my complaints dont mean much, but I know alot of people out there feel the same way that I do. Maybe, just maybe someday someone who _can_ do something about it will read this and act on it.

[reply] [top]

---

[»] Re: Missing a couple of points
by Josh Rollyson - Oct 13th 2001 21:00:48

A large part of this problem, is that users don't want to be seen as "stupid" by the [support rep|developer|etc]. They try to hide their mistakes so as not to appear to be an idiot, and of course, as we all know, in the end the real story comes out, and the user ends up looking like an even bigger idiot than they would have had they simply told the truth and not tried to hide the real problem. To provide good support, you have to be provided with all the information availible. I sometimes wondered if it might be better to simply advise the customer from the beginning that you know they are leaving something out, and that doing so will waste their time. That said, this still doesn't excuse the developers or support people from assuming every problem is user error and never following up. This does highlight one advantage of email support though. Leaving the details out costs the user MUCH more time than it costs the support rep. Eventually, the user learns to file a good bug report/support request to begin with, and everybody is much happier.

[reply] [top]

---

[»] An Opportunity in Dev V User
by Michael McKinsey - Oct 13th 2001 20:05:15

I am going to throw in my .02 here, because I think a lot of these types of problems in a development situation can be solved by a simple adjustment in the way you look at the situation as developer or user/customer.

As a long time developer of software that is more often used by people who often act on first contact like stupid, impatient, and lazy people than people who act like smart patient people who want to make my life easier, I can offer a point of view that might lead to some happier people in the world.

Person Type #1) When a person acting like a smart, experienced QA minded person (user and customer are defined by their ability to choose someone else, not by what you call them) takes the time to give you a heads up on something you are lucky. They have done you a favour, and you know it, and it is time to fix whatever it is they have found and researched for you.

Person Type #2) However, sometimes a person acting like a stupid, lazy, inexperienced person calls you because they haven't decided making your life easy is as important as making their life easy.

When person #2 calls then you have an opportunity.

Your opportunity is to act more like person number one in their world, than person number two yourself.

As a programmer/developer who is responding to a stupid question, you can do this by taking your time to help them get whatever it is they can't make work to work, and do it because you care that they need to get it done, instead of doing it because you are paid to deal with these stupid morons.

By doing so, you now have made the chances much better that this person, on their next time dealing with you will act more like number one than number two themselves. Even if they can't, due to lack of IQ or an unshakeable attitude incapable of civil human interaction, they will nonetheless try their hardest because you are a decent human being who respects them, their time, and their motivation.

--MMc

--
Michael McKinsey mmc@flashbytedp.com

[reply] [top]

[»] Bad Developers
by Mr. Shiny & New - Oct 13th 2001 18:00:32

I agree with a previous poster who said that the
developers mentioned in this article are not
behaving in a mature, professional manner. While
it's true that for technical support type roles, you
often have to assume that the user is an idiot
(because there are far too many idiots in the
world), the same does not hold for bug reports. If
the user says "I can't do this (because I don't
know how)" it is a totally different story than if the
user says "This doesn't work". As the developer of
a product, your responsibility is to investigate the
user's problems. That's all there is to it... a
developer who doesn't do this is no good at all.
Software is not meant to be written then thrown
away; it is meant to be used by someone. That
user dictates what the software does and how it
works... that is the basic reason why the code is
written.

Furthermore, if the user is an idiot (or is assumed
to be), that does NOT permit the developer or tech
support person to be rude or obnoxious. After all,
the dev/tech support person's JOB is to help the
user, no matter how stupid the user may be.
(Don't get me wrong, not all users are stupid, but
enough are.)

A developer who refuses to acknowledge that a
bug exists without investigating the bug should be
reprimanded or fired. This is similar to a tech
support person who refuses to answer the phone;
investigating and fixing bugs is part of the
development job.

If, as one poster suggested, the developer DOES
answer to bug reports by saying that the problem
can not be replicated, then the user should report
how the bug can be replicated, or at least that it
continues to occur. Then, the developer's job is to
investigate the bug further. If the developer
refuses, he (or she) is again not doing his job.

Not every job is fun all the time; writing code is
lots of fun for some people, while fixing bugs
(especially bugs found by users) is not as much
fun. But it comes with the job; either do the whole
job, or find a different career.

Mark

[reply] [top]

[»] The importance of a good bug-tracking system is paramount
by xant - Oct 13th 2001 14:26:37

Your bug-tracking software should allow you to have a conversation with the customers/users/whatever you feel like calling them. And it should allow your customer to close the bug. It's very simple - the developer never closes a bug. The user does. Let the developer make whatever excuses/ask whatever questions he wants; if the replies are recorded in the bug report for posterity, he won't ask stupid ones. (I know this, being such a developer. The pressure to ask good questions when lots of people are watching the conversation is high.) About half the time (we have a pretty skilled QA department) the questions will flush out a user error. The other half the time the questions will help me reproduce or will hone in on the real problem: for example, a bad UI that suggests the user ought to do it wrongly.

Finally, it's sometimes desirable to give the developer a way to say "hey, I'm done fixing the problem you found" - (but still not close the bug, remember!). In that case, you need an "awaiting testing" status, that IS available to the developer. If the user tests and finds it still broken, he switches it back to open status; otherwise he closes it.

[reply] [top]

[»] Re: The importance of a good bug-tracking system is paramount
by Josh Rollyson - Oct 13th 2001 20:50:44

Except for one thing. There are users that won't play by the "rules" here. They won't close their own bug reports, they won't provide additional information needed to fix the problem, and they will NEVER write good bug reports.

[reply] [top]

---

[»] Re: The importance of a good bug-tracking system is paramount
by Rafael 'Dido' Sevilla - Oct 16th 2001 02:22:35

Well, if they won't play by the rules, then they have no place on the testing team and they should get fired for consistently being such horses asses about it.

[reply] [top]

---

[»] Users == Customers?
by Captain Bozo - Oct 13th 2001 13:33:35

OK, if "users" are "customers", then the other side of the equation is "supplier" or "vendor".

It's a two way street. A relationship. You get what you give.

[reply] [top]

[»] Blamestorming and Bugzilla's and XP
by R P Herrold - Oct 13th 2001 13:30:07

The fun of 'Blamestorming' approaches that of a flame war in an email context -- and there is a time a place for it. But effective escalation -- verbal, email with a file copy, formal tracker, PHB intervention -- all have their place.

The other half of the coin, is that if the proper tools are not in place to report and track defects -- and there is really no excuse, with the various GPL variants available [Bugzilla comes to mind -- it is working for Red Hat and the Mozilla project], the developer is not really serious about supporting their end users.

-- you have to be able escalate both the Substative bugs ("Cannot log in due to the Blocking Requirement for WMF player on a platform for which it has not been released" -- which I just hit trying to listen to a weekend football game on my Linux box), and the Procedural ("Lack of a 'Webmaster Comment' link" -- which prevents me from effectively griping).

And a third half of the coin ('gee, a 3 sided coin') is that a single issue may often be decomposed into several sub-issues -- and with sufficiently small things to fix, an interim workaround fix may be possible, to get you past a Blocking defect -- in the case of that 'Logins do not work', it may have been possible to fall back to an interim .htaccess and un-authenticated-within-the-app userid method, and get to 'testing' the more important parts of the application.

This last is one of the benefits confered by a switch to the XP -- Extreme Programming -- approach with quick and incremental patching of an initially (and always) functional code base. It starts rough, and gets polished.

[reply] [top]

[»] working effectively with programmers requires some skill and sensitivity
by leonH - Oct 13th 2001 12:16:47

1) How do you consider that your relationship with these developers will alter after you have publically expressed your feelings about them in a forum where they are unlikely to feel that they have a comeback. ( What programmer wants to reply to the old comment "anyone but an idiot would .." by sticking up their hand and identifying themselves as that idiot!

2) Programmer- user relationships are shaped over a long period of time. One wonders whether there has been a history of false bugs, programmer bullying, and that you are seeing jadedness on behalf of your programmers.

3) Your comment about "5 years experience with similar applications" flags to me that you may have fallen into the classic hubris that kills many technically skilled people - that great expertise in one area is not instantly transmutable to great expertise in another without effort. Many windows power users actually believe that linux is unfriendly for this reason :)

4) I assume that your programmers are male. I have seen plenty of IT projects fail due to the incapacity of young, skilled, mobile, male programmers to take proper bullying from middle aged management. Sounds a bit like an old bull/young bull issue to me.

5) In general terms, and not related to you in particular, just because a customer/user can define the problem doesn't mean that they can manage or direct the solution. If the spec is "Let there be light" - you would be supprised at how many times some customer will tell you what you need to do. Understanding the problem is not the same as solving it, although it is a necessary first step. This is very irritating to programmers, and other people who have to "do".

6) Not many customers/users are familiar with what I call the "degrees of freedom" problem in programming. That is where extra features requested after the initial spec become progressively harder to add, due to constraints (ie reduction in the degrees of freedom or number of possible options) caused by the programmers solution to the original spec. The classic examples of this are in database programming when some bright spark wants to pull out data which was never entered into the database, but which can be inferred from it with a lot of logic. "But I just want one more field! why has it taken a week?". The programmer has initially taken an approach to solving the problem, and coded in as efficient a way as possible, based on what they think is a complete spec. Of course, most good programmers are partially resistant to this, they get a knack of leaving open as many of their options as possible, and a sense of the kinds of mistakes that customers are likely to make in their initial specification.
Having to throw out a large chunk of work to impliment a tiny feature usually is resisted by most people. Do this to a good programming team more than once or twice, and you may well ruin it. That is, you will lose your capacity to get good work done by that team. This is often a management/specification problem, and particularly manifests itself when there is a committee overseeing the project.

7) Perhaps you are unlucky with these programmers. Perhaps someone in your organisation is more successful in managing them. Maybe you need a middle layer of project management - someone that they and you respect - to manage this.

[reply] [top]

[»] It's always the developers fault.
by hikari - Oct 13th 2001 09:33:27

Unless of course it's your fault for not being psycic and not knowing how they wanted you to use the system, invariably it's the developers fault for:

Not making it blindingly obvious enough (read not enough instructions); not sanity checking submitted data; not stopping you from doing it incorrectly in the first place (as much as is possible); generaly being arrogant and assuming they can't be wrong

When you design interfaces you have to assume that the person using it is as thick as two short planks (I'm not saying all users are, but it's what you assume); then create an interface that that lowest common denominator can use.

[reply] [top]

[»] Re: It's always the developers fault.
by Ian Bicking - Oct 13th 2001 15:45:18

Here here! (or hear hear!...?)

There are very few cases when I get a bug report when it doesn't mean something is wrong -- if it's not a real software bug, then it's an interface bug.

The only exceptions to this is when there's some truly complex process, which simply can't be intuitive, or when fixing the problem involves an investment of time that the company isn't willing to pay for. Typically the latter is because training a finite number of people concerned is considerably faster than making the process more intuitive. Also, documentation is a form of training, and I try to encorporate my documentation directly into the interface... so in the end it's still treated as an interface bug.

I know it doesn't scale, but in these situations I feel I can do a much better job because I do all the code, all the interface, and all the training (of which there's isn't really that much -- I work with smart people, they figure things out pretty well). I suppose this sort of efficiency is why the lone programmer is still a viable means of software production.

[reply] [top]

---

[»] Feh!
by Mr Fiddlehead - Oct 13th 2001 08:19:54

Stop your whinging, you sound as pathetic as the mewling wimps about whom you are complaing. Face it, developers have it worse than anyone else in the company (save for, perhaps, the ones whose duties include cleaning toilets). The barrage of feature requests from above and a similar barrage of requests from the QC people below can make this job a nightmare. A sustained attack from all sides, and rarely a note of encouragement.

Besides, it sounds like you're talking about web developers and classifying most of these people as programmers is like comparing a Boy Scout with a Marine. So there!

Here's another clue, you don't need PH to behave like a PHB, so welcome to the club, your behaviour is exemplary.

[reply] [top]

[»] Tolerance will get us a long way...
by Anders K. Madsen - Oct 13th 2001 09:19:34

At the moment I'm devoloping a bigger webapplication myself, and for that site I have of course had the luck to have some beta-testers/bug-trackers, of course some of them has reported some silly stuff... For instance I got a report that all the forms on the page didn't work, they wouldn't submit...
The problem was that the tester was using Mozilla 0.9.2 and the forms wouldn't submit on [Return]. If you pressed "Submit" with the mouse there was no problem...
My first reply to his report was: "Strange, it seems to work for everyone else.. What browser are you using?"
When he told me he was using Mozilla 0.9.2 I tested with Mozilla 0.9.2...
My next reply was then, it works fine if you [Tab] down to the "Submit"-button and press [Return] or click "Submit" with the mouse...
No big deal...
The report was a bit silly, but of course as a developer I have to think: "Ok, he's a competent/intelligent human being, if he has a problem, there IS a problem.."
It took me about 3 minutes to track the "bug" and "fix" it...
If I had been blaming the tester and told him how stupid he was, then I would probably have lost a valuable "employee", and he would just dislike me. On top of that, It would have taken much more time to think up a "users-fault".
No gain in that...

If you work as a developer and want to publish your work, then you'll be forced to listen to what people say and think about it, if you don't want to hear it then perhaps you should consider if programming is the right thing for you...
I'm trying to build up the best possible programming-environment both for me and my testers, and that work can only be both fun and good if it is done in a friendly and polite environment.

Tolerance
I'd say that tolerance, both ways, are the solution. If it's "one-way-tolerance" then the tolerant part will slowly start to strongly dislike the intolerant part, because of the intolerance, but also because of the tolerance and patience the tolerant part have wasted on the project.

When all is said and done the only result will be that we'll have a developer with no testers...

- Anders K. Madsen

--
Lillesvin Networks

[reply] [top]

---

[»] Re: Feh!
by Linoleum Blownapart - Oct 13th 2001 09:28:05


> Face it, developers
> have it worse than anyone else in the
> company (save for, perhaps, the ones
> whose duties include cleaning toilets).
And with a 'tude like that, I'm sure the people who have it worse off than developers in the company is anyone who has to deal with them. Try adopting a professional attitude rather than one of a martyr. You'll go further.

My reaction to the article was "geez, this guy is working with amateurs." It's called *development* for a reason. It's part of an ongoing process. The job isn't to throw something together, then walk away. It's to develop a tool that will be used by people. Tossing something over the wall blindly is not development.

I've had to deal with a fair number of prima-donna programmers who, almost invariably, were young, inexperienced, and often didn't have the mindset of an engineer. Rather, they were code poets who threw a hissy fit if anyone dared question the artistic integrity of their code. These are the kind of guys who dread code reviews, design documents, user interviews, and anything that could possibly impose order on the general chaos that was their code. They also produced stuff that was unmaintainable and generally got tossed out in favor of something that was written by one of the more senior developers.

The good developers that I have worked with do not expect bug reports to be wrapped with a ribbon and a bow. They see it as the start of a conversation, and a chance to get insight into what the user is thinking when using the software. They actually care whether the user is able to use the software, and if it helps them get the task done. The immature developer's reaction is "hey, my code runs. That's good enough." Whenver a user bothers to fill in a bug report, there's a *reason* for it. Task #1 is to find out what that reason is. For tools being developed for an internal audience, is there any reason not to actually pick up the phone or *gasp* get off your butt and go see the user and see what the problem is (assuming they are nearby). You know... actual human interaction?

Now, granted, if there are a huge number of time constraints, then it can be frustrating to slow down, and talk to a user (or customer, or whatever you call them) about something. In that case, don't take your frustration out against the user... take it out against your manager and the organization. Ask questions about why deadlines do not include enough time to accept and act on user feedback. If your project is getting lots of questions from users on how the product is used (such as the author of the article had regarding whatever web system it was being developed), it's a sign that not enough thought went into the design of the system in the first place. Were the users involved in the design? How can you hope to satisfy the user's needs if they didn't get a chance to tell you what they expect? Your management should be guiding this process. Ask them why they aren't doing their jobs.

If management doesn't listen to those sort of questions then... why do you still work there? You *do* want to take pride in your work, don't you? If your management is going to tie your hands, then just give up and walk. If you've got the skills, you'll be able to find another job.


[reply] [top]

---

[»] You must have crappy programmers.
by MikeFM - Oct 13th 2001 08:07:01

It's usually faster to just check the damn bug than bother denying it. Check every single bug report and if it seems to be nothing put it in your watchlist and see if anyone else notices it too. If you can't make it happen again and neither can your users then it is pretty safe to assume it was user error but it doesn't hurt to keep it in mind for a while.

A lot of times it is the users fault or the browsers fault (some versions of IE are a real pain) but it's your job to check it out and fix it. If the users all seem to be doing the same things wrong maybe you need to do a usability study. If it's the browser you have to learn to work around those errors.

Next time your programmers give you that line send them home and hire me. Sure I'm a total geek and a bum but at least I have some pride in the code I write. :)

[reply] [top]

[»] Re: You must have crappy programmers.
by Gnea - Oct 13th 2001 23:13:39


> A lot of times it is the users fault
> or the browsers fault (some versions of
> IE are a real pain) but it's your job to
> check it out and fix it. If the users
> all seem to be doing the same things
> wrong maybe you need to do a usability
> study. If it's the browser you have to
> learn to work around those errors.
actually, a good majority of the time if the problem
appears to be browser-related, it will fall back to
shoddy web development. everything revolves in a
tree-like fashion at some point or another. if
assumption is what you're after than you probably
make a good ass out of u and me. :) there are so
many angles to which one can do things, and that's
usually dependant upon the work environment itself:
if most people are used to working a certain way that
is generally accepted and sufficient, then perhaps it
should be re-applied to itself in order to extend.
other times it is necessary for a complete restructure.
that can require days/weeks/months of new-hires
and interviews which can further drag things on and
on.


[reply] [top]

---

[»] Re: You must have crappy programmers.
by Samuel Liddicott - Oct 16th 2001 04:43:26


> It's usually faster to just check the
> damn bug than bother denying it.

No, it's not.
Because you don't know about a d*mn bug, only a half baked d*mn bug report.

And you can get many bogus reports from users.

So the choice is not "shall I check THIS bug report", but "do I want to spend all week trying to work out what customers are talking about and then see if each case is a bug". As a developer the answer to the second question is a sound "NO!"


> Check
> every single bug report and if it seems
> to be nothing put it in your watchlist
> and see if anyone else notices it too.

Or better still, hire somebody who likes to do that kind of thing to do it, and get on with what you like doing.

Sam

[reply] [top]

---