I was listening to a podcast on nHibernate this morning. Most of it was very good, but there was one section that absolutly made me see red.
The guest on the show was asked how the DBAs felt about the use of nHibernate for a new app on an existing (old) database. The reply essentially was ‘We haven’t told them and we’re not going to tell them.’ Apparently the plan was to only tell the DBAs about this app if there was a problem with it in production
Now there’s a whole lot of problems with that scenario and I can sum most of them up in one word – Trust.
If an application was mostly to be written in C#, but there was a critical portion that depended on (say) Biztalk no one would seriously suggest keeping the biztalk expert on staff in the dark and doing it completely themselves. So why do developers do that with databases?
I’ve often heard developers complain that the DBA doesn’t trust them. Guess what, pull this kind of stunt and they’ve got a good reason for not trusting those developers. Go behind someone’s back, hide stuff from them and they’re not going to trust you. No big surprise there.
The whole ‘them and us’ attitude that a lot of developers and DBAs have is, quite frankly, stupid and highly counter productive. The DBAs are the ones responsible for the database portion of custom apps after they become production, they should have some input during the development phase whether it be on the database design, the stored procedures or just ensuring that the app will scale to the required production load.
So, in conclusion…
Developers, speak to the DBAs, get them involved in projects early. You may be surprised how much value they can add to the project and how much smoother things can go when everyone’s working together instead of fighting each other. Of course, if your DBAs are the arrogant, overbearing type that give the profession a bad name, if may not be that easy.
DBAs, if you know that the developers avoid you, hide projects and prefer to go their own way, first take a look at your own behaviour. Ask to be involved in the early stages of development. Chat with the developers, see if there’s anything that you can help out with or any areas that they need assistance. You may be surprised how many problems can be ironed out before they become problems in the production environment. Of course, if your developers are they type that triggered this rant, it may not be that easy.
</soapbox>
Excellent comments. Both sides are guilty.
Excellent article.
I find it quite disheartening that there seems to be a presumption between these two parties that there will be some form of resistance to one another, perhaps at times even before a project has begun.
As you discuss, communication is indeed the key. Collectively we share the same fundamental goal after all, to deliver solutions and services that perform to their utmost potential, in order to meet the business objectives.
It is high time that this presumption be swept aside and laid to rest.
Pingback: Developers vs DBAs | John Sansom - SQL Server DBA in the UK
Great points Gail! I have found that in most cases where the attitudes described above exist it is mainly due to the fact that they have found little or no value in having the DBA be a part of their process. Some of that may be due to past experience and I can give some flexibility for that. However, we as DBA’s need to ensure that we are providing value to the development process.
I know that when I have run into those attitudes in the past they have been easy to overcome and would often open a literal floodgate of questions / support requests from developers who truly want that expertise on the database layer.
Thanks again for the post and the points!
Great one Gail, simply remind Developers that according to Law – at least in Canada and the U.S. we must comply segregation of duties (govt or public orgs.): http://www.sqlservercentral.com/blogs/hugo/archive/2009/02/15/the-importance-of-the-segregation-of-duties-with-respect-to-internal-controls.aspx
I like this discussion. There is forever fights between developers and dbas. If we work together in stead of against each other much more will be done
The OO purists consider we, DBAs, a relic of past (‘since well designed class hierarchies always get optimal SQL from |persistence framework of choice here|) and databases is just an sofisticated file system that serves their class hierarchy. And they teach this on school!
That’s why DBA cannot trust developers: many developers are trained to think DBA are just an ‘useless annoyance’ and the persistence framework is just their business – if let alone, they would even let the framework create the database design without review.
But when they slam SQL Server because a index scan caused a LOT of shared locking and stopped a lot of the company operations, guess who they call…..
I’m tired of hearing that kind of BS…