Rigidly adhering to a standard, any standard, without being reasonable and using your ability to think through changing situations and circumstances is itself a bad standard.
I guess I should quickly define what I mean by a “database standard” for those who are not aware. Database standards are common practices and procedures that are documented and implemented to ensure the consistency and effectiveness of the database environment. For example, almost every organization will have a standard for database naming conventions at bare minimum. But usually there are many more database standards for processes such as SQL coding, indexing, ensuring service levels, and so on.
If you happen to be a fan of Monty Python’s Flying Circus, then you probably recognize the line: “None shall pass” in the title of this article. It is the unchanging exclamation of the Black Knight in the movie Monty Python and the Holy Grail. He just stands there trying to block everyone who attempts to go past him—even after a better swordsman has cut off his arms and legs.
I’m sure that some of the application developers reading this can relate to this story, replacing the knight with their “favorite” DBA and recalling valiantly explaining to the DBA why they need to do something or make some change that doesn’t align with some standard or another, only to be told that, “None shall pass.”
For just about every database standard you can think of, I can think of an exception. A good standard should not be a rigid bottleneck to productivity. Instead, a good standard works well most of the time in terms of delivering superior performance, service, availability, or functionality. But sometimes, diverting from that standard can make sense, too. The key is for DBAs to keep an open mind and to be reasonable.
Of course, I do not mean to suggest that just anybody should be allowed to thwart the written standards of the organization whenever he sees fit. Instead, all parties involved should be reasonable and have a valid, business reason for failing to enforce a standard. Or perhaps you should look at it as modifying the standard based on new evidence or an unanticipated situation.
Ideally, every shop should have a “standard” that the database standards should be adhered to unless a compelling argument can be made to subvert the standard. There should be a documented process put in place for challenging a standard that requires a formal, evidence-based proposal for its bypassing or revisal. There should be a committee of relevant IT personnel led by a DBA who reviews each proposal and formally responds with a reasoned response that should fall into one of three buckets: declined, accepted as a one-time exception, or accepted with a revision to the standard.
Sure, that may seem to be a lot of work, but it is better than a rigid environment that makes things too difficult. And it is also better than an environment with few, or no, standards at all. Furthermore, to ensure that only legitimate challenges to standards are submitted, all challenges should require the sign-off of the manager of the development team member requesting the exception. After all, practices and procedures have risen to be standards because they have stood the test of time in most cases, so we don’t want to be reviewing exceptions all that frequently.
The Bottom Line
When going against a standard makes more sense than enforcing it, let’s all agree that it is wiser to make an exception (or to modify the standard). After all, our standards are supposed to be there to make sure we do the right thing. And they normally do … except when they don’t.
A good standard should not be a rigid bottleneck to productivity. Instead, a good standard works well most of the time in terms of delivering superior performance, service, availability, or functionality.
There should be a documented process put in place for challenging a standard that requires a formal, evidence-based proposal for bypassing or revising the standard.
