I currently write the editorial for the PASS Connector which is published every two weeks as part of my role on the Board of Directors. I'm cross posting those editorials here as well as to the main PASS blog.

I recently had the opportunity to attend the Jacksonville Code Camp, a great event with 8 tracks and 460 attendees! As you can guess from the title the focus is developers, but developers do some data access and so there was one SQL track – the main reason I attended. As I sat through some of the SQL presentations (all well attended) what struck me is how much of a gap remains between developers and DBA’s.

Some of that gap is the nature of the way we train developers and DBA’s – on the job. That’s a practical strategy, but it also means that our early views of how the world should be are shaped incidentally. If the first job a developer has is for a company that doesn’t have a DBA and doesn’t do a lot of data access, it’s easy for them to see data access as something less than interesting. Or if the first job is with a company with a really tough DBA, they may see DBA’s as an obstacle rather than a helpful team member.

Some of the gap is responsibility. DBA’s feel the weight of down time, data loss, security breaches in a way that few developers do. It’s not that developers don’t care, but they have the insulation of QA, testing, and not having access to production.

Some of the gap is the way we’ve divided up the teams. Having DBA’s and developers on different teams makes a lot of sense for many reasons; separation of duties for SOX, cross training with others will similar skills, etc. The separate teams aren’t innately bad, but in practice they present another hurdle to communication.

Over time all of those things and more have created a real divide. I don’t know that we can fix it in one editorial, but here are some ideas for you to think about:

• Developers
• Remember that data is the life blood of the business and DBA’s are tasked with keeping it safe – understanding that point of view will help you bridge many gaps
• Good design and data access does matter regardless of the number of planned users. Doing it well doesn’t take much more time than not
• Treat your DBA as a valued consultant. You’ll get better results if you show them the problem than if you give them the solution
• DBA’s
• We can’t afford to be road blocks for the sake of ideals. Time to market demands often force businesses to take short cuts. Help them make smart choices about where to short cut and where to invest a bit more effort
• Don’t expect developers to be SQL experts! They should write their own procs and more, but don’t expect them to design a solid indexing strategy for you
• Get in the game early. Start sitting in on the planning meetings with developers so that you can offer some sage advice when the cost of change is low. Remember the first point – sometimes corners will have be cut, be flexible and show them the pitfalls as you see them

I think there some things PASS can do to make the developer/DBA relationship work better, but ultimately it comes down to people – an analog solution to be sure. If you think about it, it’s really more than being a good DBA or good developer, it’s about being a good team player and a good employee. Try to worry less about your concerns and focus on helping other people get stuff done. Someone has to go first – why not you?