Friday, April 13, 2007

Development DBA...

Oxymoron or a good thing?  That is the question - one that I have a definite opinion on.  A database application under development will succeed or fail based largely on whether it was developed by a database savvy group of people - a DBA/Developer and a Developer/DBA set of people.  We don't need a DBA, we don't need coders (developers) - we need Developers with DBA'ish knowledge, we need DBAs with knowledge of the needs of developers.  If you have that - you will increase the likelihood of success in a large way.

Doug Burns has just formally written this up - warning, the link I'm pointing will will actually include "SQL Server" content :)  He wrote "What use is a Development DBA" - check it out.



Anonymous RobH said....

To me Developer and DBA are similar, one just focuses on one aspect vice versa.

I personally believe they are interchangeable (or should be in order to get the knowledge to do the other more effectively).

But this sounds awfully similar to a prologue from a book I read . . . .

(so maybe I'm preaching to the choir)

Fri Apr 13, 10:47:00 AM EDT  

Anonymous Anonymous said....

Each developer in the shop I work in is given an oracle instance to develop against. Before a developer can deploy to dev, all PL/SQL must unit tested. Part of the unit testing involves performance testing. So if you can't be your own dba and troubleshoot your own problems in your own sandbox you are toast. We are our own "dev DBA's". We never actually develop against dev just deploy to dev.

Fri Apr 13, 01:34:00 PM EDT  

Anonymous Gabe said....

Looking forward to the Development Manager (the one pushing to have a Development DBA on the team) discussion …

Fri Apr 13, 03:37:00 PM EDT  

Blogger William Robertson said....

If only life were like that. In most corporate shops I've seen, the database (warehouse, whatever) developers and the DBAs are completely separate and communicate by emails and change request tickets. Then there are middle-tier or Reporting teams in further departments and we never see them or find out much about what they do, except that the middle-tier guys want to get rid of us so they can be more Agile. Sigh.

Fri Apr 13, 06:32:00 PM EDT  

Anonymous Anonymous said....

I guess it depends on if management and the senior developers want a project that actually scales well and might succeed.

Organizations that produce consistently applications like that are working as you described already.

The others ... well ... you know what's going to happen.

Fri Apr 13, 07:09:00 PM EDT  

Anonymous Doug Burns said....

Thanks for the link Tom. You seem to have got my primary message that it's not so much about the job title (that's just a fairly common title at places I happen to have worked) but the skills and the approach.

However, I also wrote about it bearing in mind William's comments which are true of a lot of sites I've worked at too.

"In most corporate shops I've seen, the database (warehouse, whatever) developers and the DBAs are completely separate and communicate by emails and change request tickets."

He has a point, but I also know that not all places are like that and it doesn't mean to say we shouldn't try to change those that are.

Even if we are forced to work in different teams because it makes it easier for managers to get their heads round, isn't some of this down to your personal approach to the job, too? I think that's what I hoped I might influence a little.

(Honestly, I knew that William would probably turn up and start moaning. Typical developer! ;-))

Sat Apr 14, 12:39:00 AM EDT  

Anonymous Anonymous said....

You have been saying this for a while, and I had it in mind when I looked for a new job last year. After years of DBA experience, I now work as a DBA/developer in a group of Java and PL/SQL coders. My manager agrees with me that tuning starts in development and I think this is a good combination. I can also support the core DBA group and bridging the gap between them and development.

Sat Apr 14, 04:39:00 AM EDT  

Blogger Dave Hodgkinson said....

As a CTO, this is a topic close to my heart.

I see this split in code as well: developers and sysadmins (affectionately known as wookies for the noises they tend to make and the slightly musty smell).

It's not the skill set so much: developers can do root-ish things and sysadmins can script, but in *attitude*.

A developer's role is to, well, develop: new features and new code. A sysadmins role is to keep the systems up and performing within acceptable parameters. These are potentially contradictory requirements. New code, new risks.

Equally, when something's live, separated sysadmin funcion is often at a loss when performance goes down the tubes. They'll add memory, put the application on to bigger iron but they won't be able to run dtrace and find where the hotspot in the code is.

Getting the two attitudes working together, having an appreciation for each others standpoints and working towards a common goal is the tech leaders job and a very important one.

Sat Apr 14, 05:12:00 AM EDT  

Anonymous Anonymous said....

Since I started developing professionally, I always took the time to get to know well the databases and OSes I had to develop on, because it was soon clear to me that without that knowledge I had only half of the "equation", and could not take full advantage of the underlying software. It was not my company policy, and often I had to "fight" with the "systems" guys, but it paid.
I am not a real DBA and often I have to look in the docs to find how to I need, but at least I know what and where to look for.
The only drawback is the classic question: "we have a problem, can you give a look at it?" :)

Sat Apr 14, 10:29:00 AM EDT  

Anonymous Anonymous said....

I'm a "development" DBA organizationally, and have to say that I sometimes question the value of this role. If you ignore the Oracle installations that are in the top 10% of the scalability and performance requirements (e.g. corporate life-support OLTP or petabyte DW's) it seems to me that reasonably intelligent developers working with a good DB design can produce and maintain an application that is good enough. When new application requirements come up that could be implemented with advanced Oracle features, it is usally a case of "prove that implementing this in application code on the middle layer won't scale to our requirements", and then it's one development DBA vs. multiple Java programmers looking to add the latest framework buzzword to their resumes.

Again, I'm not talking about the high end stuff...

Sun Apr 15, 01:04:00 PM EDT  

Blogger DomBrooks said....

I operate in the Development DBA / Developer / Developer/DBA space and it depends so much from company to company.

It's a vital role. At least I think so, but I've got a vested interest in that opinion. I wrote about similar last week

There's a big tendency for Java developers to take the database for granted. But when you arrive somewhere where the very good Java Developers are using Hibernate and doing their own database design for very simple relationships and still cocking it up without involving you, you have to wonder.

Where the role and responsibilites are respected, a) it makes for a great job and b) it works from an application performance perspective.

Sun Apr 15, 05:07:00 PM EDT  

Anonymous Anonymous said....

The development DBA role should not be left to a junior DBA becuase the mistakes will be found in prodution by the senior DBA. If the DBA team is doing a good job they are spending more time in dev/test environments and less time in production. If I am spending my days "watching" the production databases and fixing problems there then I have some big problems.

Mon Apr 16, 08:47:00 AM EDT  

Anonymous Anonymous said....

If you are a developer of data management systems it is your responsibility to know what your target DBMS does. A developer who does not build a good relationship with the DBA(s) is incompetent.

Mon Apr 16, 10:23:00 PM EDT  

Anonymous Daryl B said....

My own experience as a development DBA is that developers from around 1990 forward (the beginning of the RAD phase, including PowerBuilder, VB, and progressing to Java) all distrust reliance on database functionality. They want things coded in their language, because that DBMS stuff is "too hard to understand," or "too proprietary". What it really means is that they don't know how to program in, say, PL/SQL or Transact-SQL, nor do they want to have to learn how concurrency control is handled in whatever database they're using.

Finally, this era of developers has moved on to the various database abstraction technologies, including Hibernate, so these developers now kid themselves that all that hard database stuff is now handled (correctly) for them, with no additional effort.

The Development DBA very much needs to be an educator, to overcome these prejudices that lead to poorly constructed applications. Further, the development DBA needs management support. I am depressed by the number of times, after making detailed technical arguments with performance metrics and so on, my technical recommendations are thrown in the garbage with management's approval.

Tue Apr 17, 07:47:00 AM EDT  

Anonymous Anonymous said....

..continued from above..

A DBA who does not build a good relationship with the Developer(s) is incompetent.

Tue Apr 17, 10:24:00 AM EDT  

Blogger Thomas Kyte said....

and to continue the continuation....

A developer who does not build a good relationship with the DBAs is incompetent.

It is a very broad, two way street.

Tue Apr 17, 10:35:00 AM EDT  

Anonymous James Barton said....

There are serious cultural problems, and I'm not sure where they start. I've moved from PL/SQL development to basically being Development DBA to a large team of Java developers. One conversation that stuck in my memory involved me suggesting to a developer that we should really get the data constraints in the RDBMS if at all possible. His view was, IIRC, that they would be easier to maintain if they were in the Java layer. The guy in question was both smart and hard-working, but I just don't think he saw the value of the database.
I suppose the attitude of many developers is similar to the Not Invented Here idea, but based on toolsets rather than companies.

For myself, it took a while to realise how important it was to do the database development properly - I didn't see how much it mattered until I saw a database that had gone horribly wrong, which was poisoning the applications written against it. I think newbie developers may need to see how badly things can go wrong before they can appreciate the benefits of Doing It Right.

Tue Apr 17, 12:54:00 PM EDT  

Blogger Cantalopian said....

The horrors I have seen...constraints deeply embedded in java code, battleship sized compiled code layers, dynamic sql executed over and over again. Vendor experts coming onsite at 250.00/hr to fix code.
The horror!

Thu Nov 19, 02:39:00 PM EST  


<< Home