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.
Conclusion
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.
Still here?
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.
I think part of the problem with ORMs such as NHibernate is they have been sold to your average joe developer who just wants to get it done quickly and easily and forgets about scalability (that apparently is our DBA problem) – but in a typical dev team DBAs don’t get a vote – we are outnumbered 10-1 (at least)
I’ve given up on entity frameworks (purely because it is junior devs making code that I will have to mop up in 2 years) as a DBA you wouldn’t expect it, but i’m liking NOSQL and queueing systems
I absolutely see bad implementations. If I was to point to a serious weakness, I’d say that the size and depth of the hole you can dig with these tools when they are used incorrectly is excessively large. However, again, the problem is the bad choices, bad development, bad knowledge. The tools can work and work well. They just have to be used correctly is all. There are great developers out there showing people the right way to do this stuff. Julie Lerman is the first one off the top of my head. Unfortunately, there are also a ton of bad examples showing the wrong way of using them.
Fabulous words about the battle between ORMs, DBAs tasks, and proactive
teamwork! Thanks for your knowledge.
As with many many things, communication is key. Great post, Grant.
I had a very similar situation in my previous role, and ended up with a soured relationship and a dev team going rogue. Now in a new role and I’m seeing a lot of Entity Framework being used. I’d love to have a more positive approach. I’d really appreciate any resources around how to work proactively with EF.
Speaking as a DBA-type, set up monitoring as early in the process as you can, so you can see the code being generated. There are positive patterns & anti-patterns you can look for. I don’t have them heavily documented myself. Names I would look up, Brian Randell, Julie Lerman, Chris Woodruff. These are dev types that I’ve talked to and worked with over the years. They get it. They recognize the need for coordinated teams. Communication is a driving factor in all they do. They are the developer models we want others to emulate. Plus, they’re really smart and capable people who do amazing work.
Good post. Good communication and team dynamics can extract the useful aspects of ORMs, and other tools, from their more negative consequences. We are a small group and have a DBA as a half-time member of the dev team. Communication is pretty much constant with the dev process. We have been using EF for over 10 years and have developed T4 templates for code generation on the DB and middle tiers to automate what would otherwise be tedious code to write. Much of that replaces what EF would do natively. EF still generates some awful SQL left to its own devices in some situations and it is possible to intercede with overrides. The fact is however, noticing the problem areas is not always easy in the development process. The DBA plays a critical role in detecting problems brought on by EF generated components and provides a direct feed-back link from what is happening in production systems using earlier releases.
To sum up: Teamwork.
I’m behind it. 100%
Good points, good article. In my experience, code automation tools can be very nice if used in limited situations. When you try to use them to accomplish everything (within their domain) they can become more trouble than they’re worth. I think the biggest problem with most of them is that they were designed to try to handle EVERY case. Which makes them complicated to use and can lead to “issues” with poor code being generated. I wrote my own ORM years ago. It just creates the basic objects I need in the format that I want them in. It certainly wouldn’t work for everyone, but it’s saved me years worth of coding time.
By the late 90s I was writing my own scripts to read database metadata and generate stored procedures and application data access code. I am lazy and easily bored, so it was a no brainer. I became happier and a lot more productive. As an added benefit, automating coding reduced errors in the code. Did I mention I hate debugging?