“Quality” is defined in the Oxford dictionary as, “The standard of something as measured against other things of a similar kind”. This is a tough proposition indeed, how do you measure against something of similar kind when developing a new product? Are there some universal criteria that you try to build into your product, and then measure how well you have executed the development to achieve said criteria? Such a simplistic view would decree that all products achieve the highest degree of “Quality” by following an algorithmic formula. “Quality” is not some component of a cooking recipe that is added to the cooking pot. “Quality” in a software product is an emergent feature that is seen as a whole in the final product. It is difficult to see this final “Quality” in the product during the period execution. One introduces various measures into the product development to achieve that final sense of “Quality”.
We introduce coding standards to make the product maintainable; it enhances our sense of “Quality”, but only one aspect of the “Quality”. No one would claim that this measure by itself is enough to achieve that final sense of “Quality”. It is a small measure that improves the maintainability of the product and it is an endogenous property of the product. It is internal to the product not seen by the end user; its importance becomes apparent during due-diligence. We encourage the use of good design guidelines for the same reason as coding standards. But, unlike coding standards we do not dictate which design patterns to use, as doing so would obviate the freedom of the developers to choose the appropriate pattern as the product goes through various iterations of chaotic changes interspersed by phases of stability. But, once again to claim a sense of “Quality” would be only partially true.
Most of the development practices that are put in place add to our sense of building a “Quality” product. But, we are also fully aware that during the development phases this sense of “Quality” is incomplete. Most of these practices improve the endogenous sense of “Quality”, but the most important contributor to the final sense of “Quality” is exogenous and comes from the user perspective.
The user experience is delivered through a combination of the visual and the functional. If you visit your banks website, and are presented with a site that has all the functionality, but presented in such a fashion that,
- Your eye has to search the page to know what your next action should be
- You are presented with every product option the bank sells, rather than your view being customized for you as a unique customer
- You have to do many-many clicks to achieve your end, even when it is a simple task of transferring funds
- A feature is provided for your use except on attempting to use it you are invited to visit the nearest branch to submit a request for making use of the feature
- Upon attempting to use a feature you are requested to provide information about yourself that is already in the system
We would say that this product is functionally impoverished no matter that this mess is served up in the most visually entertaining way. This product fails in achieving that sense of “Quality” required of a bank website. Even if the score for the endogenous “Quality” were ten for ten, its score for the final “Quality” would be close to zero, since it fails at the customers experience.
This is true for all user experiences, whether it is at a restaurant or at a banks website. If you are served the most appetizing meal, but it looks like a dogs dinner on the plate, it does not encourage eating. The eating out experience is on the wrong footing from the beginning. The obverse is also true, a beautiful serving on a plate belies its looks, and after the first bite you are more likely to push your plate away. In both cases the product has failed to deliver the user experience that differentiates a “Quality” product from one that isn’t.
These are not dissimilar examples, since they point to the same problem, the failure of the product to give a quality experience to the user. Achieving that emergent “Quality” requires more than just,
- Marketing spend to fathom the user needs, in fact whether the product is even wanted
- Roping the user to getting a handle on the product experience during the whole development life-cycle
- Doing wire frames and then trying to gauze the user reaction is not really the answer, the horse has to come before the cart
- Knowing your user base, you would not serve haute cuisine in a family diner or vice-versa for that matter
You have to trigger the “Quality” criteria throughout development the right way, if you want that rare “Quality” to emerge in your product. It is the consequence of the aggregate of all action performed in triggering the “Quality”, and not just only some of them. Focusing on the easy ones (mostly endogenous) and ignoring or minimising the difficult ones (specifically the user perspective, that is exogenous) is a recipe for a failed product.
Does doing all the right things guarantee a product of “Quality”? The answer has to be a no, “doing all the right things” is not a guarantor of “Quality”. It would suggest some of deterministic formula for achieving the final “Quality” badge, but unlike a recipe, software development can only attempt to arrive asymptotically at the ideal “Quality” product approval from the user experience. Even a recipe is not a guarantee for the final product on the plate; it is only a guide and is tempered by the chef and his team. There is a huge dose of subjectivity involved in the user experience, and that is also the reason to have the users involved at every stage of the development. This may not be enough either, since one has to consolidate the views of all the user groups in the chosen decisions for the product. The conclusion when even one these criteria for a “Quality” product is ignored is fully deterministic, you end up with a failed product.