If a customer tells you that they are not interested in software quality, that they have a specific scope that must be completed by a specific date - what do you do? Do you listen to the customer and compromise quality? (By the way, what is quality?)
Simon Baker asks should you always do what the customer wants?
If the customer says he doesn't want "perfect code", he's happy to take low quality code as long it does what he wants it to do, what do you do? We're here to deliver what the customer wants, right. So, do you cut corners on quality? I wouldn't. I'd want to understand the customer's thinking and if it turns out that it's short-term thinking ("I want the cheapest solution so I don't care about quality"), or it's ignorance or plain old stupidity, I'd walk away. My conscience wouldn't permit me to compromise the quality of my work.
And, on the ScrumDevelopment Yahoo! Group a related discussion has been taking place discussing whether or not "quality" should be non-negotiable. The discussion started with a question from Pierre Mengal:
I'm facing a case where the customer don't care about the quality because for him, this is a waste of time. They have firm deadline, not extensible resources and can't reduce scope. They are willing to rewrite completely the application few months after the release if they really have too. This is definitely not a problem of development cost at all (they can loose millions by not releasing the day of the deadline).
Esther Derby responded with a query:
I am curious about the statement “quality is not negotiable.”
Quality is not an absolute term and *must* be negotiated to reach a shared, specific definition. For me, it’s more helpful to say that “I won’t sacrifice the negotiated level of quality.”
Jerry Weinberg has said “quality is value to some person.” The task is to find out where that value lies.
You might take a look at Jerry’s Quality Software Management series.
Also Kathy Iberle wrote a nice paper “They Don’t Care about Quality” which addresses “quality” within different business contexts here: http://www.kiberle.com/2003/STAREast2003.pdf
Lance Walton pinged in suggesting that we don't have a firm definition for quality:
A very obvious problem here is that 'quality' is a poorly defined term. What if, for example, 'release something even in [sic] poor quality' actually meant releasing something that crashed every time a user tried to save their work (it might make a difference if the work was actually saved before the crash, I suppose). Or what about if it
meant every keystroke took 10 seconds to process. Would these be acceptable under the 'release something even in [sic] poor quality' banner?
Alistair Cockburn gave an illustrating example:
I just visited a company (A) whose software is selling more than their
competitor's (B), enough to be driving B defunct. The person I was
talking to said that B's product performed more functions, faster and
with fewer bugs than A's did, but B hadn't created an in-field expert
support organization, as A had.From their customers' perspective, product A had "higher quality" than
product B. Customers bought product A and not product B.Simply avoiding bugs and writing maintainable code does not yet deliver quality. Someone still has to buy it. Deciding to buy it is the
indicator of "what counts as quality".There are uncountably finite number of dimensions to "quality", and
much negotiating to be done over which dimensions rank in which order, and much of each is needed. When you go out of business, saying "bug-free and maintainable" doesn't count for much.
Another way to look at quality was discussed in Ken Schwaber's presentation Agile Quality: A Canary in a Coal Mine which suggests that code quality should be taken as a corporate asset.
So, should we listen to the customers when they say they don't care about quality? Should we do what they ask blindly or ignore them because we know better? Or, is there another way? What conversations should we be having with our customers to build the best software?