Five Rules For Sucessful Conversations With DBAs

  • peter.row (9/24/2013)


    Nowhere in my response did I say anything at all about asking for permissions etc...

    Obviously asking for sysadmin rights just because it makes life easier you should expect to get a short and sharp "NO!"

    However it also seems ridiculous to suggest that DBAs are so fragile that you are not even allowed to say "I think you are incorrect because of ...." to them without them blowing their top. To me if they did that they are being an arsehole - telling someone you think they are wrong and giving reasons/stats why should not be met with rage and tantrums it should be met with the mentioned respect and also with communication so that the person understands the reason, i.e. spreading the knowledge, otherwise how is non-DBA ever going to learn.

    humbleDBA (9/24/2013)


    kevaburg (9/24/2013)


    However on the other hand it sounds like you are saying that DBAs have a license to be complete arseholes and that "collaboration means licking their boots and putting them on a pedestal.

    Respect and cooperation cuts both ways.

    I am not sure that I agree that was being said. The security, availability and functionality of a companys mission-critical data assets lie in the hands of the DBA. There are too many developers out there that don't understand the architectural niceties of a RDBMS, only the code that can extract data. The DBA is there to protect that data. Would you call the guard that won't let you into a building because you are not authorised an (in your own words) arsehole. I think not and data protection should maintain the same philosophy.

    There are DBAs out there that are truly difficult to work with. Same can be said for developers. Or storekeepers, bus drivers, road sweepers etc....

    The point is simple: A mutual respect for the skills and requirements of each party in the argument is the only way a dispute can get resolved. If you start a discussion agressively, don't expect constructive results. Licking boots is not what is required, simply proof that your request is feasible, safe and in the companys best interests. If it isn't, it won't get implemented.

    Well said...in fact, so good, I've quoted it verbatim again...

    Would love to witness what a Sys Admin would say if you ask for Domain Admin rights, for the only reason that it would make your job easier and not because there was a genuine necesity for it, and I'm sure the air would turn blue. Now, is the Sys Admin an arsehole?

    Same for the Security Admin, when you ask to open up loads of ports on ther Firewall, because it makes your life easier. Is s/he being an arsehole when they politely tell you where you can shove yourself?

    I've been on both sides of the fence, as a Developer, Developer DBA, and Production DBA, and I've witnessed the horror of having to in-fill following a data breach, trying to retrospectively implement better security on 'live' code - and management had been warned of the serious potential risks, but the DBAs were dismissed as naysayers. It's not fun and it's not pretty...for anyone...DBAs, Sys Admins, Developers, and most important, the business which suffered massive financial penalties due to loss of reputation, loss of customers, regulatory penalties, etc.

    Security is not just the domain of Sys Admins, Security Admins, Production DBAs, it's the responsibility of *all*. Just look at the recent breaches in well-known Banks in London, UK, who fell for a bit of social engineering, letting in supposed authorised company IT engineers who then went on to fit hacking components to the bank's computer systems.

    Whoops...sorry peter.row, I wasn't critising you or suggesting that you had talked about permissions from Sys Admins...I was attempting to reiterate both your comment and kevaburg's of mutual respect and then to follow on with the theme of the article, with my asking the questions of how a Sys Admin and Security Admin may respond to anyone, apart from Sys Admins and Security Admins, asking for high-level privileges. I also then wanted to express my thoughts in a short note covering my experiences and of recent events.

    But in doing so, I seem to have also rattled kevaburg, and perhaps others, and being accused of 'agressiveness '.

    This was not my intention, as I only wanted to share my thoughts on what, in my view, is a very important subject, well thought out in Joshua Feierman's article.

    I most humbly apologise if I've caused any offence.

  • But in doing so, I seem to have also rattled kevaburg, and perhaps others, and being accused of 'agressiveness '.

    I wasn't rattled by your response.....it was actually Peter.Rows response that seemed agressive. Perhaps I misread and misinterpreted his intention but to me it seemed unncessarily terse.

  • kevaburg (9/24/2013)


    sqlnaive (9/24/2013)


    Really Fantastic article. I have been on both sides of it and now working purely as Developer so that helps me having a healthy negotiation with system DBAs. Remember the main focus should eb to "work together towards the same direction i.e. solution". However at times I've seen it becoming the fight for the pride or prestige where no one gains anything and eventualy the project suffers.

    Some of my best professional experiences have been meeting with developers to discuss merits of particular solutions based on evidence. This is how we manage to produce the results that we do. But then I think I have a DBA/Developer relationship that appears to be the exception rather than the rule.....

    I also had my share of experiences with both kind of people. At times, I had to face the DBAs who bluntly said that this cannot be done as per this rule or that rule without providing any alternates (if there were any) and that it's your problem entirely so DND us. Thankfully currently i have these perfect set of guys (and touchwood :satisfied:) with whom I can discuss over the issues rather than blowing punch after punch on each other.

  • kevaburg (9/24/2013)


    But in doing so, I seem to have also rattled kevaburg, and perhaps others, and being accused of 'agressiveness '.

    I wasn't rattled by your response.....it was actually Peter.Rows response that seemed agressive. Perhaps I misread and misinterpreted his intention but to me it seemed unncessarily terse.

    Ahhhh...ok, thanks for letting me know. Glad I hadn't caused offence to you. Certainly wasn't my intention and I thought your original comment was spot-on. 🙂

  • sqlnaive (9/24/2013)


    kevaburg (9/24/2013)


    sqlnaive (9/24/2013)


    Really Fantastic article. I have been on both sides of it and now working purely as Developer so that helps me having a healthy negotiation with system DBAs. Remember the main focus should eb to "work together towards the same direction i.e. solution". However at times I've seen it becoming the fight for the pride or prestige where no one gains anything and eventualy the project suffers.

    Some of my best professional experiences have been meeting with developers to discuss merits of particular solutions based on evidence. This is how we manage to produce the results that we do. But then I think I have a DBA/Developer relationship that appears to be the exception rather than the rule.....

    I also had my share of experiences with both kind of people. At times, I had to face the DBAs who bluntly said that this cannot be done as per this rule or that rule without providing any alternates (if there were any) and that it's your problem entirely so DND us. Thankfully currently i have these perfect set of guys (and touchwood :satisfied:) with whom I can discuss over the issues rather than blowing punch after punch on each other.

    Don't take me the wrong way, I wasn't dissing anyone, especially not developers. My point was nothing more than both groups have to realise that a discussion has to be one to one and not one end trying to maintain a control over the other.

    The most important aspect I think is something that was pointed out and that is the point whereby simply saying "no it can't/won't be done" is not good enough. Alternative solutions 90% of the time have to be sought and where a DBA says "no" it should be quickly followed up with "but I will see if there is another way".

  • "So, what is my role as a DBA, and how does it relate to your role as a developer?"

    Oh nice question !!!

    I'll add that in my tool box!

  • Very nice article!

    I believe that every developer with 2+ years experience has passed through all the mentioned rules.

    Thanks.

    Igor Micev,My blog: www.igormicev.com

  • Hey everyone! First off, let me say how awesome it is to see so many great responses to my article. This is the first time I've written for SQLServerCentral, and to see such a good discussion come from it... well, it warms my cold, hard, ex-DBA heart. 🙂

    However on the other hand it sounds like you are saying that DBAs have a license to be complete arseholes and that "collaboration means licking their boots and putting them on a pedestal.

    Respect and cooperation cuts both ways.

    I couldn't agree more (on the both way bit)! I too have known DBAs who simply act as obstructionists and clearly get off on the power they wield. This is no better than the developers who try and push out sub-standard work. For the DBA-developer relationship to be a successful one, it must be cooperative and include both sides.

    My point was not that you have to always walk on eggshells or kiss a DBA's rear end if you want things to go your way (though as several posters pointed out, food and / or beer surely won't hurt your chances). Rather, I'm just illustrating some basic social graces that will help put you in their graces. Let's face it: IT people in general have poor social skills (myself included), so a few tips here and their on being polite and respectful couldn't hurt. And, as you'll see in my soon-to-be-done follow-up article on things from the other side (i.e. "Five Rules For Successful Conversations With Developers"), I'm going to be equally hard on the DBAs in the room.

    I guess I've never met/conversed with any real DBAs such as you describe. Some of the people I've dealt with that have declared themselves as a DBA to me have clearly not been DBAs - I knew more than them and I am not a DBA I'm a developer.

    Problem is the projects I work on I end up a doing development, DB schema design, writing SQL etc... there is typically never a DBA to help.

    That is really unfortunate and I'm sorry you've had such negative experiences. Unfortunately, bad DBAs are just as prolific as bad developers. Hopefully in the future you'll get some chances to work with some good ones.

    The most important aspect I think is something that was pointed out and that is the point whereby simply saying "no it can't/won't be done" is not good enough. Alternative solutions 90% of the time have to be sought and where a DBA says "no" it should be quickly followed up with "but I will see if there is another way".

    Hear hear! If, as a DBA, I ever said "No" without offering to help find an alternative, I would expect to get smacked. This is obstructionism at its worst. Like it or not, business requirements must be met, so we have to be ready with workable solutions to problems, or expect to get pushed out of the way. Of course, the rule works both ways; as a developer if you simply say "Well this is the way I did it and we have to do it that way..." Well, good luck with that.

    Seriously, thanks again for the great chats folks.

  • I don't often comment, but I absolutely loved this. I wish I'd had it a year ago. I mostly just spend my time lurking in the shadows of this strange and forbidden land, stealing secrets.

    By which I mean: I'm a developer who has started to learn SQL and a bit of database development. I absolutely love it and wish I'd had time for more formal training during college, but that's life. The things you've said here make a lot of sense and I had to learn them (fairly quickly) over the course of the a few months as the DBA is our only other SQL guy. Personally, sitting on the other side of the table (pun intended) from most of you guys, not all developers are evil, database-wrecking monsters. For us it's about providing the customer with the best product they can have, but working well with the DBA and not asking stupid questions or involving managers is the right way to do things. Then again, maybe my experience with SQL has made me a little more protective of the data.

  • Love this article. Point 5 I have blatently stolen and now added to a slide deck on Database Security which I have to present to a load of developers next week.

  • I particularly like Rule #5. Similarly and I don't recall where I read this quote but "DBAs are the protectors of the organizations data. We took this oath when we accepted the job as a DBA". As one who will always give the benefit of the doubt and try to see the other person's perspective; it took me quite a while to get this point and learn to stand my ground when it comes to being a firm but fair DBA.

    Great stuff Josh!

  • kevaburg (9/24/2013)


    sqlnaive (9/24/2013)


    kevaburg (9/24/2013)


    sqlnaive (9/24/2013)


    Really Fantastic article. I have been on both sides of it and now working purely as Developer so that helps me having a healthy negotiation with system DBAs. Remember the main focus should eb to "work together towards the same direction i.e. solution". However at times I've seen it becoming the fight for the pride or prestige where no one gains anything and eventualy the project suffers.

    Some of my best professional experiences have been meeting with developers to discuss merits of particular solutions based on evidence. This is how we manage to produce the results that we do. But then I think I have a DBA/Developer relationship that appears to be the exception rather than the rule.....

    I also had my share of experiences with both kind of people. At times, I had to face the DBAs who bluntly said that this cannot be done as per this rule or that rule without providing any alternates (if there were any) and that it's your problem entirely so DND us. Thankfully currently i have these perfect set of guys (and touchwood :satisfied:) with whom I can discuss over the issues rather than blowing punch after punch on each other.

    Don't take me the wrong way, I wasn't dissing anyone, especially not developers. My point was nothing more than both groups have to realise that a discussion has to be one to one and not one end trying to maintain a control over the other.

    The most important aspect I think is something that was pointed out and that is the point whereby simply saying "no it can't/won't be done" is not good enough. Alternative solutions 90% of the time have to be sought and where a DBA says "no" it should be quickly followed up with "but I will see if there is another way".

    Chill Kevaburg, I am not pointing anything here friend. 🙂

    I was just saying that this DBA vs Dev (happens at times) is same like the one's between Dev vs QA (much more frequently) but there is always a good way to do the work, be it Dev or DBA or QA. I am very happy with all my counterparts and from your post seems you are too. So just chillax 🙂 🙂 🙂

  • Josh, a nice take on the complexities of dealing with DBA's - I'd like to see you write the corollary for dealing with developers!

  • Andy Warren (9/24/2013)


    Josh, a nice take on the complexities of dealing with DBA's - I'd like to see you write the corollary for dealing with developers!

    Maybe something about how the customers have no idea what they want, the managers have red-hot pitchforks and keep prodding developers, and the DBAs are some kind of mystic mountain yogis preaching patience while the developer is about to have a heart attack from stress? 😀

  • GREAT ARTICLE! Accurate and entertaining!

    (It would help, however, to spell the word "successful" correctly)

    Thank you!

    T.

Viewing 15 posts - 16 through 30 (of 76 total)

You must be logged in to reply to this topic. Login to reply