September 23, 2013 at 9:51 pm
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
September 24, 2013 at 12:51 am
IMHO move rule four ("Collaborate") to number one.
It's the most important.
September 24, 2013 at 1:07 am
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!
September 24, 2013 at 1:56 am
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).
September 24, 2013 at 1:57 am
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.....
September 24, 2013 at 2:08 am
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.
September 24, 2013 at 2:23 am
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.
September 24, 2013 at 2:37 am
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
September 24, 2013 at 3:14 am
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.
September 24, 2013 at 3:38 am
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.
September 24, 2013 at 3:46 am
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.
September 24, 2013 at 3:49 am
Rule 0 -
Bring doughnuts! 😀
September 24, 2013 at 4:00 am
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.
Wow.....that was the sort of agressiveness I was alking about! If you have DBAs that react in that way then I would recommend they get help for begin colleric....
I am also well-aware that you did not mention permissions in your answer. I used it as an example of demonstrated bad practice from the side of developers to make their lives easier without concern for company or DB best practices.
I am one of the DBAs that will quite happily admit when I am wrong. But I need to have it explained why I am wrong.
I normally ask one question: Why is my answer or solution wrong? Typical answers from Developers I have closed the door on include:
1. It just is
2. Noone does it like that
3. When I was on my course
4. I read in a book somewhere
and so on and so forth
Am I also wrong to insist that developers produce an application that fits into OUR security model? Our model does not, and will not devolve to mete the sub-standards of a badly or lazily written application.
Let me explain my practice, in the workplace to ensure the safety and security of my Oracle DBs:
1. Developer comes to me and says they need code inderted into production.
2. The code (and its UNDO partner) are run on a test server to esure both function as expected.
3. If the change works but the undo doesn't, the code goes back to the developer explaining it doesn't work. If the change, in an unforeseen circumstance, can't be wound back, it won't be run in production.
4. Once these tests have been successfully completed they will be performance tested. If IO or CPU performance regresses, the code will be rejected. If network traffic increases disproportionately, the code will be rejected. If the code requires elevated privileges due to lazy or bad programming techniques, the code will be rejected.
5. Once I am happy that I can take responsibility for the code it will be run into the production database and checked over the course of its next few runs. If it fails to meet the criteria met in testing, i will be removed and rewritten.
My employers demand the best DBA efforts I can offer them and in order to do that, I require the same from the people whose code I am trusted with. If they can't accept that then the problem is theirs and not mine.
High standards (not necessarily perfectionism) are the key to a successful RDBMS implementation and I will not sacrifice those standards for bad practice.
September 24, 2013 at 4:03 am
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.....
September 24, 2013 at 4:12 am
What does DBA Stand for?
Don't Bother Asking (We can't hear you in this ivory tower)
Viewing 15 posts - 1 through 15 (of 76 total)
You must be logged in to reply to this topic. Login to reply