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."
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.
-
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.
That is pretty funny. It sounds like that particular designer had a very well developed sense of ego?
-
That is pretty funny. It sounds like that particular designer had a very well developed sense of ego?
I think frustrated. He had been hired to design a system similar to another system he had a hand in creating, but after a while the mind numbing bureaucracy of the place took hold and he needed the buy in of the other managers before anything could be added. Since witch hunting was the favorite sport at that company, nobody but nobody was going to sign off on any changes except to fix bugs.
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.
-
I think frustrated. He had been hired to design a system similar to another system he had a hand in creating, but after a while the mind numbing bureaucracy of the place took hold and he needed the buy in of the other managers before anything could be added. Since witch hunting was the favorite sport at that company, nobody but nobody was going to sign off on any changes except to fix bugs.
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.
Ouch, so it seems like when there are systemic problems within a company or a relationship, the bug list becomes a catch-all. Witch hunting is a terrible practice, hopefully most modern companies are more concerned with fixing the problems than with fixing the blame.
-
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.
The agile thing only works if your customer trusts you; trusts that you are doing a good job for them, and is willing to pay you for the time you put on the project. I gotta say, it takes a very enlightened customer, and generally a customer that already knows you, to go for that. If the customer doesn't trust you, all you've got is specs. It's not optimal, but it's not horrible either. You just gotta grind through it, like the whole rest of the process.
-
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 am sadly used to 'bug reports' based on correctly issued error messages that indicate a user or hardware error - apparently some users equate all error messages to software bugs ... :doh:
-
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."
It’s not always “users” that compile “bug lists”. If it’s another IT type that compiled the list, they refer to it as a “bug list” because they are trying to score points at your expense; otherwise, more often than not, it is a list of “change requests”. (Contracting 101).
-
Yes. The day you'll move to management ;)
Countered the one vote, not sure why that one had to happen. That's pretty funny stuff if you ask me.