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

Replies are listed 'Best First'.
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.