I earned my nickname. I’m proud of it. I am the Scary DBA. I don’t really like to advertise my other nickname, Rant (get it, Grant shortened to another word). I earned that one too. I’m not proud of it at all. I got that one because I sometimes don’t listen as much as I should and, because I tend to be more than a little passionate about my job and my databases, I would go off on a rant. And yeah, I stood in the way of some development processes and approaches that I shouldn’t have. Instead of facilitating the development team and trying to understand their problems and issues, I just said “No.” Usually at length.

I just finished reading this post from Martin Fowler, whose work I’ve  enjoyed, about what he’s calling the NoDBA movement. It’s not so much a “movement” as it’s a by-product of the NoSQL movement, ORM tools, and other developer-centric/code-centric approaches to managing data. Some of these are natural, and appropriate, rejections of the relational storage engine. Let’s face it, it doesn’t work very well at all for some types of data collection. You should be using “pick your favorite” NoSQL storage engine for some types of code. But, there are two problems here. The first, Mr. Fowler mentions in passing, just because there are places where NoSQL works well doesn’t mean it works well in all places. Humans very much tend to fall into a mode where “I have a beautiful hammer. Look at all the lovely nails” becomes how we work. There are nails that need that NoSQL hammer, but there are screws and bolts and other types of fasteners out there that using the NoSQL hammer on will not work terribly well. Same as if you have a big data hammer or a structured storage hammer or a relational storage hammer or an object storage hammer or whatever kind of hammer you are currently enamored with. I am not casting aspersions on your very fine hammer to suggest that it’s probably not going to be efficient at pounding in screws. And, I’m telling you flat out, your ID value pair data collection engine which is great for pulling in “web scale” data is going to blow serious chunks when it comes to business reporting. It just will. That’s not questioning it’s utility for data collection, but just as the hammer-to-screw mechanism doesn’t work well, the collection-to-reporting mechanism doesn’t work well either.

The second thing that Mr. Fowler mentions is the social aspects of what’s going on here. It’s “Rant” that is causing the developer to try to find a way around the DBA team. In short, it’s my fault. It’s your fault. We have not been listening. We have not been communicating. We’ve been at war. And that’s just stupid. There are very sound, technical reasons for using an ORM. Standing in front of your developers with a furrowed brow and your arms crossed saying “no” without a full understanding of those reasons just gets you kicked out of the room. Then, of course, the development team goes off and makes some of the classic implementation errors that can be done with ORM tools. But, because you weren’t in the room because you became “Rant” instead of trying to engage and understand, those errors grew and were standardized within the app. It’s your fault. When the developers proposed changes to the structures of the database under development, instead of whining that it was going to take time and that they needed to fill out paperwork and get approval from fifty people, you could have listened and understood what they were proposing and why and then you could have either done the work, or showed them a better way to do the work, or proposed a different solution, or even suggested that maybe they’d be better off with a NoSQL solution. Instead, you became “Rant” and they bypassed you. That’s your fault too.

Now, the really fun part is, that even though you’ve been bypassed, in most organizations I’ve been in or worked with, inevitably the data has to be reported on and it has to be backed up and it has to go through a DR process. Then, suddenly, you get handed the mess. And it is a mess because no one even thought about reporting on the data collected or backups or the ability to get the site back on it’s feet in the event of a fire/flood/meteor strike. And this is not the mess that those nasty developers created. Oh no. It’s the mess you, “Rant,” created. Fault yours.

Yes, I’m off on a tear, a rant. Initially because after reading what Mr. Fowler wrote I was quite upset with him and his attitude. Then I recognized that at least half the problem lay at my own feet. And while I hope, to some degree, I’ve learned some lessons from being “Rant” a little too often, I feel I’m still seeing way too much of “Rant” in my peers. I see the outright rejection of Azure SQL Database. I see the scoffing at HDInsight. I watch people trying to block the adoption of ORM tools. I see data professionals unwilling to engage with their development teams in areas like source control, continuous integration, testing, agile processes, new deployment processes and more. All this is hurting our ability to influence, in a positive manner, the products delivered by development teams. Further, it’s hurting the businesses that we, data pro’s and developers alike, are supposed to support. Yes, the development teams are going to need to meet us halfway on this stuff, but I don’t see why we can’t be the first ones to offer a hand, to acknowledge our past misdeeds, to stop being “Rant” and get out there and help the people and the businesses we support. If you don’t, it’s your fault.

17 thoughts on “It Is Your Fault

  1. Bravo, sir! Bravo! I could not agree more with your post. I think we’ve all experienced “Rant” or have become “Rant” at one time (or many) in our careers. Innovation will only be achieved through imitation and open minds. If we close ourselves off and don’t offer that hand, we will be left behind, or worse, standing with a huge pile of steaming crap to clean up. Great stuff Grant.

  2. Sad but true. And not only do we have to deal with our own current “rant”s but everyone who came before us. Unfortunately the perception of the data professional is similar to that of the developer from 20+ years ago. We like to work at night, in the basement, and don’t want to talk to anyone. And don’t try to talk to us, we might bite. At least at my office we are having to make a huge effort to get past old perceptions and convince the development teams to bring us in earlier in the process so we can provide more help/guidance where we can.

  3. I agree with you whole-heartedly. I’ve been Rant more times than I’d like to admit and it has always ended badly… I think we as database folks need to learn to explain to development teams *why* the relational model works well and *why* we think it’s the right choice for a given situation. We may not be able to make the decision but we can learn to become advocates and educators.

    Sure, use NoSQL, but know the cost. For a lot of problems it’s worth the cost.

    And, of course, you need to value the relationships. I hate to say it as it goes against habit, but sometimes you have to think about how you express yourself in such a way that even if people disagree with you they still want you in the room.

    I’ve ruined some good workplace relationships by rants. Who knows what the long-term cost of that is…

  4. Well…I see your point. Sure, we bear some of the blame. However, I think the larger problem is that we don’t have decent technical managers. I could cite LOTS of examples where the devs wanted something that made no sense, and I would give my reasons for saying no (and valid ones, not just me being a roadblock) and as a result of managers not knowing right from wrong I end up being put in a corner.

    I *do* get what you are trying to say here. I just want folks to understand that sometimes it isn’t you, or them, it’s the fact that we lack good management in IT these days. This is VERY true in shops where accountants are put in charge of IT teams because “they know the business”.

  5. Rockstar makes a very good point! That’s one of the very reasons I set a goal to manage within IT. I understand the inner technical workings and I’m not solely working on the “I know the business” premise. While it’s important, you need someone in charge that understand the technical aspects. The problem is not too many good IT people make good managers or leaders, and sometimes the ones that would don’t want anything to do with management. Who could blame them! I digress, but fully agree that we need better IT managers.

  6. I think the last paragraph is the most important one. More than ever, there are other alternatives, and sooner or later you can get to a situation where no one asks you if your organization should start working with technology x or not. The managers or architects will decide and just say “get up or get out of the way”. So we better know the new technologies and know what’s suitable when, or we will just be left behind.

  7. Grant, I think the gold from Fowler’s article (and much to the point of your post) is the last paragraph: Fowler’s dead on that we need to break down the barriers between developers and DBAs. This means more reaching out, more teaching, more work from our end, but it needs to start somewhere. This, of course, touches on Tom’s point that sometimes we try to explain and no one in that room wants to listen. There’s no good answer for this, but if we can be seen as the reasonable ones, the part of the equation reaching out, then it becomes harder to shut us out.

  8. Your closing message ‘..get out there and help the people and the businesses we support’ really resonates with me. To that end, I have ‘forced’ myself to learn more about NoSQL over the last several years, both the good and the bad. I must admit, I have built my fair share of Rube Goldberg Machines using what I know about SQL Server. When I start building something that doesn’t seem ‘natural’ in SQL Server these days, it’s a sign to me that a NoSQL store may be better suited for the problem. SQL Server is still my hammer, but I have used relational databases long enough to know when they may not be the right tool for the job. Many NoSQL stores were built to solve problems that relational databases don’t handle well, and it is important for all of us to understand the alternative data stores and continue to guide development teams down the right path. And, it doesn’t even have to be an either/or proposition – polyglot persistence can give you the best of both worlds.

  9. Thanks for all the feedback.

    Tom, I agree with you. My own experience with ORM was not as a roadblock. I saw what they were doing and understood why, so I sat down, dusted off & oiled up my creaky old C# skills and worked through code to understand what an ORM did, exactly. That’s when I first saw the N+1 problems and horrifically bad code that could be generated if an ORM was just used out of the box and inappropriately. So I went to the dev teams and laid out the case for all the places where the ORM tool was going to be great and where it was going to fail and how we could deal with the failures. It was probably the most positive approach I had ever taken. It was utterly shot down in every regard. Oh, and the project which was going to take 18 months thanks the all the cost savings from the ORM tool took well over 4 years (and I’m still not sure it’s delivered) and performance was worse than even I had outlined it was going to be.

    So, I hear you and I’m not going to argue with you at all. But I think the issue is still primarily in our court.

  10. Grant, thanks for the post. I for one am passionate in my job and all the responsibilities that come along with it as a DBA and Data Professional. I think it’s a fine line we walk at times on when to say “No” and when to “Embrace” change. I think all the points you’ve made are valid points and I think a lot of the comments I’ve read are valid as well. Again thanks for the post made me stop and think for a bit.

  11. Great post, Grant!

    I always say “There are no technology problems, there are business problems solved by technology”.

    If DBAs are dogmatic and obstructionist, they lose credibility. If they’re helpful and flexible, they gain credibility. And not with developers, but also with management and the executive suite.

    When DBAs provide insight into how the business operates and help enable that to maximized, they become even more valuable.

  12. I agree with the post and have seen it all too often in my past. This is why I tell so many DBA’s and It professionals in general how important it is to learn to present, listen and understand your customer. We do monthly lunch and learns from the DBA team not just to get great info out but to build a communication bridge between us and the development groups. The better you can help others understand the better off you will be. 🙂

    Great post.

Leave a Reply