SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Being Right, the Other Side

I read an excellent article by Camille Fournier about the importance of recognizing that being right is not the only factor that needs to be taken into consideration when making a decision. You could even change it from “being” right to “doing” right. Although, I mean it in a technical sense, not a moral one.

If you haven’t read it already, go ahead, I’ll wait…

I agree with her.

I’ve been that guy… more than once…. okay, okay, a bunch of times. You know that guy. The one who just couldn’t see past the point that we were doing something wrong, something stupid, something that would bite us in the butt for the next three or four years. Oh yeah, that guy. The popular one (not at all). The one the that causes the to boss starts to cringe whenever that guy heads towards the office. Been there, done that, have the embossed external hard drive.

Now… over the last several years, I’ve made an honest and sincere effort to not be that guy. I’ve tried pointing out the flaws, making my arguments, and then, if they get shot down, lose quietly & gracefully. Sometimes I’ve been successful. Other times not so much (times 100). I usually gaged how successful I was by how angry one member of my team, who never compromised, became.

The only thing is, well, sometimes, that guy (or gal), is 100% correct.

Not only that, but the boss/program team/consultant/whoever on the other side of, what to mean seems a silly argument, ready to toss common sense out the window in order to deliver software faster (because it always seems to come down to how fast we deliver the software) is 100% wrong. Not only are they wrong, but they’re destructively wrong. Project wrecking wrong. I’ve seen it happen, multiple times. That’s why those of us who do tend to act like that over-wrought freak-out queen put on our performance. I know we’re crazy to thins it’s a really bad idea to throw out relational integrity, stop designing databases for optimal storage, rely on the app for all integrity checks, use an ORM tool as an OOM tool, skip testing for deployments, stop maintenance routines and monitoring, or just flat out ignore the laws of physics. We’ve seen the projects fail because we understand how things work. We just can’t always explain that understanding to others.

So the real key here is that you have to split this hair mighty fine. Yeah, giving up on some processes, some best practices, in some situations, that really can make all the difference in getting software out the door faster & more efficiently. No question. But, those same compromises can lead to absolute failure. Management has to be able to listen to weed out the best practice complaints from the technically unsound complaints. And we geeks have got to stop having the vapors every time a developer proposes making a change to the system or a process. Otherwise, we won’t be listened to when it really counts, like the Boy Who Cried “Wolf!”

The Scary DBA

I have twenty+ years experience in IT. That time was spent in technical support, development and database administration. I work forRed Gate Software as a Product Evangelist. I write articles for publication at SQL Server Central, Simple-Talk, PASS Book Reviews and SQL Server Standard. I have published two books, ”Understanding SQL Server Execution Plans” and “SQL Server 2008 Query Performance Tuning Distilled.” I’m one of the founding officers of the Southern New England SQL Server Users Group and its current president. I also work on part-time, short-term, off-site consulting contracts. In 2009 and 2010 I was awarded as a Microsoft SQL Server MVP. In the past I’ve been called rough, intimidating and scary. To which I usually reply, “Good.” You can contact me through grant -at- scarydba dot kom (unobfuscate as necessary).


Leave a comment on the original post [www.scarydba.com, opens in a new window]

Loading comments...