Wednesday, November 18, 2015

The problem with "Best Practice"

I love having technical arguments.  I call them technical dialectics.  The process of weighing competing implementations, discussing their advantages and disadvantages is what makes a good technical team great.  At least until THAT PHRASE comes up, alone, without further cause. The typical usage is something like

"We should do X, it's a 'best practice'".

As if there is a council of software engineering that sits on high, prescribing the universally correct ways of development regardless of the environment.

Software engineering has no "one size fits all" set of practices, or even single practice for that matter.  What makes a "best practice" is a practice's fitness given the type of work and environment it will be used in.  When a practice provides more value than it's cost within a particular context, then it is a "best practice".

The valuation process cannot be done in absentia of the environment.  That means a team should be able to, not only justify, but know the value of each practice within their current context.  They should also feel free to remove the practice should a change in context ever make the practice more costly than valuable.

Do the analysis and assign value to determine worth.  If the analysis is bypassed, and "best practice" is the only justification used, well, it's worse than worthless.  It detracts from a reasoned argument by it's glaring absence of reason.