By Joshua Feierman, 2014/02/07
As a DBA, though you would like very much to avoid it, sooner or later you will encounter the frightening creature known as The Developer. In the wilds of the development environments they often roam unfettered, with sysadmin level access for all and nary a stored procedure in sight (because they prefer the use of tools such as Hibernate and Entity Framework, rather than actually learning to write SQL and design databases). But, like it or not, these animals are actually the life blood of the companies you work for.
In my previous article, Five Rules For Effective Conversations With DBAs, I came at this seemingly never-ending conflict from the perspective of a developer trying his best to get along with the neighborhood DBA. Now, we are going to switch sides and see how DBAs can also work better with their counterparts on the development side. I've been in both seats, having moved from development to support and back again throughout my career in IT, so I can see both sides of the equation. And believe me, while I was harsh on the developers, I'm going to be equally harsh on those of us on the production front lines.
If you read my previous article, you will see some overlap here, because some of the principles apply both ways. But at the same time, there are some things that we as DBAs have the unique power to do that will help forge a mutually respectful relationship.
So, without any delay, and in no particular order, here are my top five rules for DBAs to follow when dealing with those who call themselves "Developers".
Rule number one: Be a teacher, not a bully
When developers come to you asking for things, there will probably be times when the things they are asking for are so blatantly wrong that you feel the overwhelming desire to yell (in your best Gunnery Sergeant Hartman impression) "What is your major malfunction?!". Do yourself a favor: take a deep breath, count to ten, punch a wall (okay, perhaps that one is not the best option), whatever you need to do to calm down.
Look, I get that you think that anyone who honestly thinks that an account needs sysadmin rights to execute a stored procedure deserves to never again see a keyboard. But remember, you probably have the benefit of years of focused time working with SQL Server, whereas developers are (at least in my experience) generally expected to be Jacks Of All Trades. Perhaps they haven't had the chance to experiment on their own, or this is their first time working with the platform. Either way, you have a unique opportunity to shape their skills and help them be better at their job.
Instead of bashing them and berating their every effort, offer to take them under your wing and teach them how to do things the right way. Maybe they will refuse and stubbornly insist that their way is the only correct way (in which case feel free to point them to point numbers three and four of my previous article), but you owe it to yourself and your company to give them ample chance to learn.
Rule number two: Build them a toolbox
One of the best ways to increase the communal SQL Server knowledge is via a shared script library, where the best and brightest SQL Server folks (which may often be the DBAs) in the company can put pre-written examples and templates for use by others. This can come in extremely handy when folks come to you asking for help completing some task related to the database layer of their applications, since you may well be able to hand them a pre-approved, efficient example of how to accomplish exactly what they are asking. It also can serve as an effective tool for enforcing best practices; if you think about it, it is far easier to say "No, you can't do it that way, but let me give you this script which shows how to do it correctly," versus "No, you can't do it."
Let's take a simple example: the need to convert a date/time to the effective beginning of the day. Maybe you see this in some code you are reviewing:
set @start_of_day = cast(cast(datepart('year',@date) as varchar) + '-' + cast(datepart('month',@date) as varchar) + '-' + cast(datepart('day',@date) as varchar) + ' 00:00:00' as datetime);
You simply point them do your nifty little script, where you use the much more manageable:
set @start_of_day = dateadd(day,datediff('day',0,@date),0); That's a simple example, but a powerful one. Over time, you can build up quite the library of commonly needed code. You can even include more complex things, like a set of standard scripts for setting up Service Broker connections between servers. I've seen this taken so far as giving developers a compiled program that will auto-generate standards compliant CRUD stored procedures when pointed at a database. This was received with great appreciation and went a long way towards helping folks write better code. So feel free to dust off your programming skills and go nuts. Not only will you be helping to make things easier for your developers, but you will also save the company time and money.
Rule number three: Don't include the world in your communications
This one is a complete repeat of the same point my previous article, and I am going to hold you to the same standard. I know that it really irks you when those pesky folks call you out in public, especially when they are completely wrong. And I know that you really want to illustrate to management how horrible that person's skills are, and how they should be instantly banished to the nether-world, never to code a line of T-SQL again. But, returning fire or initiating the first volley in the open will result in nothing but resentment and further the image of the Bully DBA. Be the bigger person and make it a point to (a) not respond in kind, (b) take all critical conversations off the public thread. Then, when the two of you have worked out your differences privately, you should feel free to respond to the group indicating that you have reached a mutual understanding.
You will end up looking like the mature and socially graceful individual you are (well, it's something to strive for at least, right?), and you may end up getting yourself some valuable credibility with your developer comrades for not humiliating them in public. "Why should I care about credibility with those [insert insulting name here]," you ask? That's easy: because that street cred will mean you have a better chance of getting them to follow your (come on, admit it, slightly anal retentive) rules without a full out battle.
Rule number four: Don't judge a book by its cover
Look, I know that you have had to deal with some truly incompetent developers in your time in IT. And over time, it's only natural to start assuming that every new developer you work with is a member of that bunch. But that's not fair to those individuals who truly care about the craft of engineering software. I have met some people who have incredible talents in making Transact-SQL sing, and take the database side of their work as seriously as any DBA. Equally important, I have dealt with folks who, when I first met them, seemed so totally clueless around SQL Server that I considered attempting to have them banned from doing any work in that area. But, given time and (a nod to my earlier rule number one) some coaching, they matured into very good SQL developers.
My point is this: don't go into every interaction you have with the mindset that the person opposite you is inherently incompetent and needs to be beaten into submission. This attitude will only serve to alienate the good developers and destroy any chance you have of finding a diamond in the rough. Outside of that, you'll likely come of as a condescending jerk, which, at least in my mind, is something we'd like to avoid.
On a related note, let's not forget that for every incompetent developer, there is probably a corresponding equally incompetent DBA out there. You are no more immune to laziness and apathy than our counterparts, so get rid of your righteous "better-than-thou" attitudes.
Rule number five: Remember what they are paid for
As I told the developers in the audience last time, you need to understand where your counterparts are coming from if you are going to get out of the cycle of endless war. And when it comes to developers, the answer is equally simple as with DBAs: developers are paid to deliver results. If they can figure out a way to meet their business requirements on time, but doing it your (standardized) way would result in them missing their timetable, expect an argument, and expect a passionate one. In some cases their pay may be directly tied to the product shipping on time or some other effort based metric, and by trying to make them follow the rules, you will be perceived as threatening their livelihood. They are not going to care about your law against using ORM tools because of how they cause plan cache bloat; they only care that writing all those stored procedures means many nights of late work if they are going to get their work out the door. And frankly, I think they have every right to be upset if you try and push arbitrary changes on them late in the game, especially if they did the right thing and involved you early on in the process.
So how can we overcome this difference? A good first step is to try and insert yourself as early in the development process as possible. Talk to the development managers to make sure that you are invited to their whiteboard sessions and have a chance to review all design documents before work begins. This way, you have a better chance of catching bad designs before work is done, thereby eliminating the classic "But we've already written it this way and it will take twice the time to re-do it" argument. When developers realize that they can follow your rules without greatly impacting their work, I've found they generally are pretty amicable to doing so.
Another simple action that will go a long way is to make sure that your guidelines are clearly published and accessible, so that teams can see them at all points during the process. Hold regular town hall meetings where people can come and propose new rules, and let people outside of the DBA realm have a vote on what changes get made versus what gets thrown out. Transparency and communication are key. And while I'm not going to go into a lot of detail on this last point (that is a whole separate article I'm writing), I think we need to be very conscious about the differences between something that is a truly worthy of being regulated, versus trying to force others to follow our own particular style. Suffice it so say, keep your standards as lean and simple as possible. Think of them as a basic "SQL 101", where as long as you follow these, you have at least a chance of avoiding the bane of poorly written database code. If your list of rules is starting to look like the federal tax code, you're definitely doing it wrong.
As I stated in the counter article to this one, the relationship between developers and DBAs will always be contentious. Whether you are deserving of the reputation or not, DBAs are often viewed as tyrannical and hard-headed. While a little of that nature is generally a good thing (do you really want someone who will fold under pressure protecting your critical systems?), thinking about some simple ideas such as those presented here will go a long way towards breaking down those perceptions. And once those barriers are removed, you might be pleasantly surprised at what can be accomplished when the two sides work together.
View original article
Five Rules For Successful Conversations With Developers
