Re: The dangers of perfection, and why you should stick with good enough

One of the huge initial proponents of quality was a man named 'Philip Crosby', You can find a quick overview here. One of the toughest tasks in production is quality and defining it. Here is a excellent overview of quality management.

Four Absolutes of Quality Management

Quality is defined as conformance to requirements, not as 'goodness' or 'elegance'.
The system for causing quality is prevention, not appraisal.
The performance standard must be Zero Defects, not "that's close enough".
The measurement of quality is the Price of Nonconformance, not indices.

As far as IT goes, trying to write code to requirements can be tough. You are often working with people who do not understand what type of product they want or how to write requirements. On the other hand, you will have programmers that don't understand enough about the business to fill in the gaps that the rest of the business may know.

Another area that a number people miss No 2, prevention leads to quality not appraisal. What I mean by this is error handling when it comes to getting your data from somewhere else. A good example is when programmers don't use place holders when doing a SQL query, but instead just stick raw values from the client. The result was a number of applications that are vulnerable to SQL injection attacks.

You are correct, Quality is the toughest one, but it is not a developer issue, but a management issue as well. Quality often requires to sit down and do some real work, and to be honest most people are reluctant to do that, especially when they think they can pass that work off onto the programmer because "Their smart, they will figure it out."

Comment on Re: The dangers of perfection, and why you should stick with good enough

Replies are listed 'Best First'.
Re^2: The dangers of perfection, and why you should stick with good enough by chromatic (Archbishop) on Mar 11, 2008 at 18:35 UTC
Quality is defined as conformance to requirements, not as 'goodness' or 'elegance'. Overall, I think that's the right approach. However, I've seen it most often as a conformance to static requirements, which pleases no one. Ultimately quality means "The stakeholders are happy with the results of their investment."	[reply]
Re^3: The dangers of perfection, and why you should stick with good enough by ack (Deacon) on Mar 12, 2008 at 05:35 UTC
I much prefer the "The stakeholders are happy with the results of their investment" definition rather than tying quality to requirements. My experience is that humans seem to be notoriously and consistently bad at producing 'requirements'. 'Good requirements' should completely define the thing to be delivered...but it seems that we are not so insightful or complete in our understanding of what is needed to be able to make it truely 'complete.' There always seems to be 'things forgotten' or 'things misunderstood' by the requirements producers. Hence it seems to be all too frequently that things that exactly match requirements are still not what the stakeholder, as chromatic noted, wanted. Though I have seen too many stakeholders reluctantly/begrudgingly decide (often, it seems to be in the interest of keeping cost and schedule to a minimum) that they're happy enough to go ahead and accept the product. I'd be hard pressed to consider such an outcome as having delivered a 'quality product.' The weak (in my opinion) linkage between 'quality' and 'requirements' is one of the reasons that my teams have so much trouble delivering satisfactory systems even though we've thoroughly tested that every single requirement is proven to work. So we've gone to broader testing to try to ensure that what we've come to call 'essential services' (which are end-to-end functional capabilities/services as defined/requested by the stakeholders...somewhat similar to Use Cases) are provided correctly and consistent with what the stakeholder expects. It is one of the key elements of our movement towards defining 'quality': a stakeholder-expectations-centric strategy. ack Albuquerque, NM	[reply]
Re^4: The dangers of perfection, and why you should stick with good enough by chromatic (Archbishop) on Mar 12, 2008 at 06:16 UTC
My experience is that humans seem to be notoriously and consistently bad at producing 'requirements'. At least up front. Similarly, it's much easier for me to do code review on a patch that exists over a patch not yet written.	[reply]
Re^3: The dangers of perfection, and why you should stick with good enough by Herkum (Parson) on Mar 12, 2008 at 20:44 UTC
A major source of conflict is between usesr who are unable to describe their wants and programmers who unable to understand users needs. While static requirements are not very good, it can create some stability in a project. One position I had, the requirements were literally changing everyday. It was impossible to make any progress because we were always going back and fixing the code we just worked on. Requirements were finally required to be written down as it was the only way developers were able to make any progress. The users still kept changing their requirements, but at least the developers had a fall back point on why things were done a certain way. The moral of the story, "There are some people who cannot figure out what will make themselves happy".	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.