You’ll find a lot of people, consultants and peers, liberally dispensing plenty of “best practices” on the Interwebs and in real life. Heck, I’d say that’s pretty much all I do on this blog. But when should you go with the best practice and when should you make your own road?
On occasion in my consulting day job, I get into architectural discussions with clients and other consultants. Because I typically do a lot of business intelligence work, those discussions often have to do with data modelling. My interlocutors are normally well-informed, knowledge-based and to the point, but there’s one thing that invariably happens:
Quoting scripture.
In the field of business intelligence, “scripture” normally means anything written down by Ralph Kimball or Bill Inmon, depending on your choice of religion. In fact, most professions have their own go-to references, but the fundamental concept is the same. Each industry has established best practices founded in the blood and tears of other hard-working professionals such as yourself, but with enviable 20-20 hindsight. In aviation, for instance, there are endless checklists – minute details that you’ll want to check, at the off-chance that a single misplaced circuit breaker could bring your red-eye commute to a fiery end in a remote forest clearing.
Best practices, for lack of a better word, work. Best practices are good.
Best practices are a good thing, and unless you’re on the absolute bleeding edge, building next-gen stuff that has never been done before (in which case, I highly doubt you’d be reading my humble blog), what you’re doing right now has already been done a hundred times.
But when your daily standup derails into an ad-hoc architecture meeting and you’re all throwing around terms like “conformed dimensions” or “semi-additive facts”, you should stop for a few seconds and remember an important core concept that artists and creators have known for centuries: if you understand the rules and you understand your craft, you get to decide when to break the rules.
So take a step back and consider what you’re trying to do. Maybe, just maybe, this industry best practice only applies to an ideal scenario. Maybe your idea is the best one for this particular case, even though it’s contrary to everything you read in The Datawarehouse Toolkit (and even though your enterprise architect guy is having a dramatic seizure).
The very idea that you can question a best practice, that you can reason your way to a good solution that works for you, that you don’t have to accept the words of textbook authors as gospel, is what makes you human. And it’s (hopefully) why they hired you in the first place.
Don’t be a fundamentalist.
So don’t be a proverbial bible thumper when it comes to your work. By all means, use that hard-earned knowledge of others to your benefit, but allow yourself to break some rules when you know you’re right. At the very least, you might have a memorable learning experience.
* unless you’re a rookie – then, please, consult people who have already been burned a thousand times.
** oh, and also, if you’re flying my plane, can we please just keep doing the checklists?