October 23, 2012 at 9:44 am
I've been a developer for over 16 years and at the beginning of that time, I was forced to play the role of DBA which gave me a better handle on how to troubleshoot problems with the application I worked on from the database side of the house. I have noticed during that time that working with a DBA is not always easy (I'm sure the reverse is also true from the DBA's perspective). There have been times when I've had to work with a DBA who was less than cooperative with me when I have needed his/her help. With the often mandatory separation between developer and DBA, there is often nothing a developer can do to get the problem at the database level resolved except to wait for the DBA to help. What frustrates me is that the DBA is often resentful of helping the developer in getting the issue resolved. My feeling is that the developer and the DBA have to be able to work together as a team in order to keep their customers happy. Can anyone here explain to me why the relationship between the two is often tense? I really want to understand this. This is an honest question and I'd appreciate some constructive feedback on it.
October 23, 2012 at 1:00 pm
Hello,
I hope it is stress. Having to manage too many troublesome instances or other work that has to be done too.
Also it is a lot harder to revert to a previous situation (not easy to change datastructures).
At work we can have a sit-in where the required teams come together. It helps hearing what the team is busy about, what the upcoming changes are and their impact.
Currently very busy handling a project which delays other projects. After that I intent to teach, the interested, databasetroubleshooting techniques like tracing, best practices, which can be used on their developmentmachines.
Automation will help too.
You can also escalate when necessary.
October 23, 2012 at 6:49 pm
Its interesting that you say:
chinn_chris (10/23/2012)
What frustrates me is that the DBA is often resentful of helping the developer in getting the issue resolved.
I certainly have felt that same sentiment, but coming from the other direction.
My perspective on this is that of being a DBA for 10 years and working with certain developers who have an attitude that once a project is in production, clearly nothing can ever be the fault of the developer again. The immortal lines "it worked fine in development"; "What do you mean it can't run as 'sa'?" make my head spin around and green slime gush from my mouth.
The separation of environments, too, can be the cause of 'sulky developer syndrome' as I see it; with the developer resenting that he's not permitted to tinker in a production environment and giving the DBA a hard time because of it.
Generally speaking any tension between my team and the development teams arises because, when the s#!t hits the fan, we are the ones in the firing line and the developer is hiding out in his Teflon jacket. This could be because we've been hit with a new release at the 11th hour with inadequate information to deploy it or, perhaps because something is not performing well (or at all) in production and "it worked fine in development" is the only contribution the developer feels it necessary to make. When we're under immense pressure to get something live/back up, smugness and shoulder-shrugging doesn't really cut it. I will add, too, that this same conflict occurs, on occasion, with dev DBAs, so I wouldn't pigeonhole the behaviour as developer/DBA warfare, more dev/prod warfare;-)
Other than that I get along like a house on fire with our developers; we have regular meetings, occasionally heated debate, often useful discussion with great collaborative outcomes. We're usually fairly open to hearing others ideas and I'd like to think that we can usually work towards a common goal without much in the way of conflict
October 23, 2012 at 7:50 pm
I think it's frequently because when a Developer asks for help, it's on an ad hoc basis that may not fit into any open time for the DBA because some don't have any. They've been loaded up just like any Developer might be.
That doesn't excuse a cruddy attitude but it does explain it.
The other thing is that such help is frequently a one way street because the Developer simply doesn't have the privs to help the DBA.
That, notwithstanding, I don't believe in keeping the DBAs separate from the Developers. I sit right in the middle of all the Developers so I'm right there to help and answer just about any question at the drop of a hat. Sure, the answer is sometimes to remind them that I've taught them how to use Books Online but they get that. It's not a frequent reminder.
I also build templates for them to promote code with and I do 100% code reviews which also turn out to be a great opportunity to do some mentoring instead of yelling.
They key is that they listen to me and I listen to them. That takes some effort and trust on the part of everyone. Like I tell everyone else, "We're all in this together and I'm pullin' for ya" (Quote from "Red-Green").
{EDIT} One more thing that may cause a rift... sometimes the DBA knows squat about T-SQL but won't admit it. It depends on the type of DBA in place and it certainly depends on the attitude of the DBA.
--Jeff Moden
October 27, 2012 at 2:08 pm
Wow, I would certainly be ticked off if the developer had that attitude and I was the DBA that had to make the app work in production. My opinion, devs and DBAs are both tasked with making it work in production once it moves there. When it comes to my applications, I kind of take it personally when they don't work and I'm somewhat embarrassed when that happens because it might may that I didn't do a thorough job before it moved to production.
I also understand that DBAs are quite often over-loaded with work so they may not be able to get to my request immediately and that is certainly understandable. I don't expect them to drop everything to take care of my request, just to add my request to their list of priorities if management is telling me it has to be done as soon as possible. Ultimately, we both an answer to management and our customers.
As for the separation of the roles of the DBA and the dev, there is a reason for that separation, mainly it's for security. When I need my permissions elevated in a produuction environment, I ask my manager and he usually grants my request and trusts me that I won't screw up the prod environment, but there has to be a good reason for doing that. It is sometimes frustrating that I cannot go on the DB server myself and take care of the issue if it is a quick thing that I know how to do but it is okay if the DBA gets it done in a timely fashion. But there are times when it is urgent and the DBA blows it off.
I find that very irritating.
Anyway, thank you for your feedback on this. It certainly opened by eyes about the behavior that DBAs sometimes have to put up with from developers. I've dealth with a few arrogant developers and DBAs in my career. However, after reading your response to my initial post, I think the thing to take away from it is making an effort at better lines of communication between the two and emphasizing that both are working toward the same goal, a satisfied customer.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply