February 7, 2015 at 11:10 am
Comments posted to this topic are about the item Programming Rules and 'Best Practices' Can't Replace Professional Judgement
Best wishes,
Phil Factor
February 7, 2015 at 12:12 pm
Much like the story of the mother who tells her daughter to cut the end off the ham, because that's how her mother cooked it, because that's how her mother cooked it, because the ham didn't completely fit in her pan.
Jay Bienvenu | http://bienv.com | http://twitter.com/jbnv
February 8, 2015 at 3:42 am
I agree! Rules (or at least heuristics) are good, so long as the people using them understand why they are there. When they start to be enforced rigidly, especially by people who do not understand why they are there, then problems start. When the environment changes we need to revise the heuristics we use. That means that someone has to be qualified and feel empowered to challenge and revise "the rules". That someone can be an R&D department, a Methods group or just an experienced developer, but they to be allowed to exist in the organisation. If they do not, then "the rules" will progressively get out of step with reality, productivity will drop, the number and severity of mistakes will increase and we will start doing strange things like "chopping the ends off bits of ham".:-D
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
February 8, 2015 at 7:43 am
There was a post in these forums not long ago from a programmer who was new to an environment that had some rigid rules. Some of them actually dangerous (Always use nolock for best performance) and others that were based on "sage advice" for SQL Server 2000 but which are wrong for anything more modern. Grant Fritchey wrote an article about it. Many of these best practices need revisited once in a while and even current best practices don't apply to every situation.
Thanks for a good reminder that "best practices" are guidelines, not the 10 commandments.
February 8, 2015 at 8:28 am
From the article:
It is strange how the gradual repetition of advice that was once guarded, nuanced, and garnished with conditions, transforms it into cast-iron rules.
+1000, Phil.
The notion also applies heavily to the "jump on the bandwagon to use the shiny new toy even if it's easier/faster/has more performance to do an older way" effect that occurs every so often.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 9, 2015 at 4:17 am
I have written, in part or totally, a few programming standards documents. I have read many more. My favoured format is to describe them as guidelines, explain that deviation is allowed but needs explaining and that each guideline documents not on what the guideline is but also why and what its provenance is.
Guidelines should be periodically reviewed by the whole team to allow for people of various experience and backgrounds to bring new (to the guidelines) perspectives.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 9, 2015 at 6:02 am
A hearty amen to this article and I would add I don't see it as something limited to IT management.
I've never been one to follow a supposed "best practice" unless and until I understand it. The flip side of course is that while I may use something sub-optimal even in production, at the same time I strive to learn and understand "best practices" and implement them when appropriate as my knowledge and confidence grows. I work in an environment where I have a LOT of latitude being effectively the only developer. Plus the scale of our systems is small. Were I working in a multi-developer shop developing for solutions that process hundreds of thousands or millions of rows at a time, my approach wouldn't fly and rightly so. But in those environments I would expect a fair amount of mentoring to be happening.
Not too long ago I was reading up on design patterns related to moving data back and forth from databases to client applications. Hokey, smokey Bullwinkle I kept thinking to myself "There is no god but Fowler, et. al. and so-and-so is his prophet." There were reasoned articles that explained a given pattern, it's pros and cons and how to go about successfully implementing it. Far too many others were little more than "Implementing X violates Commandment Three of the Sacred Principles of OO!! Repent O Ye Who Have Sinned!!" screeds.
Rules and standards aren't bad, but it is all too easy to use them as a substitute for thinking.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
February 9, 2015 at 6:54 am
I'd go between the idea of guidelines and best practices, with the notion of recommended practices, and giving the downsides of what ever you are adopting in a clear way.
February 9, 2015 at 7:06 am
To my eyes (and it's just my opinion) it's a lack of willingness to understand what's going on under the hood. (and this apply for everything in this world not just SQL Server)
Only a very few ones have care enough to understand when to use each tools and for them, leaving them the right of "judgement" is appropriate. It's without a doubt those persons were also doing the same thing in the other aspects of their live which make them outstanding not just in their job but as an individual.
For very very (did I say very?) majority of those I've worked with doesn't want to learn / doesn't care when they should. They need a recipe so they can free their mind of learning (and stay at lower level in the hierarchy, assuming we aren't dealing with the Dilbert principle)
So to answer your question, Yes I do give "rules" for them (ex: always uses temp tables instead of variable tables). I'm 100% aware of the consequences but I knows 2 things:
- Most of them will never learn why (remember some learned from me so I'm always open to explain things when asked)
- Most of the time, applying everything at their appropriate level aren't in line with the project objectives, therefore aren't mandatory to bother with (for instance: a low OLTP database)
My last point my hurt some people but we're there to support business operations not the way around. If the need arise to change temp table to variable ones because it became *the* bottleneck, you bet a lot of other stuff would already have been done by then.
My best helper? : "Why".
"Why is it working that way?", "Why Best Practices", "Why is there rules" hence my answers.
IMO
February 9, 2015 at 7:26 am
I believe that my position agrees with Megistal's. For clarity, when I said "deviation is allowed but needs explaining" I should have said "deviation is allowed but needs justifying"!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 10, 2015 at 5:41 am
I couldn't agree more. I consider them guidelines, not mandates. If enough people say something enough times, it seems that they get automatically elevated to a best practice, no matter how true they are.
February 10, 2015 at 10:47 am
This reminds me of a manager I had many years ago who had "rules of thumb" for just about everything. One day we were having a discussion and something I suggested we do didn't agree with one of his rules. After explaining my position, I finished with "...besides, you don't want a DBA who's all thumbs do you?" 😉 at which point he chuckled and agreed my proposal was fine for that instance.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply