The 'bug' list
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
Tell them insects are not your problem, but you'll be happy to look into any defects they discover. :)
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
If there is a bug I'll fix it. If it is a feature request I tell the customer so and get them to flesh it out first. If it is none of the above I just shoot a WAD at them. In case you're wondering: "Works As Designed" Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
Sasha Laurel wrote:
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.
-
Good points. I mainly think the different interpretations of bug is what is funny. Its also funny how they are trying to skip around what is contractually obligated ;-)
Everyone wants exactly what they need at that very moment... not what they bought... I think it's more a psychological thing than anything else.
-
Oh yes. Remember that the user is not generally as computer literate as they think. Anything the program does that they don't expect (or want) it to is a bug as far as they are concerned. :sigh:
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Specially when the buttons are not "our blue" :doh: :sigh:
Regards. -------- M.D.V. ;) 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.
-
Specially when the buttons are not "our blue" :doh: :sigh:
Regards. -------- M.D.V. ;) 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.
:laugh: Yep. That is important to some people. (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... :doh:)
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
I fully agree with jschell. Clients can be uneducated and unable (or too lazy) to specify what they want. You have to help them formalize things. This is part of the game. More serious is the situation where your management are uneducated ;)
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
Oh my God, yes. Yes, Yes, Yes.
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.)
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
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.
-
Oh my God, yes. Yes, Yes, Yes.
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.)
Quote:
"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 fully agree with jschell. Clients can be uneducated and unable (or too lazy) to specify what they want. You have to help them formalize things. This is part of the game. More serious is the situation where your management are uneducated ;)
You mean to say that some management actually understand the software suites that they are managing? :laugh:
-
You mean to say that some management actually understand the software suites that they are managing? :laugh:
Yes. The day you'll move to management ;)
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
Yes. Every time I roll out a new version of any my software packs, apperently when things look a little different, or has new functionallity, it pops on the bug list X|
-
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.
Nice
Gus Gustafson
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
I learned that we can't tell the clients what they want, despite knowing they are wrong sometimes. In the end they are the ones we have to please even though we can get aggravated on doing something we don't agree. If they are wrong, and the "bugs" are there to better help them with their jobs we gotta give them what they want by "fixing the bugs" and let them bang the head against the wall as long as they are paying for it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Oh my God, yes. Yes, Yes, Yes.
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.)
Fran Porretto wrote:
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...
Spot on. It's like getting caught by quicksand, the more we fight, the deeper we get. I learned not to fight and just give in. It creates a better chance of survival ;)
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
The customer's perception is that bugfixes are free, whereas new features require a lot more overhead and sometimes actual money. So, filing a bug is perceived as a lightweight (and free) process to get a small change into the code. There are some who abuse it though, and I've even run into some I suspect were abusing it intentionally. Aside from those who are intentionally abusing it, keep in mind that the customer only looks at the user interface. They'd never ask for a complete redesign of the UI as a "bugfix", but they wouldn't hesitate to ask for what appears to them to be a small UI change, completely unaware that it might result in a significant amount of work. Changes that have no UI manifestation are perceived as even smaller.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
At the place I used to work at, this one disgruntled "designer" would write up bugs that would later turn out to be features he wanted to install but had been outvoted by the other designers.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
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 :wtf:. 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. :laugh: I usually say "These are requests, not bugs. Spec them out and we'll add them to the backlog."
I wonder if the problem is that you and your customer are in an adversarial relationship over changes. If so, then it is important for you to agree on the definition of "bug" and "change request". If your customer pays for feature changes but not for bug fixes, then your relationship is inherently adversarial. Adversarial contracting relationships are very 20th century. They institutionalize distrust between you and the customer. They don't lead to the best software. When your customer insists on creating an adversarial relationship, and you can't find better customers, you have to have written-down specifications in detail. In addition to being tedious, this prevents you from evolving the design as you work on it. If you don't write everything down and agree to it in advance, then it is completely inevitable that you'll get into arguments over features that work as you expect them to, but don't please the customer.
-
I wonder if the problem is that you and your customer are in an adversarial relationship over changes. If so, then it is important for you to agree on the definition of "bug" and "change request". If your customer pays for feature changes but not for bug fixes, then your relationship is inherently adversarial. Adversarial contracting relationships are very 20th century. They institutionalize distrust between you and the customer. They don't lead to the best software. When your customer insists on creating an adversarial relationship, and you can't find better customers, you have to have written-down specifications in detail. In addition to being tedious, this prevents you from evolving the design as you work on it. If you don't write everything down and agree to it in advance, then it is completely inevitable that you'll get into arguments over features that work as you expect them to, but don't please the customer.
Wow! Well said! I think you understand these types of problems very well. I don't know any specific details about contractual obligations, but it sure does seem like we are pushing towards a very "waterfall" type of adversarial relationship (we've already had to resort to tedious written specs). Hopefully with some new-found resources and some agile practices we can turn this thing around.
