The third “word I do not use” is best practice.
The “best practice” serves a vital need in any industry. It is the answer to, “Please don’t make me learn about this; just tell me what to do.” The “best practice” is a fine idea in spirit, but here’s the thing: many practices labeled “best” don’t deserve the adjective. They’re often containers for bad advice.
The most common problem with “best practices” is that they’re not parameterized like they should be. A good practice usually depends on something: if this is true, then do that; otherwise, do this other thing. But most “best practices” don’t come with conditions of execution—they often contain no if statements at all. They come disguised as recipes that can save you time, but they often encourage you to skip past thinking about things that you really ought to be thinking about.
Most of my objections to “best practices” go away when the practices being prescribed are actually good. But the ones I see are often not, like the old SQL “avoid full-table scans” advice. Enforcing practices like this yields applications that don’t run as well as they should and developers that don’t learn the things they should. Practices like “Measure the efficiency of your SQL at every phase of the software life cycle,” are actually “best”-worthy, but alas, they’re less popular because they sound like real work.
6 comments:
... any it probably annoys your sense of being unprovable as literally best, even if something is a useful starting point. At best, a practice can only be the best we have tried so far.
@mark, yes, well put.
And even some "pretty good" practices need to be re-examined regularly. A few years ago, I came back to work for a client for whom I had written some database naming and other standards about 10 years earlier. I was going to design them a new application database. I was handed a document and told "these are our naming standards that you need to follow." The document was VERY familiar - it was the same document I had written 10 years before with only a few changes since then.
I was flattered that something I'd written had survived the years - most of what we do in IT is obsolete only months later. Still, that document deserved to be obsolete. Much of what I'd written was fine for Oracle 7 - which is what we were using then, but some of it was actually WORST practices for Oracle 10g and 11g.
"Best Practices" is a comforting blanket to people who are tasked with developing systems using technology with which they are not-yet-sufficiently experienced.
Developers are much less likely to get into trouble with their superiors if they follow "BP"; importantly, they are almost certain to get into trouble if they decide to ignore the published "BP" and their system fails to meet expectations. Whether or not this failure was actually caused by their non-adherence to "BP" might not even be a factor in their excoriation.
As a result, it is natural to expect the general tendency will be to follow "Best Practices", even if the developer has an inkling that maybe they should not apply to their particular situation.
What makes things worse, IMHO, is the common practice of incorporating "Best Practice" directives with Development Standards documents. In such places you need the support of a senior developer who understands the constraints and reasoning behind the directives, who can then overrule them when it makes sense.
I'm sure you'll have read it but I like what James Morle said here a while back: http://www.jamesmorle.com/right-practice/
@Jeff, yes, I had seen that post. Thank you for the impetus to read it again.
Post a Comment