The definition of quality is that it meets a certain specification. What a bunch of bollocks! I have a Holden Vectra (a rebadged Opel which people say is a very bad brand in its own country, Germany) - it requires more oil (about 1 litre) every 3,000-4,000 kilometer ever since I've bought it. It has only done 30,000 kilometers in 3 years but in that time it's run out of oil 4 times (between services). Now I ring up Holden support and say that this is an unacceptable specification. They say the car is fine, it is within the oil consumption specification.
Quality is excellence and that's not Holden.
Update: So here's a bit more, based on what Matthew wrote in the comments.
So the quality of the specification comes out of a process. And if that process doesn't have "the quality of excellence" in it, at all levels, then you're not achieving quality yet.
One of these aspects to this quality is a sort of self similarity - like well designed code - each bit of code does a small bit and does it in an understandable way and is roughly the same as the other bits - independent of which level of the system you're at.
If you can't raise an "IT Strategy Defect" then your organizational processes (which your lower processes are a part of) lack that aspect of quality. Now maybe that has to come out of high costs, failed projects or whatever.
From the perspective of the software industry, it seems that we've got a much higher expectation on what can be done. There aren't that many industries where the customer, project manager, support, maintenance, engineer, tester, etc. are even able to say (let alone expected or encouraged) "there's something wrong, fix it".
The guy at Holden support says, "I wouldn't buy a car with those specs" and so on - they know it sucks but they can't change it.
Now that isn't to say software should produce the equivalent of bubble domed cars that play "La Cucaracha". I'd like a flying car but at the moment I'd settle for something that doesn't need to be checked every 3,000 km and isn't going to destroy the planet.
1 comment:
Well I guess the quality of the specification is different to the quality of the product.
I run a defect management process that basically says 'anybody who doesn't like something raise a defect'. Some of this is planned testing and some isn't - but it's all considered a quality measure.
It's only after the defect is raised that we decided if it is a specification defect, or a code defect, or a project initiation defect, or the PM's fault, etc...
It's the project's defect (not the developer's) until we decide what/who more specifically is at fault.
If the code is just following the specification then the specification is at fault. If the specification is part of the terms of the contract we change the contract and maybe even classify the defect as a 'contract defect'.
If the contract is wrong because our vendor screwed us then I guess it's a 'supplier relationship defect', or even an 'IT strategy defect' so we might have to change vendors, or strategy, or you maybe should just buy a new car.
What I find really interesting that within IT organisations only the technical work products are subejcted to a defect management process. I've often tried to raise a defect an IT Strategy - but I don't get very far.....
Post a Comment