Five Rules For Sucessful Conversations With DBAs

  • The bottom line (for DBAs, developers, and anybody else drawing a paycheck) is:

    - If you are approachable and easy to work with, people will want to work with you;

    - If you are a "no" person and difficult to work with, people will want to work around you.

    And don't fool yourself into thinking that your skills are so specialized or valuable that you are above those principles, or can get away with "I'm like this, so deal with it."

    Anybody who thinks they are truly invaluable needs to stick their finger in a bowl of water, pull it out, and examine the hole left behind.

  • Simple, you're here to protect the data. Period.

    I found that amusing. If that is true, then turn off the server, remove the power cords and go home. The data will be very safe, but not very useful.

    So, you need to use the data too? Is that data going to remain static or is it going to change? If it is going to remain static, burn it on DVDs and mount those for access - it will remain very safe because nobody will be able to change it.

    You need the data to change as well? If so, I believe software will most likely be making those changes - at least, on most projects I've worked on, it has. If DBAs are changing the data, I'd be concerned about the audits.

    Now, if software is changing the data and if developers write the software, why would DBAs believe they should be in charge of how developers do their job? Do they know how to write software better than the software developers?

    None of the interaction is as simple as you put it. I agree with Knut. It all depends on the installation - some people (DBAs, Developers) are reasonable to work with, others are a pain; all you can do is not be a pain (to the best of your ability), back up what you say with data, remain consistent and if that doesn't work, hope they retire before you go crazy.

    Thanks,

    Rob

  • Why isn’t Rule #5 first? To affect change, we need to recall Stephen Covey’s advice, “Seek first to understand.”

    Admittedly, DBAs are often a bit opinionate (bordering upon arrogance), however, worthy DBAs are rightfully protective of corporate assets and should be suspicious of change. Hence, I would think that the second rule should be Collaboration.

    Any sage DBA is cognizant of Covey’s fifth principle (“Seek first to understand”) and is going to foster an environment where input is encouraged. Admitted, rely upon the developer’s thorough data analysis

  • These seem to be mostly common sense rules for treating any fellow employee, DBA or not. A DBA has an important role, but I don't believe it's really more important than many other roles, including developers. A DBA should not be treated with a different level of respect, it's just that everyone should be treated with a high level of respect. Even though they are often the gatekeeper, A DBA should not consider themselves as more important than anyone else. When that happens it just causes unnecessary stress among coworkers. Egos should be left at home.

  • Kyrilluk (4/10/2015)


    From a Dev perspective, I think that the article is a bit backward.

    First of all, why does it suggest that only dev should come up with data to back up their claim and not the DBAs?

    The other issue is that recently, the power has shifted from DBAs to Developers.

    There are many reasons for that:

    1) A lot of companies that adopt BI are small to medium. The perceived security level that they need can be accomplished by a basic backup/restore strategy. So between a good good DBA and a good Dev they are choosing the later for obvious reasons. Or they decide to use a cloud solution.

    2)Businesses are starting to realize that data is the new oil. Keeping it safe into the ground with a bulldog guarding the gate doesn't improve their bottom line. So when the dev extract and refine this "oil" and tell then that there is bulldog that prevent them to get the profit that they deserve, the businesses tend to listen.

    As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.

    I love this attitude. "We don't need a DBA".

    Please keep promoting these myths.

    Because I make a ton of money fixing the garbage that was put in place because "We don't need a DBA"

    As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.

    Really? According to whom? Sellers of cloud computing?

    Again, please keep promoting these myths. Retirement will keep getting more and more comfortable.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • This is one of those 'touchy topics' that tend to send people all over the map.

    There's good and bad developers and there's good and bad DBAs. There's no standard and there certainly are stereotypes. This article plays mostly to the stereotypes.

    Collaboration is essential. DBAs need to publish the guidelines for what is allowed into production. Developers need to incorporate those into their coding and testing. And on both sides there needs to be respect for what the other team does.

    The other thing is that quite a bit of the time the DBAs don't set the rules. They enforce them. Developers should realize they aren't special flowers who don't have to follow the rules or 'rock stars' (I hate that term) who know better than the DBAs as to how the company infrastructure should run.

    If you're guilty of being a stereotype then it's on you to take your lumps.

  • In the past, I was asked to provide access to my divisions data to SalesForce consultants. We handled 3rd party data, so we did not own it. I refused until I could get approval from our lawyers that we could put the data into SalesForce for other people to look at. Devs just wanted access, NOW. No explanation of why, or for what purpose, on top of that they where not MY teams developers.

    In the end we got approval from the lawyers after they reviewed the contracts etc. I happily gave them the minimum access they needed to get their project done.

    This is my job in a nutshell. Provide secure and available data services. Not to make developers, managers and executives get what they want just because they want it.

    And I never do anything that I think is questionable when it comes to security without a written approval 😉 It's amazing how many times I have had an executive try to bully me into doing something, and never send that email when I refuse to do it on a verbal order....

  • Michael L John (4/10/2015)


    Kyrilluk (4/10/2015)


    From a Dev perspective, I think that the article is a bit backward.

    First of all, why does it suggest that only dev should come up with data to back up their claim and not the DBAs?

    The other issue is that recently, the power has shifted from DBAs to Developers.

    There are many reasons for that:

    1) A lot of companies that adopt BI are small to medium. The perceived security level that they need can be accomplished by a basic backup/restore strategy. So between a good good DBA and a good Dev they are choosing the later for obvious reasons. Or they decide to use a cloud solution.

    2)Businesses are starting to realize that data is the new oil. Keeping it safe into the ground with a bulldog guarding the gate doesn't improve their bottom line. So when the dev extract and refine this "oil" and tell then that there is bulldog that prevent them to get the profit that they deserve, the businesses tend to listen.

    As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.

    I love this attitude. "We don't need a DBA".

    Please keep promoting these myths.

    Because I make a ton of money fixing the garbage that was put in place because "We don't need a DBA"

    I'm merely stating a fact that in small and medium size companies, people don't tend to use DBA's. They use dev that double as "accidental dba's". Now if you make a lot of money it's probably because you are super specialized and work for big companies.

    Michael L John (4/10/2015)


    As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.

    Really? According to whom? Sellers of cloud computing?

    Again, please keep promoting these myths. Retirement will keep getting more and more comfortable.

    If you are very specialized you will end up in one of this big data center that provide cloud computing for Big company and yes, you will be ok. But most DBA's starting today, if they don't widen their skill set, are going to face a very tough competition and wages for DBA's are going to slump.

    As this article explain; http://www.computerweekly.com/feature/Time-to-pension-off-your-DBA outsourcing the DBA's is a new trend that is here to stay.

  • Kyrilluk (4/10/2015)


    Michael L John (4/10/2015)


    Kyrilluk (4/10/2015)


    From a Dev perspective, I think that the article is a bit backward.

    First of all, why does it suggest that only dev should come up with data to back up their claim and not the DBAs?

    The other issue is that recently, the power has shifted from DBAs to Developers.

    There are many reasons for that:

    1) A lot of companies that adopt BI are small to medium. The perceived security level that they need can be accomplished by a basic backup/restore strategy. So between a good good DBA and a good Dev they are choosing the later for obvious reasons. Or they decide to use a cloud solution.

    2)Businesses are starting to realize that data is the new oil. Keeping it safe into the ground with a bulldog guarding the gate doesn't improve their bottom line. So when the dev extract and refine this "oil" and tell then that there is bulldog that prevent them to get the profit that they deserve, the businesses tend to listen.

    As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.

    What does a cloud solution have to do w/ a DBA?

    Any DBA is going to be suspicious of change. After all, his role is to protect corporate assets.

    I love this attitude. "We don't need a DBA".

    Please keep promoting these myths.

    Because I make a ton of money fixing the garbage that was put in place because "We don't need a DBA"

    I'm merely stating a fact that in small and medium size companies, people don't tend to use DBA's. They use dev that double as "accidental dba's". Now if you make a lot of money it's probably because you are super specialized and work for big companies.

    Michael L John (4/10/2015)


    As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.

    Really? According to whom? Sellers of cloud computing?

    Again, please keep promoting these myths. Retirement will keep getting more and more comfortable.

    If you are very specialized you will end up in one of this big data center that provide cloud computing for Big company and yes, you will be ok. But most DBA's starting today, if they don't widen their skill set, are going to face a very tough competition and wages for DBA's are going to slump.

    As this article explain; http://www.computerweekly.com/feature/Time-to-pension-off-your-DBA outsourcing the DBA's is a new trend that is here to stay.

  • I'm merely stating a fact that in small and medium size companies, people don't tend to use DBA's. They use dev that double as "accidental dba's". Now if you make a lot of money it's probably because you are super specialized and work for big companies.

    Who's facts? Please show me your facts.

    Certainly the two-person company would not hire a DBA. But they also would not hire a developer.

    The last project I finished was for a 7.1 million in revenue company with a total of 350 employees.

    Before that, in order:

    2.3 in revenue, 90 employees

    31.5 in revenue, 575 employees

    Currently I am at 13.5 in revenue with 60 employees.

    Not large companies. As for "super specialized", here is what I have done in the past year.

    1. Led a data center move. Not just database servers, but application, web, and file servers.

    2. Designed and implemented the BI initiative.

    3. Started gathering data warehouse requirements

    4. Re-factored 500+ procedures. Why? Because the developers and accidental DBA's did not have any idea on how things worked. And performance was terrible.

    5. Implemented maintenance.

    6. Implemented monitoring

    7. Implemented database source control.

    This list goes on and on. Doesn't sound "super specialized" to me.

    If you are very specialized you will end up in one of this big data center that provide cloud computing for Big company and yes, you will be ok. But most DBA's starting today, if they don't widen their skill set, are going to face a very tough competition and wages for DBA's are going to slump.

    As this article explain; http://www.computerweekly.com/feature/Time-to-pension-off-your-DBA outsourcing the DBA's is a new trend that is here to stay.

    Big data center? I have two production database servers.

    Outsourcing DBA's? This article is from 2002. It's 12 years old! Yes, there are many outsourcing companies that making lots of money and showing big growth. One that I know of has gone from 35 employees to 350+ employees in 3 years.

    How about a more current article about demand?

    http://www.bls.gov/ooh/computer-and-information-technology/database-administrators.htm

    The US department of Labor is predicting a 15% growth in demand for DBA's for the next 10 years.

    Please stop spewing opinions as fact.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • Michael L John (4/10/2015)


    I'm merely stating a fact that in small and medium size companies, people don't tend to use DBA's. They use dev that double as "accidental dba's". Now if you make a lot of money it's probably because you are super specialized and work for big companies.

    Who's facts? Please show me your facts.

    Certainly the two-person company would not hire a DBA. But they also would not hire a developer.

    The last project I finished was for a 7.1 million in revenue company with a total of 350 employees.

    Before that, in order:

    2.3 in revenue, 90 employees

    31.5 in revenue, 575 employees

    Currently I am at 13.5 in revenue with 60 employees.

    Not large companies. As for "super specialized", here is what I have done in the past year.

    1. Led a data center move. Not just database servers, but application, web, and file servers.

    2. Designed and implemented the BI initiative.

    3. Started gathering data warehouse requirements

    4. Re-factored 500+ procedures. Why? Because the developers and accidental DBA's did not have any idea on how things worked. And performance was terrible.

    5. Implemented maintenance.

    6. Implemented monitoring

    7. Implemented database source control.

    This list goes on and on. Doesn't sound "super specialized" to me.

    Well, I guess I assumed that we had the same understanding of what is a DBA. My bad 🙂

    From what you explain, your projects are a mixture of DBA and developements (BI)

    1. Led a data center move. Not just database servers, but application, web, and file servers. <--DBA

    2. Designed and implemented the BI initiative. <--BI DEV

    3. Started gathering data warehouse requirements <-- BI DEV

    4. Re-factored 500+ procedures. Why? Because the developers and accidental DBA's did not have any idea on how things worked. And performance was terrible. <--BI DEV

    5. Implemented maintenance.<--DBA

    6. Implemented monitoring<--DBA

    7. Implemented database source control.<--DBA/BI DEV

    Michael L John (4/10/2015)


    Outsourcing DBA's? This article is from 2002. It's 12 years old! Yes, there are many outsourcing companies that making lots of money and showing big growth. One that I know of has gone from 35 employees to 350+ employees in 3 years.

    How about a more current article about demand?

    http://www.bls.gov/ooh/computer-and-information-technology/database-administrators.htm

    The US department of Labor is predicting a 15% growth in demand for DBA's for the next 10 years.

    Please stop spewing opinions as fact.

    According to the article you gave, here is their definition of a DBA:

    System DBAs are responsible for the physical and technical aspects of a database, such as installing upgrades and patches to fix program bugs. They typically have a background in system architecture and ensure that the firm’s database management systems work properly.

    Application DBAs support a database that has been designed for a specific application or a set of applications, such as customer service software. Using complex programming languages, they may write or debug programs and must be able to manage the aspects of the applications that work with the database. They also do all the tasks of a general DBA, but only for their particular application.

    I consider myself as a B.I. Developer but according to this article, I'm a DBA too ("Application DBA"). My comments were more about "System DBAs" because they are the ones that the article by Joshua Feierman seems to be speaking about.

  • The essence of the article, to me, seems to be about the power struggle between a DBA and Developer that happens every time a change is requested. I want to bypass all the issues of ego and psychological maturity and focus on power. Power comes in several forms:

    Personality Power:

    Having the ability to communicate well and win over others to accomplish your goals. Some call it charisma.

    Intellectual Power:

    Having the knowledge to best solve a problem under a certain set of ranked criteria. Experience is the best teacher. Staying in a state of "not knowing" is the most helpful for learning from new experiences.

    Positional Power:

    Using the authority and responsibility granted to a job position. Of course, getting fired means you instantly lose this power. Many powerful people are actually just weak people in powerful positions.

    Resource Power:

    Having money or any asset that others need gives you power to control the quality of others' lives.

    Relational Power:

    Having strong ties with other influential team members will grant you certain privileges.

    Accomplishment Power:

    Having many challenging projects under your belt will be empirical proof that you deserve power beyond that of less successful people.

    In summary, a developer and a DBA will need to resolve these power struggles to get their jobs done. How well they do it is up to the individuals involved.

  • Bill Talada (4/10/2015)


    The essence of the article, to me, seems to be about the power struggle between a DBA and Developer that happens every time a change is requested. I want to bypass all the issues of ego and psychological maturity and focus on power. Power comes in several forms:

    Personality Power:

    Having the ability to communicate well and win over others to accomplish your goals. Some call it charisma.

    Intellectual Power:

    Having the knowledge to best solve a problem under a certain set of ranked criteria. Experience is the best teacher. Staying in a state of "not knowing" is the most helpful for learning from new experiences.

    Positional Power:

    Using the authority and responsibility granted to a job position. Of course, getting fired means you instantly lose this power. Many powerful people are actually just weak people in powerful positions.

    Resource Power:

    Having money or any asset that others need gives you power to control the quality of others' lives.

    Relational Power:

    Having strong ties with other influential team members will grant you certain privileges.

    Accomplishment Power:

    Having many challenging projects under your belt will be empirical proof that you deserve power beyond that of less successful people.

    In summary, a developer and a DBA will need to resolve these power struggles to get their jobs done. How well they do it is up to the individuals involved.

    Perhaps Stephen Covey can help here "Seek to understand"

  • Bill Talada (4/10/2015)


    The essence of the article, to me, seems to be about the power struggle between a DBA and Developer that happens every time a change is requested. I want to bypass all the issues of ego and psychological maturity and focus on power. Power comes in several forms:

    Personality Power: Having the ability to communicate well and win over others to accomplish your goals. Some call it charisma.

    Intellectual Power: Having the knowledge to best solve a problem under a certain set of ranked criteria. Experience is the best teacher. Staying in a state of "not knowing" is the most helpful for learning from new experiences.

    Positional Power: Using the authority and responsibility granted to a job position. Of course, getting fired means you instantly lose this power. Many powerful people are actually just weak people in powerful positions.

    Resource Power: Having money or any asset that others need gives you power to control the quality of others' lives.

    Relational Power: Having strong ties with other influential team members will grant you certain privileges.

    Accomplishment Power: Having many challenging projects under your belt will be empirical proof that you deserve power beyond that of less successful people.

    In summary, a developer and a DBA will need to resolve these power struggles to get their jobs done. How well they do it is up to the individuals involved.

    Bill, that is quite an interesting list. I recently completed a class on supervision and management and have spent a lot of time recently reflecting on previous supervisors in case I become one again, and I've had plenty of good and bad ones. Looked at in the context of this list, I can see where past managers abused one level while neglecting or abandoning another. Did you develop this yourself or is it Covey or someone?

    Back to the topic on hand, I'm a firm believer in Rodney King's statement for many facets of my life: "Why can't we all just get along?" I freely admit no understanding of object programming and AF, it seems to me that there's a failure to communicate: developers don't have a good understanding of how their data is going to be stored because they don't get a background in database. I taught relational database to a group of COBOL programmers and you could see the lights come on as they learned about normalization. I remember a 1500 column mainframe file that was sparsely populated that needed to be converted to SQL Server, all because of old mainframe techniques that were horrors in a relational/normalized world.

    Part of the problem, in my ever so humble opinion :-D, is that a lot of programmers are so tightly focused on their current language that they don't explore others, including database and relational theory. Maybe NoSQL will meet their data storage requirements, just don't ask me to maintain it or link it in to my SQL Server.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Great article Steve! I am neither an "official" DBA nor developer. However, I work with the database all day, every day on the operations and projects sides. Point number four is 100% correct and I have found it to be accurate EVERY time!

    As to the other points; they are also 100% correct...and explain the attitude and comments from almost every subscriber on EVERY single thread of this website!

    I would like to see an article on how to talk to developers as well, because I have to work with both.

Viewing 15 posts - 61 through 75 (of 76 total)

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