Perfectionists are sadomasochists. They are masochists, because they rarely reach perfection, and can’t maintain it for more than an instant when they do. So they are continually frustrated, in addition to being obsessed. And they are sadists, because they drive everyone around them to pursue the same silly goals that they obsess over.
Perfection is an Asymptote
There is a certain level of quality – call it “good enough” – where you should stop polishing. This isn’t an ethical or psychological consideration, but a financial matter. Generally, perfection is an asymptote to the quality / cost curve, meaning the next unit of cost gives you an ever smaller improvement, and you can never achieve absolute perfection. Those who keep struggling for incremental improvements beyond that quality goal are simply wasting resources, especially time.
This is not to say that high quality standards are counterproductive. Indeed, our economy is dependent on the reliability of everything from aircraft to the water supply. However, not everything is defined by a life-or-death quality dichotomy.
Expressing Software Quality
A quality standard should set the context for quality and define achievable success. Software quality for business applications can be discussed in three dimensions:
- Fitness for purpose, meaning compliance with functional requirements
- Fitness for use, which refers to relative ease of use and performance consistency
- Compliance with non-functional requirements, which might include everything from maintainability to robustness to auditability
These three dimensions can serve as a context for quality. Now let’s consider ways to express achievable success for each of them, with these simple examples:
Fitness for purpose: Validate that there are no missing capabilities or behaviors, as described in the functional requirements. Verify that for all expected scenarios, all results are correct [not that all possible permutations have been exercised]. Ensure that invalid scenarios and requests are trapped and can be properly resolved, without support team intervention.
This description includes both constraints and goals and considers both the expected and the unexpected. Of course, we want to ensure that the unexpected won’t be allowed to undermine the system, but this wording clearly shows the dominance of positive testing. The point is to provide goals, rather than methods, to guide both the designers and the testers.
Fitness for use: Confirm that the user perceives the system as consistent, and that navigation is clear for each critical capability. Average response time to a user action must not exceed three seconds. Ensure that the user is always certain whether the system is taking action, or waiting for an action.
This description would require more detail, specific to the system and the users. Again, provide clear goals for designers and testers.
Non-functional requirements: Confirm that the system is auditable, to the satisfaction of the auditors and CISO team. Ensure that the system is maintainable, to the satisfaction of the operations maintenance team.
The key here is to link each non-functional requirement to an authority responsible for acceptance.
Achieving Quality Goals
The point of defining quality is to be able to tell when the team has more work to do, and when you’ve reached your goal, so you can all move on. As you flesh out your quality definitions, keep those two uses in mind, as well as how you’ll measure progress. Well-defined, actionable quality goals are one of the primary tools for managing not just quality, but cost and schedule.
For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager