Developers are a pain. They have no idea how to properly write queries and test them against a database. They constantly deploy poorly written code.
DBAs are control freaks that impede progress. The DBAs never let anyone get code written in a timely manner and slow down development.
Both of these are similar stereotypes that exist in the world. I realized that a short while back when I had the chance to talk with Scott Hanselman at an event. He noted that developers are as antagonistic towards DBAs as the reverse is true. We both realized that this is a problem, and that those of us that write and speak perpetuate these views of the world.
I know that we should work better together, and despite making jokes about bad developers, I really don’t dislike developers. This week, I wanted to get some ideas and thoughts from the rest of you about how we can change things.
How do we get DBAs, Developers, as well as sysadmins and Sharepoint administrators, to work closer together?
That’s the poll this week, and I’m looking for specific things you’ve tried or have found to work that break down barriers. We are all working in technology, and we can all do a better job of trying to ensure that we, as an industry, prove that we are extremely valuable to our employers.
I’m also calling on DBAs to be the bigger people here and make an effort to work in a positive way with developers. If you find development practices problematic, then explain why in a calm, respectful manner. If you find deployments to be destabilizing, practice them more often. Try to work with developers, not against them.
Steve Jones
The Voice of the DBA PodcastListen to the MP3 Audio ( MB) podcast or subscribe to the feed at iTunes and Mevio . The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com. |
Voice of the DBA 
Devs need to understand that code must be properly tested under a like-for-like environment and adhere to basic standards. IMO this is best implemented by using templates (CRUD – Create, Update, Delete) and getting them to use these templates for the basic insert, update, delete ops. For DDL, we need to see a justification, how it fits into the overall design/growth plan.
The trouble is, many devs just dash off some code or copy it from the Internet with no thought. Without code standards, DBAs get very, very angry. Why? Because it is the DBA who has responsibility for it. When the dev is waltzing off to the pub at 5.01pm and the DBA is watching the stored proc change wreak havoc on the DB, who has to fix it? That’s right.
Many devs also show basic misunderstanding of DB concepts. [Dev] ‘Can we add another column to table A please?’ [DBA] ‘What data type?’ [Dev] ‘NVARCHAR(8000). It’s a free text field on the web page. And we’ll be querying on it.’ [DBA] ‘No. We don’t have the space. Index maintenance will be a nightmare. It’s a fact table anyway, put it somewhere else and use a key if you must.’ [Dev] ‘We don’t have time. It’s 4.30pm, we must deploy by 5.’ [DBA]: ‘FFS.’ This, and other idiocy, is common.
But are DBAs obstructive? Yes … and no. Yes, we are obstructive in that we are generally anti-Agile, anti-speed, anti-risk. We’ll spend whole days tuning individual procedures. We’ll get excited by tables full of metrics. We embody that popular saying from the children’s book, ‘Hurry Up and Slow Down’. No – we generally do things for a good reason, and try and do everything properly, and only once. The reason your data estate is serving up 20GB/minute at 10% CPU is down to us. The idea of continuous integration and eventual consistency is anathema.
Devs and DBAs will probably never be able to resolve their differences, not until devs learn the meaning of the word ‘quality’ and DBAs are able to relax their guard and become less neurotic about control of the DBs. Neither of which will happen.
LikeLike
True, but how to we, as DBAs, learn to work faster and more agile? I’d say we definitely need to learn to work with developers and bring some of our testing/scale/tuning ideas to their process earlier on. We also need to better explain and defend our reasoning without getting angry.
LikeLike
For me this has been an age old issue, nature of the beast really, I’ve been on both sides of the fence as a developer and as a DBA. No one developer or no one DBA is perfect regardless of what someone may say; we all have our faults but at the end of the day we all have a job to do.
From my perspective a lot of it is communication based that I’ve dealt with. How does the developer approach the DBA and how does the DBA approach the developer. Usually, in most shops, everyone is on the same team yet rarely does that get brought up; instead it is more looked at they are telling me to do something, and why do they want it done that way.
It’s a question I’ve dealt with and spoke on many times in speaking engagements and blogging and one that I don’t know will ever be truly solved, but like yourself I believe it is integral for all of us to co-exist and work together to put out the best products that we can.
Great conversational topic, I’ve also seen the battle between Network Admins as well.
LikeLike
Thanks, and we agree. We know what to do, but it’s hard to get it done. Especially hard to convince others to work together, and not against each other.
LikeLike