If you are a developer, and you work with databases, chances are that at some point in your career you will encounter the animal known as the Production DBA. This creature exists solely to slow down your important work with needless questions, standards, rules, and regulation. S/he is often stubborn, rude, and highly opinionated. However, like it or not, you have to deal with them if you want to get your work deployed.
I can speak from both sides of the equation here. I began my career working with SQL Server as a DBA, and believe me, we ruled by fear and intimidation. This ruthless nature was born of the benevolent desire to keep our systems healthy and operating smoothly, so that our customers could use our services without interruption. If we came off as stand-offish or unwilling to compromise, it was because our methods and rules had been battle hardened and tested, and we were very comfortable operating within them.
More recently in my career I've come from the perspective of a database developer. I have work I need to get done, and some times those (seemingly reasonable at the time) standards are a real pain to work through. There are also times when I think that I've found a better way than what is allowed, and so I would like to bring this option to the table for consideration.
Because I've come from both directions, I have developed a good sense for the right and wrong ways to go about these delicate conversations. If done in the proper style, you'll find that the discussions occur in a more civil fashion, and you'll likely get your desired result more often. Over time you may even build up a good rapport with your DBA, to the point where they even let you slip things through without jumping through all the hoops (believe me, as a DBA I definitely let the nice people get away with more than the not so nice ones).
Without further ado, here are the five rules for successful conversations with DBAs:
Rule number one: Back up your arguments with data
When you go to your (not-so) friendly neighborhood DBA, and you are going to ask them to allow you to do something in a different way than what they usually allow, come prepared to defend your case with strong, quantitative evidence.
Example: a developer wanted to use an index on a computed column in place of an existing rule we had around using a BETWEEN statement when comparing date-times (that's a whole interesting discussion of itself, but I digress). When s/he sent this request along, all they included was a vague statement about "in [their] experience" computed columns performed better, along with an example using around ten thousand rows. The main argument they pointed to was that the estimated cost of the plan for the computed column was much lower.
Needless to say we shot that one down quickly, requesting more useful data such as STATISTICS IO and CPU ticks. In the end the data did not support their solution, and we could have avoided a lot of back-and-forth chatter if they had come with more useful numbers (or better yet, if they had asked us which specific metrics we would want).
Rule number two: Don't include the world in your communications
Several times as a DBA I received e-mails from developers complaining about how our rules were too strong, or insisting we were wrong in one or more of our assertions. Now, most DBAs have very little tolerance for whining, and don't like to be told "you're wrong" in general (yes, I know, we should have thicker skins, but we don't), so those messages got me annoyed as soon as I started reading them. But what really got me mad was when these developers would include half of upper management, including my boss, in their communications.
Understand this: DBAs, especially the good ones, are very prideful folks. Challenging them openly and in public is liable to be met with an equally hostile response lobbed back at you. At best you've now angered the very person you need on your side; at the worst, your argument will get mercilessly picked apart and you will end up looking like an idiot (and I do mean mercilessly - the DBA is a vicious animal when attacked).
Instead, let me offer you this advice taken from one of those management classes I got put through when I worked in retail: compliment in public, but criticize in private. If you are going to argue that something a DBA said or a rule they implemented is wrong, do yourself a favor and do it quietly and in a one-on-one communication. And please, don't insult them or use belittling language.
Rule number three: Don't argue endlessly
I once had an e-mail argument with a developer that spanned the course of a full day and was over twenty messages long (the only reason I didn't talk to them directly is that the individual was in a different country). This experience truly left a sour taste in my mouth, because no matter what I said, even after we agreed that his original assertion was wrong, he kept throwing statements like "But I must point out an error in your thinking" at me.
Listen, I know that everyone likes to have the last word in an argument, and you may believe incredibly strongly in your position. But like it or not, the DBA is the gatekeeper, and in most cases they have the final say in what does or does not get to be released in their systems. Additionally, they are often very busy and have multiple demands on their time. Waging a war of attrition for the sake of your pride or saving face in front of your boss (because your were foolish and copied everyone, didn't you?) is going to do nothing but get you put squarely on the "hard to work with" list.
Rule number four: Collaborate
At their heart, most good DBAs are geeks and love to tinker. Many have probably spent hours playing around with SQL in labs, reading up on new features or functions, and building their own solutions to common problems. Knowing this, you can use it to your advantage.
Instead of coming to the DBA and saying "You're wrong about this", ask them for help in investigating the problem. Send them an e-mail saying "Hey, I could really use your help looking at this. I'm seeing some things that don't make sense, can you work with me?" By taking this approach you are accomplishing two things: first, you are avoiding directly challenging them (yes, I know, we (DBAs) need to stop being such sensitive things, but we won't, so move on). Second, you are appealing to their curiosity and desire for learning. Chances are, so long as they can find some free time, they will want to poke around with you. In the end, even if your hypothesis is proven wrong, you have established that you are a team player and only want to figure out the best solution, regardless of who came up with it.
Rule number five: Remember what they are paid for
Once when I was interviewing a candidate for a SQL developer position, I almost instantly knew he was someone I'd like to work with after a single question.
Me: "So, what is my role as a DBA, and how does it relate to your role as a developer?"
Them: "Simple, you're here to protect the data. Period. If I try and do something that puts the enterprise's data at risk, that means it's your job to stop me."
DBAs live by this rule. It is what they are paid to do, and the good ones take it extremely seriously. When they are faced with conflicting priorities (business deadlines, market deliverables, called in favors), this one will always win out. They will not care who is standing at their desk, or what executive wants this done, or how much beer you try and bribe them with (but that last one sure would be a good way to get on a DBA's good side); if you put the organization's data at risk, expect the gloves to come off. The sooner you realize this fact, acknowledge it, and work with it, the better off you will be.
How can you get around this Great Wall sized obstruction? Simple: prove (again, quantitatively, please no meaningless stories about experience) beyond a doubt that what you are going to do doesn't put the data in jeopardy. You want to use some dynamic SQL within your code to enable flexible searching? Great, sit with the DBA and show them how you are handling SQL injection attempts, using parameterized queries to avoid plan cache bloat, and limiting the size of result sets.
The Wrap Up
Am I saying that by following these rules, all your interactions with your neighborhood DBA will be smooth and pleasant? Certainly not! By their very nature, the interactions between a DBA and a developer are bound to be contentious, and you will bang heads with them on more than one occasion. As I said, the goal is not complete peace and harmony, but merely a respectful and cooperative relationship, where you are both able to get your work done without compromising your principles (much). That way, the organization wins out, and that should always be the goal on both sides of the equation.
