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


Five Rules For Sucessful Conversations With DBAs


Five Rules For Sucessful Conversations With DBAs

Author
Message
Joshua Feierman
Joshua Feierman
SSC-Enthusiastic
SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)SSC-Enthusiastic (135 reputation)

Group: General Forum Members
Points: 135 Visits: 304
Comments posted to this topic are about the item Five Rules For Sucessful Conversations With DBAs

Senior DBA - Gateway Ticketing Systems
Co-Founder - Do It Simply Software

Follow me at http://sqljosh.com
fhtino
fhtino
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 109
IMHO move rule four ("Collaborate") to number one.
It's the most important.
Toby Harman
Toby Harman
SSC Eights!
SSC Eights! (801 reputation)SSC Eights! (801 reputation)SSC Eights! (801 reputation)SSC Eights! (801 reputation)SSC Eights! (801 reputation)SSC Eights! (801 reputation)SSC Eights! (801 reputation)SSC Eights! (801 reputation)

Group: General Forum Members
Points: 801 Visits: 668
I've had many an argument with App Developers about how to access the data, and there's another rule I would like to suggest.

Don't try and sneak it in. You may get it through the first time, and even the second, but ultimately it's going to be spotted and the DBA is going to react badly to this (to say the least). If you are already on the "hard to work with" list, this may cause even more issues. If there are emails which suggest strongly that this is a bad idea, and it has been discovered after a problem, then your friendly, neighbourhood DBA is going to turn into something bad.

https://www.simple-talk.com/opinion/opinion-pieces/raw-materials-administration-automated/

The rule I like to try to get through to the developers is "Don't come to me with a solution to your database problems. Bring me the problem and some suggestions we can work through."

DBA's like to feel involved (more of rule 4), so share your woes and troubles. You never know, they may have some suggestions too!
peter.row
peter.row
SSChasing Mays
SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)

Group: General Forum Members
Points: 607 Visits: 412
Some of what you've said makes perfect sense.

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 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.

I imagine this is especially true when it comes to bespoke software products where your clients simply install it and host the DB, i.e. it's not an in-house thing. I find that in this scenario whenever there is a problem DBAs won't/don't get involved it's us that has to deal with everything (whether we want to or not).
kevaburg
kevaburg
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2265 Visits: 1022
Fatastic article, thank you!

I have had many a "discussion" with developers that argue there isn't a need for stringent securty in a test and development environment. In my opinion it is the most important place to have it because the model for security that is being tested is the model that will be used in production.

An then there are the developers that believe they have to have SYSADMIN (SQL Server) or SYSDBA (Oracle) rights because "that is how their code works". I don't need to elaborate on that one I think.....
kevaburg
kevaburg
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2265 Visits: 1022
[b]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.
Steph Locke
Steph Locke
Old Hand
Old Hand (367 reputation)Old Hand (367 reputation)Old Hand (367 reputation)Old Hand (367 reputation)Old Hand (367 reputation)Old Hand (367 reputation)Old Hand (367 reputation)Old Hand (367 reputation)

Group: General Forum Members
Points: 367 Visits: 870
You forgot an important rule - 'come bearing food' - since food goes a long way to making your DBA happy and quiescent.

In all seriousness, a very good article. As a followup for developers who would like to learn how to back up their arguments with data before going to their DBAs for help, then I highly recommend Kevin Kline's session from SQLBits.
Graeme100
Graeme100
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1620 Visits: 795
Morning,

I think these are great. I totally agree with them and I agree that the goal is not always peace and harmony (although hope springs eternal), it is a mutual respect for each departments skills.

I think DBAs face an uphill struggle as the business is often on the side of the agile development. I find myself unable to administer the control i think is needed as the business just won't tolerate this. In other words, I don't think the respect is always there.

Excellent article.

Graeme



humbleDBA
humbleDBA
SSC-Addicted
SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)SSC-Addicted (488 reputation)

Group: General Forum Members
Points: 488 Visits: 1508
kevaburg (9/24/2013)
[b]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.
peter.row
peter.row
SSChasing Mays
SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)SSChasing Mays (607 reputation)

Group: General Forum Members
Points: 607 Visits: 412
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)
[b]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.

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search