I know I’m a weirdo. I’ve always been a weirdo. When I was a DBA (now I only play one on TV), I was a weirdo too. Case in point, ORM tools. Whether we’re talking nHibernate, Linq, or Entity Framework, the degree of loathing for these tools by most DBAs is really hard to measure. Yet, after an initial period of difficulty (here are some ancient blog posts documenting that pain), I’ve come to believe that code generation tools are a very important part of what we do. Further, that they are not evil, or wrong, or bad.
Let’s talk about this just a little.
A Tale of Two Teams
At my previous employer there was a degree of friction between the developers and the DBAs (shocking, right). Both sides held some of the blame. Heck, I was personally responsible for some of it (I got my Scary DBA nickname at that company). It ultimately resulted in one development team simply dismissing the DBA team entirely. They went off, and did their own thing. One thing they introduced was nHibernate.
If you follow the link above, I detail some of my early work with nHibernate. Let me summarize it here. I used to be a coder (or developer, whatever the cool kids say these days), so I have the basics still. I went and learned how to code nHibernate. I set up a test system. I walked through a bunch of examples online. I had a fully functioning system.
Then, I took off my developer hat and put on my DBA hat. I looked at what was delivered from that process. Frankly, it wasn’t pretty. There were problems. So, I documented them. I researched. I figured out how to solve most of them. Some were only solved by using stored procedures, but only a few. I delivered this document to the team, so that they could avoid the problems I hit. I was dismissed because I was the enemy.
At the same time, another team of developers at the company, who I had a wonderful working relationship with (not being a jerk, we really got along), started using Entity Framework. I did the same thing. Put on my dev hat and set up tests. Put on my DBA hat and evaluated the tests. I went back to the team with a set of recommendations. We implemented them. We had a wildly successful project that delivered faster than any other, comparably sized project in the company.
Oh, and the other team, they were about three years late on their delivery cycle, the project didn’t work, required an entire second database to be built and a customized, near real-time, replication process to get the data into it. Nightmare.
I came to several realizations because of this. Most important, don’t poison your relationships with people in your organization or you lose the ability to influence them. That’s number one.
But, from a technical standpoint, what I learned was, team work and communication are important. Listening to people is vital. The developers were insistent that the ORM tools would help them speed things up. They were right. However, some of the code generated by the ORM tools (and all of the data structures) were problematic. I was right. When we listened to each other and worked together, we built something great. All it required was a few changes on their end. Not much.
So, the key here is not that ORM tools are magic and you need to surrender all control over your database and let the developers do anything they want. Please, hear me. THAT IS NOT THE MESSAGE!! (and yet, I know, I’m going to get those responses in the comments).
The key is, every tool is capable of evil. Every tool can be used badly, poorly, with ignorance and stupidity. However, just because you’ve seen a tool used in this fashion, that doesn’t make the tool bad. It’s entirely possible through education, testing, documentation, and, yeah, teamwork & communication, to make that tool work well. Throwing out a tool because it was used poorly pretty much means we can’t have any tools at all, because they’ve all been used badly at some point.
Also, another point, just because you can’t see the purpose, intent and benefit of the tool does not mean it’s not there. Education is very much a two way street. We can also afford to learn new things. It is possible through ignorance or prejudice, you can’t see the benefits. Part of teamwork and communication is placing some trust in the intent of your partners. Work from that position of trust.
If you’re interested, I’m doing an all day seminar at SQLBits talking about DevOps for the DBA. It doesn’t cover ORM tools in any way (huzzah!). However, it does spend some time talking about teamwork and the need for communication and automation, trust and validation of the same. Please, follow this link and join me.