How to prevent antagonism between DBAs and developers

Question

This seems to be a common pattern in nearly any large organization with lots of IT infrastructure: DBAs and developers are more or less at each other's throats.

The DBAs see the developers as incompetent whippersnappers with no understanding of data integrity and DB performance, who must be prevented from compromising the "database fortress" at all costs. They install procedures to ensure that all DB schemas and code that accesses the DB is double- and triple-checked and as much logic as possible is put into stored procedures written by them, who understand how to Do It Right. "I don't care about your deadline, if you can't justify why those columns are varchar(), they're not going into the production DB".

The developers see the DBAs as lazy roadblocks, coffee-guzzling obstacles to Getting Things Done, with no understanding of real-world problems and looming deadlines. They want to treat the database as just another part of the code that can be refactored as needed, try to circumvent procedures and believe that DBAs are unnecessary when you can just have the O/R-Mapper generate a DB schema and start using it right away. "N+1 query problem? What's that?"

So how can this be avoided? How can you make DBAs and developers understand each other's concerns and work together towards a common goal? Have you seen it done in a large organization? How?

Answer 1

Paintball! Let people shoot each other!

Seriously, the best way is to make everyone feel like they are part of one team.
That way the DBA's understand the priority behind some of the requests, and are more understanding, while the developers should hopefully learn a thing or two about why the DBA's feel the way they do. (Some stories about queries deleting audit trails, or live data should do the trick.)

I've only worked in medium sized teams, where there hasn't really been a seperate DBA team.

Answer 2

Instead of both sides dictating what needs to happen in the others domain, have each side explain what they need and allow the other to implement as they best see fit.

Developer to DBA:

"I need to store the following tidbits of data, and I need to retrieve it to fill this business need."

DBA to Developer:

"Here is the table schema that we have come up with, and here are the efficient and secure ways to get the data"

This works great, and avoids the problem altogether.

Answer 3

Well, by not separating them.

I would consider myself a handicapped programmer if I was unable to freely work with the DB, and I'd be bored as hell if I was restricted to DBA work. The divide is artificial, pull it down.

Answer 4

Don't isolate the DBAs in their own department, add DBAs as needed to development teams and have them work in conjunction with developers on new projects.

In our organization, we have a distinction between "operations" DBAs who work on backups and routine issues, and "project" DBAs who work with the development teams on new applications and deployments.

Answer 5

Accountability and cross-functional teams. In Scrum, both the developer and the dba would be on a cross-functional team that would, as a whole, be responsible for delivering by the deadline.

In that setup, there is no Us vs. Them. Its We and how are we going to meet this deadline.

Answer 6

The problem you describe is of course compounded by the awareness of both opinions by all involved. The developers know what the DBAs think of them, and therefore fire off all requests in the direction of the DBAs with a certain degree of disdain. The best developer-DBA relationships I've ever encountered were when the two groups were colocated and respect was allowed to build up. In organisations I've worked in where the two are geographically separated (and sometimes in wildly different time zones), then this relationship can't build up and resentment ensues if the situation isn't appropriately managed.

So, if you've got developers and DBAs in the same building at least, set up some face-to-face meetings. Regardless of how far apart they are, get developers to engage DBAs early in the development process, to describe to the DBAs what their initial thoughts are and ask for any advice or help the DBAs can give them. In other words, butter them up. Developers need their cooperation as the project progresses, so some investment in this at the start in getting the onside is invaluable. The same goes for information security and other groups with an input that is often seen as restrictive!

If the DBAs have been involved in what looks like a well-planned development effort from the start, then they're less likely to get shirty about last minute requests for oddly-typed fields. If the developers know the DBAs, and have already discussed the project with them, then their communications are likely to have a better tone anyway.

I've worked in both camps, by the way, and have seen (and probably exhibited) the traits you describe.

Answer 7

Well, I've been in this exact situation on the developer side.

The problem has been quite easy to solve : we've admitted that they (the DBA) were much more knowledgeable than us regarding database related things.

Not only have we acknowledged that fact, but I think most of us were convinced that it was true.

We've started listening to their advice (which usually made perfect sense) instead of ignoring it. We've even asked for their help when we were facing tricky problems. We've valued their help. We've thanked them for the time they spent optimizing our poorly-written queries.

Moreover, we've stopped feeling attacked and challenged each and every time they were spontaneously suggesting enhancements in our data structures/queries/etc.

IMO, the main reason why the situation your describing keeps happening is that coders do think they know everything regarding computers better than anybody else (I mean, any non-coding person).

Let's face it, that's not true.

Answer 8

The only attitude you have total control over is your own. If you feel that there is antagonism between us and them, then your own attitude is the place to start as it is the only place where you can realistically affect change. You will find that often if you change how you treat them, they will change how they treat you. Treat the other side with respect. Respect their time and their deadlines (dbas are often supporting much more than just your project) as well as your own. Talk to them early in the project and sit down together to create a plan of action. Don't wait until the last minute to provide information they need (I've been asked to load new customer data the day the site is to go live with no prior knowledge that a project even existed or a change to have input into what the file needed to contain. The dbas work takes time as well, remember to put it into the project plan. The same goes if you are on the dba side, respect other people's deadlines, talk to them respectfully, don't wait until the last minute to tell them something they needed to know, etc.

Answer 9

Find DBA's that DON'T like programming. When DBA's fancy themselves as programmers they can always do it better and all developers are lacklustre. When all a DBA cares about is keeping the database running smoothly and securely and not with how to optimise a stored procedure from 100 lines to 99 lines everyone will be happy.

Of course I'm a developer not a DBA :-).

Answer 10

If you know better, you have to rise above this. I went to work for an organization where this was deeply in the culture of the existing staff, and I was (as a developer and architect) immediately assumed to be on one side.

I personally found that through open discussion, and working with individuals on both sides, that trust can be achieved, once both groups see evidence of goals and motivation.

How do you eat an elephant? One bite at a time.

And of course, this is a systemic business cultural problem. It should also be addressed from the perspective.

Answer 11

Get them to sit together

Answer 12

Common decency will get both sides a long way. I'm well aware of the huge collapsing of egos, not only DBA vs. dev, but also amongst kin.
Involve everyone in the project, give each other room to breathe. It really can be dead simple. In our current project the DBA is my neighbour and just communicating like normal human beings, in stead of little kids who're afraid to give in only the slightest bit, gets us alot of work done.

Communication, patience and respect is the key. Ain't that an open door?

Answer 13

On one project I worked on, the DBA's were developers ... of course, we had a custom developed database system, so development and maintenance had to be done by someone internal.

Others have touched on the communication and respect issues, so I won't beat that drum.

As Michael Borgwardt's comment to Brian's answer said, having the DBA's as direct employees but the developers as contractors naturally creates an us vs. them mentality on both sides. So, either make the developers direct hires, or farm out the DBA work to the same contracting company. Yeah, I expect the DBA work is "too sensitive" to be farmed out ...