Robert Nyman wrote recently about the difficulty to get buy-in for accessible web pages. His article speaks to a greater issue however of the difficulty for organisations to address the detail of generating quality. I define quality to mean not only those aspects of a products finish that benefit an end-user but also those that benefit those that support and maintain a product.

The strategic decision makers often talk to short-term benefits as reasons
for taking short-cuts on quality. Sometimes I think the Google Offline Spider’s Archive maybe handy in settling once and for all how the short term thinking had lead to issues such as poor stickiness or excessive bug reports or that high exit rate from page x.

I have had various QA tester and QA Manager roles in my past (it was even my entry into my current company!). From this vantage point it often feels like the last thing anyone wants outside QA is a quality product.

Things aren’t generally that bad - of course once you experience different roles around the workplace you do realise that quality is being achieved despite conflicting incentives. I’ve done in-the-trenches development (I continue to moonlight with this every once in awhile to satisfy my hobby interest and to make sure I maintain a reasonable understanding of the work at hand), content direction and production, marketing and various managerial roles as well.

Developers and content producers generally are striving for quality in the face of deadlines, distractions and the conservative decisions of their managers (spending time on both sides of the fence I acknowledge that sometimes those decisions represent excellent risk management and othertimes fear/laziness of disturbing the status quo). Managers deal with distraction, the competing needs of other managers, the goals of the organisation and that estimating accurately is HARD.

In my post detail versus perspective I had discussed the trap of fiddling with details whilst the truly valuable contribution to the success of your organisation languished. This is not in conflict with achieving quality in your work as often quality (attention to detail, usability, accessibility, reusability, literate code - whatever it is that provides ongoing benefit inside and out of your ogranisation) is that truly valuable contribution.

So how do we all ensure we contribute to an overall environment of quality? There is no way to guarantee it but you can certainly do more than ‘your little bit’. To understand and facilitate others in their efforts to contribute to the quality of the product of your workplace is important. If QA request consideration to their workload and throughput then give it. In fact support any of your domain experts when they are suffering friction from decision makers when trying to address issues within their domain. And evangelize the aspects of quality that are key to your own domain succeeding.

Stumble it!