Software Development Best Practices: Enabling or Stifling?

It seems that the arguments for and against best practices and standardised ways of writing code will never cease. But what motivates people to be strongly against or vehemently in favour of best practices?

• Fear and distrust are big issues, and it's no surprise that people fear losing control over what they see as a creative process to best practices, boiler plate code or standardised working practices. The way in which arguments for best practices are presented may affect whether they are perceived as a threat or not.
• Understanding is another key area here: differences in people's perceptions of what constitutes "best practice" or "coding standard" will undoubtedly lead to differences in levels of acceptance. Inconsistency between perceived requirements and constraints imposed by best practices and the other pressures present in writing good, solid software are a close cousin to understanding (or misunderstanding) standards and best practices.
• Finally, personality is an unfortunately big part of this: developers are extremely independent thinkers (which is no bad thing) with strong independent personalities to match. Ideas such as coding standards and best practices can seem too authoritarian for many, so may be resisted simply because they "feel wrong". Worse, an idea can fail to be adopted by an individual simply because it's put forward by someone they generally disagree with or even personally dislike.

Best practices come in many shapes an sizes (of course depending on opinion), but lets lay out a few along the continuum:

• Low level best practices such as memory management or object storage. For instance "always use boost::shared_ptr rather than a raw pointer" or "avoid using a vector of std::auto_ptr". Such ideas are really rather hard to argue against: the ideas are about avoiding common pitfalls and bugs. Of course there are (rare) situations where we may need to diverge from such rules, but a coding guideline should at the very least make it necessary to justify your decision to do so.
• Next come mid level ideas such as common pattern usage. For instance a standardised way (or a couple of ways) to do Observer may be recommended. How much you can standardise through generic code, boiler-plate or simply guidelines is language dependent, but it's at this level that divergences in opinion start to form. Observer is a great example, as you don't have to write too much code to find that a generic "Observer with Hint" template might not appear to be enough: you might need two hints, visibility both ways or perhaps two types of observer. The balance that needs to be made at this level is the cost of modification to the code that uses the pattern versus the cost of partial duplication of a new pattern variant. These costs can be in time to code, clarity, maintainability and bug fixing.
• Finally, the largest ideas we might consider putting forward as best practices are architectural paradigms such as "all communication via asynchronous events" or "no database access on the non-GUI thread". Such rules are unlikely to be effective across many projects, but are suggested to be essential ideas in XP in the "System Metaphor".

Lean manufacturing suggests that standard working practices are at the heart of continuous improvement, but those using them must be empowered and motivated to improve them. If developers are in charge of their best practices, then it's less likely that they will be viewed as an authoritarian diktat. In addition, issues of trust and respect becomes potentially less thorny, as the standards are maintained by a group of peers by consensus. Going back to an earlier example, if someone has a real need to diverge from a best practice such as a generic Observer pattern, then the particular problem they are trying to solve should be discussed and the standards amended if needs be. The main point of such an exercise is to inspect and adapt standards and best practices to suit, rather than view them as something fixed.