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.Tags: quality
posted by Simon Baker @ permalink
blinklist :
del.icio.us :
digg :
furl :
simpy :
spurl :
reddit
7 Comments:
Unless it's justified short term thinking. An example from your session at XPDay was a project supporting broadcast coverage of the Olympics. It needed to be ready on a hard deadline, and was thrown away afterwards. In that specific case it was acceptable to make some compromises on quality, if the alternative was missing the deadline.
If you compromise on quality, how do you expect to ensure the product you deliver is fit for the intended use ?
The only safe way (as the producer) to do cheaper is to remove the non necessary functionality. Interestingly enough that is exactly what agile methodologies will do for you.
Compromising quality is rarely if ever a coherent or intelligent solution. But whether it is justified depends on the values of the company.
Compromising quality leads to unknown and unpredictable defects. Reducing scope/functionality means you know exactly where the weak points are since they are there by design (which as Denis correctly points out is exactly what this whole "agile" thing is about).
However if organisational values mean that getting a product out of the door at any cost and to hell with the consequences is rated above controlling the risk and generally agreed good management practices then I suppose it can be justified by some extremely wishful thinking.
Now whether we (as developers/team leads/managers) accept this type of madness is up to us. Demand more. Demand better. But if we do accept it then please don't apply the "A" word to the project, because it ain't.
My response these days to customers who ask for second rate software? "OK, but can you specify exactly what bugs you would like where in the software? We could introduce some really serious ones that's what you want....".
Excuse me...I'll just step off this soapbox now.... ;-)
If you can't walk away then you need to get that requirement in writing.
Why is it this kind of discussion always gets this categorical and high level? When asked no customer would say yes to lower quality, no they what something that works. But what works can be made in many different ways. Today every .Net developer tend to create very loosely coupled n-tier architectures, but this might be overkill for smaller projects, and perhaps a 3 tier tight coupled architecture would fit a customers need for time-to-market and flexibillity, that a 5 tier model, with bloated architecture. Both can be made with suitalble quality.
Accepting lower quality basically means that some things might not work. If that's acceptable, I would ask which things don't need to work, and leave them out, using the saved time to develop those things that absolutely need to work with high quality.
The answer is ... it depends. And it depends on business value. I agree with Kerry that there are rare situations where the business value would lead you to sacrifice quality. But this is rare. I like to point to the XP Customer Bill of Rights and mention to the customer that these rights can only be delivered by honouring the the Developer Bill of Rights. And the Developer Bill of Rights has the right to produce quality work at all times. It is only through ongoing quality that the customer can get repeatable high value and the ability to course correct.
Post a Comment
Links to this post:
Create a Link
<< Home