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

The developer / DBA relationship.


A large part of my job involves liaising with developers. I spent the first 8 years of my IT career working as a developer before moving into database administration in 2008. Consequently,  I find this relationship to be one of the easier aspects of my job to manage  - which is the direct opposite of how some DBA’s feel :-) .

I remember receiving advice from DBA’s when I was a developer and thinking that the constraints that they were placing on me were a little rigid, to say the least.

Back then, I had little experience of what a DBA’s job involved and the constraints that were placed upon them by others (such as data custodians).

However, after making my move to the land of the DBA (over to the dark side, as some have termed it), I find myself in an excellent position to manage this relationship, mainly because I can now clearly see situations from both camps and immediately see any conflicting requirements.

I’d just like to say that whether you sit in the developer camp or the DBA camp, you’ll find this relationship a whole lot easier to manage just by making your mind up to be flexible (obviously within the constraints of you role)  and willing to listen clearly to any opposing views from the other camp.

Lets be clear here about what I mean by listening. I am talking about letting the other party speak clearly and explaining their position. Let them finish and only interrupt then if absolutely necessary – maybe to ask them to clarify a point. When you listen to them, make an absolute effort to fully understand all of their concerns and solutions. Listen to them with an open mind and be prepared to accept that their solution – or at least a portion of it – may have clear, valid merit. Make sure that you understand every word they say. I also think that the test of this is that if the other person has explained something so well – and I have fully understood it, then I should be able to go away and explain it just as clearly to somebody else.

When they have finished, ask them questions, maybe run over a few “what if” scenario’s and get clarification on anything that you are unsure of.

Now, lets be clear, about what I most definitely  do not mean.

Do not just let them speak for the sake of appearing polite and ignore pretty much everything they say. This will probably come back to bite you at a later date.

I mean after all, we all like to be listened to, so just extend them the same courtesy that you would expect then to extend to you.

With the right respect for each others roles I think this relationship can be (and should be) one of the strongest in IT.

I’m going to attempt to put out a short developer tip (or even a DBA tip) every so often that has helped me to manage this relationship – and hopefully will help anybody else to do he same.

I’ve use this page as the index page and so will constantly keep it updated.


Posted by Steve Jones on 27 April 2011

Good advice. I've also found that I need to explain any concerns or restrictions I have about design or security in terms of the actual application and potential issues that affect my job. Often if I let developers know why I have rules in place, with specific logic and not just "because I don't want problems", they understand.

It is important to listen to them and address their needs, either by compromising or developing a workaround.

Posted by Martin Catherall on 27 April 2011

yes, good points steve - being transparent definitely goes a long way towards relationship building.

Posted by al_kessler on 2 May 2011

Absolutly, after all the overall goal is the same for both groups, or at least it should be seen that way.  Provide a viable and working application or modification that meets the customer's needs.  Early communication of the goals and discussion of the method(s) used to reach the goals will save time in the long run and should result in a more tightly integrated product.  I have always found that taking the approach of "what can I learn about (fill in the blank)" when dealing with another disciplin or department.  On more than one occasion I have experienced the "lightbulb" moment of understanding how or why something works the way it does.  Keep building bridges.  

Posted by bryanbutler 79109 on 2 May 2011

These are great points.  Keep in mind that the restrictions placed on a developer by the DBA vary in range depending on the size of the organization and if it sits on the New York stock exchange.  Being able to explain where these restrictions come from is critical to the relationship.

Posted by John Summers on 2 May 2011

Good start, I'd love to read more details on specific points. Coming from a background where I design and administrate both databases and applications, from cradle to grave. Small development teams often can't afford a dedicated DBA (or system administrator). Developers in this situation definitely understand the value of a good DBA.

Posted by Melissa.Fischer on 2 May 2011

Great article, and timely since today my manager had a meeting with one of our Java development team to explain some sql standards and why we have them.

Keep posting, I look forward to reading more.

Posted by brian.schallhammer on 3 May 2011

Well said!  Being able to clearly explain your reasoning in return opens the door for feedback that can actually generate a better solution.  So often one does something because it's correct from a single point of view, but turns out to be only one of several correct options, another of which could better serve a broader context.

Posted by Dream Weaver on 3 May 2011

Steve--sometimes even better is to put your concerns in terms of the end users that the developers are also trying to please.

"The users may love the web site you're developing, but if they feel that they can't trust us they won't use it.  And if some rogue employee of ours steals their credit card number they'll sue us.  I have to do my part to build their trust and preserve it. That's why I'm being so stingy about security.  I know it's a pain, but what else can we do?"

Posted by Jeff Moden on 8 May 2011

Good post.

I think the picture for this blog is perfect for the subject.  In order for Developers (front-end or database) and DBA's to get along, they both have to take the proverbial "chips" off of their shoulders and realize that they're all in the same company and working for the same goal... namely, to make the customers (internal or external) happy and that happiness includes (whether the customer knows it or not) protecting the data and the servers.

Leave a Comment

Please register or log in to leave a comment.