Good Enough Software - Some Psychology
In Good enough software, I proposed having pre-defined sets of 'good enough' standards - different jobs might have different levels of 'good enough' and it might be beneficial to have predefined levels. Recently reading Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy R. Lister, I came across a pertinent chapter to the topic. In it, they talk about the conflicting quality standards of clients, managers and developers - something that both @thecrumb and @aliaspooryorik both touched upon in comments on my previous post. I thought I'd expand on what the authors of Peopleware have to say on the matter.
The chapter starts by touching on the base layer of human instincts, things such as survival, territory, self-esteem and reproduction. Challenges to those instincts always invokes an emotional response.
In the workplace, the base instinct most frequently challenged is self-esteem. As developers, this often manifests itself as being coerced or forced into submitting code that does not meet our own high quality standards. The cumulitive effect of this, if it is the norm within your organisation, is an errosion of self-esteem for the developers - most of us pride ourselves in the quality of our work and working below our own standards is damaging. This in turn leads to less motivated developers and eventually a higher turnover of developers in the company. Production suffers.
Quality vs Productivity
The conclusions that the chapter reach are perhaps not surprising for developers; organisations that encourage builder led quality are more productive.
An important peice of their conclusion was centered around standards that were builder (developer) led. These will most often be higher than clients' expectation of need. As managers, it might pay to, every now and again, pay attention to those grouchy, tinkering developers. As developers, it might pay not to wait for your managers to setup the quality standards that you wish were in place - go ahead and implement your own team standards and show your managers the benefits.
How this relates to 'Good Enough' standards
The phrase "Good Enough" is perhaps an unfortunate one, it seems to suggest "that'll do", as if quality should be the first factor to be dropped given project constraints. This should absolutley not be the case. The important idea behind "Good enough" standards is that not all jobs require, or should indeed have, the same set of standards by which to judge their completion.
I think that the authors of Peopleware would suggest that all these standards should be developer-led and that the minimum standard should be somewhat higher than that which clients (and perhaps managers) would suppose.
Though I've not finished it, I can highly recommend, Peopleware - good reading for developers, even better reading for managers of developers.