So this client continually puts together a bug list and pushes it at the management. Management sends it to me and find that it is a list of things that 'bug' them (the client) about the software . Is this common for anyone else? I mean, there is usually 1 or 2 items on the list that can be construed as actual 'bugs' as in unintended behaviors or consequences. I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
(Many, many years ago when monitors were text based, and generally green-on-black, I had to work on a a colour VDU for the blind. It had to have colour, and the colours of everything had to be user selectable, for their comfort. And it had to have a Braille output from each text line because they couldn't see the screen at all... )
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
I certainly know what you mean. I get this all the time. On a few occasions I have written applications to perform tasks similar to an older outdated application, basically creating my own version of it. And when my application performs a process differently because it's more efficient than the old, they have told me things like: "Why is it doing this? It's not supposed to do that. That's an error." When in reality, I've done exactly what I have been instructed to do. And I think they feel somewhat less intelligent when they go over me and report it to management, just for management to tell them why it does what it does and why THEY are wrong.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
The word "bug" as it applies to software is a euphemism and as a euphemism, it is open to interpretation depending on the culture that is using it. In sales, the word "bug" is interpreted as "potential loss of sales". In customer service, "bug" is interpreted as "two hours on the phone with the customer helping him configure his software correctly".
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
In most cases the only difference between disappointment and depression is your level of commitment. -- Marc Maron
Happens... unfortunately you just have to learn to deal with it or offer to help them understand how everything works a bit better. People won't always agree with the way you chose to code things, so prepare to be criticized (directly or indirectly).
One of the first projects I worked on professionally had a customer like that - everything was a bug so that they didn't have to pay for it.
In one particularly egregious case, they reported that the code wasn't calculating a value properly. When I investigated, I found that they had changed the rules used to calculate the value, and hadn't bothered to tell anyone. Of course, they expected the software to magically know about this change and adjust the calculation accordingly.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
That of course is a management (your managers) problem.
Businesses often route all customer requests through some sort of filter process often a business analysis, and that person classifies the communications.
If your company doesn't have such a layer then it is your job.
We all have our faults, but the fault that practically defines the software customer is his conviction that "the specification" is "whatever I happen to want at the moment."
Quite a few software customers regard any suggestion that they have a responsibility to the process -- a binding commitment to whatever specification they've agreed to and presented to Engineering -- as a deadly insult. "What do you mean?" they say. "I'm paying you." It occurs to few of them that even the best of us aren't telepaths and can't read the requirements right out of their heads. It occurs to effectively none of them that a change to agreed-upon requirements, once they've been written down and signed off, constitutes a new purchase order, deserving of its own price tag and time-to-delivery.
In part, the problem arises from our ever-increasing speed of production and refinement. We're getting too BLEEP!ing good at this stuff, colleagues. So they importune us with indirect praise of our skills: "It's such a small change for you, and you turn this stuff out so fast! Couldn't you just fold it into the next revision?"
And every time our pride impels us to accede to such a request, we encourage them to do it again. We dig our own graves just...a little...deeper...
(This message is programming you in ways you cannot detect. Be afraid.)
"the specification" is "whatever I happen to want at the moment."
You hit the nail on the head I think.
I once suggested to this particular client that it would be helpful if they would provide more detailed information. I also suggested that when I asked questions that responses were NOT optional. Geez, you would have thought that I was a mortal enemy for a few moments there .
I find it useful, in dealing with clients, to distinguish between bugs, deficiencies, and missing features:
A bug is present when the software doesn't behave as the programmer intended, and usually reflects a programming error. Bugs get fixed asap, and on my dime.
A deficiency is present when the a feature doesn't work as the customer intended, but the programming is correct. These usually result from a failure to communicate what was wanted, usually because I didn't ask the right questions about edge cases or unusual circumstances. These also get fixed promptly, and (usually) on my dime, and they prompt a review of the specifications for possible similar problem areas elsewhere.
Missing features, on the other hand, are generally things that the client wants to add that weren't in the original specification. These (unless trivial) have to be costed out and billed to the client.
If you are straightforward about identifying and handling the first two properly, you are in a good position to make the client take responsibility for the third.