The Curse of Working With A DBA

noI no more than finished my rant from last week than I started thinking about all the reasons why a healthy chunk of the reasons that developers want to bypass relational database is not the horror of the relational database itself, although, that’s there. No, a very large reason why is the DBA.

We’re on a blog called The Scary DBA. I earned that title, well sometimes. Sometimes I got it and I wasn’t sure why. However, it’s perfectly in keeping with how many people view their database administrators; grumpy, obstructionist, slow, difficult, control freak, etc.. There are even jokes about it, “What’s the DBAs favorite word? No!” And for those answering “It depends” that’s two words.

I understand why. In large part it’s that phone in your pocket (used to be a pager on your belt, I’m old). That darned thing can go off any time night or day. It tends to make you very gun-shy. You start doing anything you can to keep that thing from going off. And developers, holy moly, they want to change things. They want to introduce new tables and new queries and they want to do it all really fast, faster than you can possibly review all that code, and all, ALL, AAAAALLLLLL, that code needs to be reviewed before we can let it unsettle our production servers. No.

And developers get crazy ideas in their heads sometimes. Maybe it would be easier to put the queries in the code rather than in stored procedures? What? How the heck can I review all the code too? No.

Developers also start thinking to themselves, you know, most of this T-SQL code could be generated using other code. Wait, that means even more T-SQL generated even faster, and generated by a program, and I can’t review that program, or it’s code and you want to put it into my production server? Are you smoking something over there? No.

CLR? Ha! No.

ORM tools? Have you seen that T-SQL? Hell no!

How about other tool sets? Maybe an object database would work here. We may be better off using unstructured storage for data collection in this situation. ID/Value pairs might work well for this application. No, no, no and no again. Just in case you think of something else, no.

Gee, I’m sure if I were a developer I’d be perfectly happy with this approach. I’ve no doubt as developers introduce even harder subjects like agile development, devops, and other things in the future the responses will be just as nuanced. In short, I’d be doing anything I could to bypass the DBAs too.

So, what do we do about it as DBAs? Change. Use the word “Yes.”

We need to recognize that the business is changing, fast. That means that the applications are going to change, faster. We, DBAs, must become enablers. We must create processes and methods that smooth and speed the deployment process in order to provide lots of opportunities for automated testing because you’re not going to review this code and you can’t just stand in the way. We need to adopt to and adapt the development and deployment paradigms used by the developers. We have to start treating databases, as much as possible, like code. We need to have our code in source control along side the application code. We need to be at the stand ups. In short, we need to change what we do and the way we do it. We can’t just say no. We need to say yes. The goal is to get in with the developers and influence through assistance, not just stand in the way.

Is it more work? Yes. Is it going to be hard? Yes. Will we have to go quite a long ways to convince them that we’re not just going to say “No” again? Yes. Are there damned good reasons for us to make these efforts so that someone who loves and protects the data and will be able to provide special skills not developed by most programmers? Yes again.

See, it’s easy. Try it.

11 thoughts on “The Curse of Working With A DBA

  • Allen White

    The biggest issue I have with this approach, Grant, is that developers tend to view their application as an atomic unit, and so the database structures they build server their application and their application only. There’s more to data than that, and we have enough data silos. A proper look at the application from a business perspective will probably reveal some commonality with another application that uses similar, or even the same, data. Take one step back and make sure you’re not reinventing something that’s already there.

  • No arguments Allen. That’s just it though, we, DBAs, Data Architects, etc., actually have a lot to add to the discussions. But I think our past negative behaviors and our (correctly so) over-protective natures have gotten in the way of supporting development. I know I’ve been guilty of it in the past.

  • I think the main reason that DBAs say no is because they are the ones that have to get up in the middle of the night, or lose a weekend, because the code released has caused massive performance problems.

    Devs are generally not on those calls.

    That being said, I’ve mellowed in my old age. I think that’s come down to working at a company that does things the right way, and actually works through a decent UAT and perf test process prior to the automated release of code to production.

  • I smile and say “Sure! What’s it going to take to do it safely?” We have a Dev-Test-QA-CAB-Prod Agile process in place and our developers follow it, so I’m not too stressed out about the MTP for new stuff. We generally find and fix stuff in Test-QA, but sometimes stuff gets through to production that shouldn’t. Fortunately, our business model doesn’t involve life-or-death decisions, so if the worst happens and prod goes down people just get annoyed, but not dead. Life-and-death systems like hospital patient records and 911 emergency systems necessarily are held to a higher standard. Been-there-done-that for years. Now-a-days I try to stay away from Life-and-death systems for my mental and physical well-being. Cheers!

  • Richard Ray

    I work for a company that has one DBA, me. We also have one developer, also me. Our databases support applications that serve thousands of on site customers each interacting dozens of times a day with several of the systems the db’s support.

    I wish there were a way for all developers to experience the sense of hopeless desperation I get when something’s not working 5 minutes before we open for the day. I also wish there were some way for all DBA’s to be on the hook for delivering while everybody from ownership to front line users glare with exasperation, frustration, dissatisfaction, skepticism and downright hostility.

    Maybe then the two camps would get along better.

    Richard Ray
    DBA/Developer
    Jackson Hole Mountain Resort
    Jackson Hole, WY

Please let me know what you think about this article or any questions:

This site uses Akismet to reduce spam. Learn how your comment data is processed.