Developers vs. DBAs: Keys to Successful Cohabitation
Successful enterprise consists of numerous individuals with various backgrounds and interests. There are successful mom-and-pop companies out there, but those are few and far between larger companies employing dozens to thousands of folks. If you work for an entity of medium to large scale, you'll have to learn to understand—and, in some cases, appreciate—differences in opinions and preferences between you and your colleagues.
Software developers and database administrators (DBAs) have jobs that might appear to have opposite interests: DBAs try to keep databases as secure as possible, whereas developers try to get access to certain SQL Server functionality or production databases that they're not permitted to use. Due to such differences in responsibilities, it's not uncommon to see DBAs and developers in conflict, often to the point of slamming their office doors and avoiding each other in the hallway. In this article, I'd like to offer some pointers for successful and peaceful collaboration among software developers and DBAs.
We Have Something in Common
I've been on both sides of the fence. As a consultant, I've often had to work with DBAs who tried to make sure that I wouldn't hack their systems. They would even complain about me having administrative access to the Developer Edition of SQL Server installed on my desktop. As a production DBA, I've worked with developers who wanted to put a Profiler trace on the production servers during peak hours of end-user activity. Furthermore, I once had a developer drop the MSDB database and even attempt to drop the TEMPDB database!
Both parties have a common goal: making the company as successful as possible. I'm very glad that I've experienced both sides of the coin, because I can find commonalities with developers as well as DBAs. In fact, the best way I've found to resolve arguments between the two trades is for each side to find something in common with their peers.
Developers and DBAs typically disagree on at least the following issues:
- Letting developers have an administrative account on development or quality assurance (QA) servers
- Running SQL Profiler traces on any database server
- Transact-SQL code reviews
- Choosing one coding style over another
- Choosing naming conventions for database objects
- Deciding whether business logic is implemented in business tier or in stored procedures
I'll discuss each of these arguments briefly and offer my opinion of how each of the issues should be resolved.