Comments on: ‘process’ rather than ‘quality’ http://www.magpiebrain.com/blog/2006/06/26/why-talking-about-process-is-more-important-than-talking-about-quality/ Sam Newman's blog Fri, 08 Aug 2008 18:39:57 +0000 http://wordpress.org/?v=2.5.1 By: Richard Jonas http://www.magpiebrain.com/blog/2006/06/26/why-talking-about-process-is-more-important-than-talking-about-quality/#comment-1822 Richard Jonas Tue, 27 Jun 2006 15:02:12 +0000 http://www.magpiebrain.com/blog/2006/06/26/why-talking-about-process-is-more-important-than-talking-about-quality/#comment-1822 Thanks for clarifying this Sam. I had thought of "quality" slightly differently, being defined by questions like the following: "do we make sure this web site runs in an obscure web browser that 0.05% of people use?" "do we ensure all the dialog boxes in the application have buttons that are the same size and neatly aligned?" "does it matter if the application fails in the unlikely event that 5000 people use it at the same time when it is usually used by 50?" The answers to these questions will depend on the people using your application. For an application used by a small number of technical people, having buttons neatly aligned might not be necessary and the development time would be better spent adding an extra feature. I agree that changing the process can improve quality without compromising the other variables. If our process includes checks to ensure everyone uses standard features of HTML, then our application will work in our obscure browser. If our process uses standard templates to build dialog boxes, then the buttons might be neatly aligned. If our process insists on good exception handling, our database might be able to fail gracefully and recover under a high load. Changing the process can also increase the amount that is in scope, reduce development times, reduce the numbers of people necessary and reduce risk. Thanks for clarifying this Sam.

I had thought of “quality” slightly differently, being defined by questions like the following:

“do we make sure this web site runs in an obscure web browser that 0.05% of people use?”

“do we ensure all the dialog boxes in the application have buttons that are the same size and neatly aligned?”

“does it matter if the application fails in the unlikely event that 5000 people use it at the same time when it is usually used by 50?”

The answers to these questions will depend on the people using your application. For an application used by a small number of technical people, having buttons neatly aligned might not be necessary and the development time would be better spent adding an extra feature.

I agree that changing the process can improve quality without compromising the other variables. If our process includes checks to ensure everyone uses standard features of HTML, then our application will work in our obscure browser. If our process uses standard templates to build dialog boxes, then the buttons might be neatly aligned. If our process insists on good exception handling, our database might be able to fail gracefully and recover under a high load. Changing the process can also increase the amount that is in scope, reduce development times, reduce the numbers of people necessary and reduce risk.

]]>