What use is a Development DBA?

"I can't help thinking that unless you have a good DBA on a development team and use him or her as a consultant on all database matters, we're all losing out. I end up having work thrown at me that I could teach a trainee to do, which is a waste of my talents, and the development team's database skills might be 'good enough' but could be so much better." Doug Burns assesses the role of the Development DBA and its increasing importance to the success of software projects.

I’m sure that there are many Developers who would respond to that question immediately, with something like:

‘None, other than to obstruct me at every opportunity!’

‘Well, he’d be more use if he stopped breaking things!’

As a DBA, and having worked alongside many DBAs with different attributes and personalities, I have some sympathy with that perspective. As the number and size of databases used by organizations grows steadily, so does the size of the teams of DBAs in these organizations. However, it doesn’t necessarily follow that the developers will have a helpful, skilled resource working with them, to whom they can turn for advice on database matters.

Many organizations don’t even have separate Production and Development DBAs and I think this is a mistake – a strong, development-focused DBA can prove extremely valuable to any database-centric development project. In this article I’ll explain why, starting with a description of the basic role of a Development DBA and then taking a look at how I think a Project Team can extend that role to get the best results from a DBA, and vice versa.

What do Development DBAs do?

A Development DBA looks after and is responsible for the development and test databases. It truly is as simple as that, although I think you should consider this a starting point.

Many of the more experienced DBAs tend to be Production DBAs. The reason is simple – your critical business systems are in the hands of your Production DBAs and you have to be able to trust them to be competent and reliable. If something goes wrong in a development environment, time might be lost, but customers shouldn’t be affected directly. However, implicit in that view is that Development and Test databases aren’t very important, and Production-orientated DBAs often exhibit very casual attitudes towards caring for non-Production environments. I’ve been guilty of that at times, and it can cause problems. While even most developers would accept that Production should always be the first priority, if you’re a Developer, you might have to stop work completely if your database is down. Likewise, an entire stream of Testing can grind to a halt for days because of a single error by a DBA, or if there is no DBA around to help fix a problem or, better still, prevent problems happening in the first place. Developers and testers are often working to very tight delivery schedules and this sort of downtime can be critical.

However, even when a dedicated Development DBA is in the team, he often tends to be underused. Development DBA roles have often been filled by someone who is training and in their first few years on the job (and therefore more prone to mistakes). This can sometimes cause trust issues with the developers.

Ironically, though, it’s mainly because of the time pressures, and fear of a DBA “stonewalling” and further impeding their progress, that many developers are reluctant to engage a DBA too deeply in their projects. If they consult a DBA at all, it will generally be for a fairly routine task such as moving data around or creating user accounts. While such tasks are important, it reduces the role of development DBA to little more than a highly paid operator, with sufficient privileges to do the bidding of developers. This is a real pity, in my view, as a good development DBA can offer so much more to the team than this.

Evolving the role of the Development DBA

Although their role is often the more senior, a Production DBA might only be using a fraction of a DBA’s skills. If a system is configured well, then all that should be left to fix are small intermittent problems, with the occasional recovery. Once a system is implemented, things should die down until the next implementation. Apart from when you hit a severe problem, the pace of work is sometimes a little slower, with more planning and care taken over each action. Massive hardware resources and better tools have also made the job easier. In some cases performance problems are solved by just throwing more money at them.

When the Production environment is reasonably stable, I’d suggest that your best DBAs should take the opportunity to start working more closely with the Dev and Test teams instead of leaving this to the more junior DBAs. Why?

RDBMS software has become richer in features and more complicated in recent years. Most DBAs would be the first to admit that they struggle to keep up with these improvements and, because the core RDBMS engine is often the most stable component, some of the biggest changes are in the addition of tools and techniques that improve the application/database interface. In other words, the operational DBA aspects don’t change much, but the way you develop database-centric applications does. For example, the area that is probably improved most frequently is the SQL Optimizer, on which any application you develop is going to depend.

However, as a Developer you have enough on your plate already, right? Improved languages, APIs, XML and IDEs coming out of your ears! If DBAs struggle to keep up with the current state of RDBMS software, how on earth can you be expected to do so, along with all the developments in your own field of expertise?

That’s where a great Development DBA can be a true asset – as a consultant on all matters relating to the best use of the database. Because, after all, databases are what all DBAs care about! With this thought in mind, here are a few suggestions for making the most effective use of your development DBA, and generally improving the DBA-developer harmony within the project team.

Top tips for DBA-Developer co-operation

The crux of what I’m suggesting here is simply that developers and testers work much more closely with a dedicated development DBA, right from the very start of the project. I’ve seen this work very successfully at many sites, but probably seen it fail at many more. So, let me summarize what I see as seven of the key factors for the success of the DBA-Developer relationship. Three are advice for DBAs, three for developers and the last, and perhaps the most important one, is for both.

What the Development DBAs need to do for the Developers

Be helpful!

Suggest new approaches, tools and features. Developers love learning new techniques but, as RDBMS software isn’t their primary area of interest, they can’t keep up with improvements as well as a DBA should.

Set up short master-classes covering new features or even just the important basics. I’ve seen this work well a few times. Developers start to feel that they’re improving and can be more self-sufficient, and it feels good for the DBA when you see those new approaches start to appear in their code. You’re making a positive contribution. Most importantly, the application quality improves, for the benefit of all.

If you do these things then you can start to provide the tools to help developers do their work more efficiently. Rather than just moaning about the poor quality of the SQL that turns up in one of your databases, you can start to show them how to use utilities to get at the execution plan and teach them how to interpret it.

Just like DBAs, Developers are not stupid and don’t wilfully produce poor database code, it’s just that no-one has shown them a better way, yet.

Understand the pressures that Developers are under.

DBAs are very aware of the need to work quickly sometimes. If a Production database is down it’s obvious that recovery time is crucial. However, whilst we have a strong appreciation for those time-scales, we can overlook the fact that Project Teams are often working to very tight deadlines too, dictated by a business need for an application to go live. The time-scales might be hours and days, rather than the minutes and seconds of a Production problem, but they are still a constant pressure. What could appear to be a small matter of a few hours lost because of a broken database could be a disaster to a test team who only have today left to complete their testing.

Remember that it’s not your database!

A central subject of DBA philosophy is the balance between ownership and responsibility. If I’m to be held responsible for the non-operation of a database (and I will be) then I should have the implicit right to stop anyone from doing anything that will compromise its operation. However, having a say in related matters is not the same as having complete ownership. A development database is there for developers to use, not to keep me in a job and let me practice my DBA skills. The database belongs to the developers and I’m just taking care of it for them. If they do things that screw up its availability, then I reserve the right to say ‘I warned you about that’, but they must be allowed sufficient flexibility to do their jobs and not encounter a scowling brick wall every time they approach a DBAs desk. We are not database guardians, who must be obeyed, but should be there to help and advise.

What the Developers need to do for Development DBAs

Don’t treat them like Junior Operators.

If there is one thing that I hate about being a Development DBA it’s being treated as though my only skills are moving data around with export and import utilities, cloning databases at the file level, running SQL scripts and creating user accounts. They might all be essential requirements but, really, if that’s all your DBAs are doing, you’re probably paying them too much and wasting their talents.

Try to replace requests with questions.

This is an extension of the previous point. If you come to my desk and say, “Here, we need you to run this script to create a bunch of new objects for a new messaging system we’re developing”, what would be the likely outcome? Probably I would run your script and move on. However, if you come to my desk and say, “We need to create a new messaging system, what’s your advice on the possible approaches?” then I would ask first whether you’d considered the RDBMS built-in messaging functionality.

Think of the man-months that could be saved! (By the way, this is a true example – but unfortunately I turned up at that site after the bug-ridden in-house messaging system was already in place). Let me put it this way. If you tell me where you’re trying to get to, there’s a good chance I might know a better route that you might not be aware of. You’d probably be amazed by what a modern RDBMS is capable of.

Get them involved early

I am always disappointed when I see code that replicates the built-in functionality of the RDBMS. Even if it works, I could have saved someone time if they’d asked me at the outset whether there was an easier way of doing this. I have seen too many SQL statements that are attempting to build XML output files or perform simple data integrity checks, when I know that the server could take care of that with a couple of lines of code. The earlier you ask questions, the better. We might not have an answer, but you might be surprised how often we do. It also gives us the opportunity to stop you from following a path that will come back to haunt you later, when it’s too late to rectify.

What Developers and DBAs need to do for each other

Show each other a little more respect.

Personally, I’m a keen fan and eager participant in any DBA vs Developer banter (Storage Administrators are another favorite target of mine.). However, I can assure you that it is only banter, because I know that the truth is that we’re all in IT because we like its peculiar challenges and the fulfillment we get from the job. Oh, and the money! I’m a DBA through choice. I used to be a Developer and I know several people who’ve made the switch the other way. In the end, we all want systems that run well and make the business happy and the fastest, smoothest way to get there is for us to work well together.

You know more about VB/C/Java/Websphere (insert your own particular skills there), I know more about databases. It’s simple. If I want to know about C, I’ll come and ask you. If you want to know more about databases (and that includes SQL), you should come and ask me. Of course, you could Google around for information (which appears to be the default approach to all problem-solving these days), but who knows you’ll find anything if you’re not sure what you’re looking for in the first place?


If more DBAs and Developers could at least try to follow these suggestions, I think everyone would benefit.

The Development DBA? Well, instead of being reduced to a highly-paid operator with the necessary privileges to follow the developer’s strict instructions, we can inhabit an interesting consulting role as a core part of the development team with some design responsibility. We’ll also understand the application more than we do at the moment, so will appear less stupid when discussing it and will understand the logic behind the work that we’re asked to do.

The Developers? It might come as a shock to some, but DBAs tend to know lots of cool and interesting features which can make your life easier for you. We just don’t bother telling developers, because they seldom ask us and they treat us like Junior Operators. Oh, damn, I slipped into that DBA/Developer banter again, didn’t I?

I can’t help thinking that unless you have a good DBA on a development team and use him or her as a consultant on all database matters, we’re all losing out. I end up having work thrown at me that I could teach a trainee to do, which is a waste of my talents, and the development team’s database skills might be ‘good enough’ but could be so much better.

Tags: , , , , , , ,


  • Rate
    [Total: 130    Average: 4.3/5]
  • Anonymous

    Development DBA vs SQL Developer
    In my definition, a good “Development DBA” will have experience in multiple areas. I have found however that the concept of a Development DBA differs greatly from company to company.

    The DDBA should understand production DBA tasks/issues, be experienced in database design/architecture and SQL programming, and be at least somewhat familiar with development in other tiers/languages (UI, mid-tier/business logic, etc.) Only then can he/she guide related parts of the project in the right directions.

    In the MS SQL Server world (where I currently reside), many of the teams I have worked on do not have the budget for separate DBA types – one has to wear all the hats.

  • Anonymous

    Development DBA / Developer / Designer
    I totally agree that it varies from company to company (as does the job title).

    I have been called a development dba, a database developer, a developer, a developer/dba and a designer and all these things tend to be pretty much the same (with some exceptions).

    I find that the best development dba has responsibility for some, most or occasionally all of:
    – Schema design
    – Database interface design
    – SQL & PL/SQL development
    – SQL & PL/SQL code QA
    – SQL & PL/SQL code optimisation
    – Database release scripting / communication / management
    – Testing new database features and implementing as appropriate (together with negotiating acceptibility of said features with production/operational DBAs)
    – Advising operational DBAs of application specific functionality / settings
    – Diagnosing production issues with application specific database activity and this is done as part of the development team rather than the operational DBA team (although
    acting as bridge from development to operational DBA)

  • Anonymous

    source code DBA?
    There should also exist a “source control admin”, an senior developer, which would be the “owner” of the checked in code under source control and responsible to check the quality of what goes in,..

    That could be as beneficial as a DBA can be.

  • Anonymous

    The Definition
    I agree that the definition and responsibilities vary widely from company to company. It’s a constant source of debate in the database community!

    There are so many different roles that can be performed here, including

    – The out-and-out developer who understands the database management issues too. That’s how I started actually, when we didn’t have the budget for a separate DBA. I was a C programmer, so they figured I’d like that ‘low-level’ stuff 😉

    – The Designer/DBA. I remember DBAs used to spend a lot of time on database design and ER diagrams were a big part of our lives. These days that activity has been pulled back into the development teams, but I’ve worked at at least one site recently with a dedicated design team who I’m sure would describe themselves as DBAs.

    – The Release Management DBA (or source code DBA). With complex development projects and multiple test environments, it can be a full-time job just keeping those schemas straight!

    – The Project DBA, who only ever works on one system (for example a Data Warehouse) and knows the code, the model, the operational issues – a bit of everything, but only for one system.

    The Dev DBAs I was talking about were the kind who just look after Dev and Test dbs and don’t really design or code, but could maybe become more involved in those areas to good effect? They tend to exist in the bigger companies I’ve worked for and I think they’re under-utilised.

    Thanks for the comments. Good, thought-provoking stuff.

  • Anonymous

    That last comment was from ….
    Doug Burns, but maybe I have to register before I can post as anyone other that ‘Anonymous’?

  • DougBurns

    That’s more like it
    I’ve registered so hopefully my name will appear on this comment

  • Phil Factor

    Maybe we should WIKI all the IT roles…
    I dispair of the Industry reaching a common understanding and description for the different roles in application development. I keep getting crazy job descriptions which include ASP, .NET, C#, Java and various commercial applications and methodologies AS WELL as everything listed above. Maybe the most useful thing we could do is to start a WIKI that describes in detail every role in the IT industry so that HR depts, agencies and management don’t feel tempted to try the blunderbuss approach to job description.

  • Anonymous

    I agree.
    I completely agree with Doug’s comments here. I am working for client who does not even believe in Dev. DBA. Everything (dev, test, prod), i mean everything DBMS related is handled by the production DBAs. In last six months two of our best prod. DBAs have left the company.
    There is a need for more awareness and openness towards using Dev. DBAs for every DB centric system.

  • Anonymous

    Oracle Specialist
    I would strongly advice all Oracle Developers to try their best to acquire Oracle Administration skills as well..you should not spend all day writing pl-sql 🙂

    in my view they should be only one Job Title:
    “Oracle Specialist” or “Oracle Expert”

    it’s not that hard to learn and you can learn from Experienced DBAs.Good DBAs will Document all Database related tasks so that they could also be done by some other not-so-experienced Admins, but most of them don’t!

    You can only make a Good Database Developer if you also have those Oracle Admin skills,not-all, because the DBAs themselves only know a handful of Features.
    Yes you can ask the DBA about the new Features, but you don’t have to, because they are all documented in the New Features Guide.

  • Anonymous

    Nicely written
    Nice work, Doug — I had only one nit, and that was probably more semantics than substance. I think that database engineers should take pride in their “ownership” of the development databases. More in my blog entry from today…

    Dominic Delmolino

  • Granted

    Nice Article
    That was very well written. I’m currently working in the Dev DBA role. Here, we’ve found that the more senior people are in the Dev environment rather than in Production because that’s where most of the action is. We have to design the systems, help the developers build them, deploy them, put them through database testing, work with the business teams & project managers & qa. The production people set up backups (same script on every server), alerts (same script on every server) and monitor disk space & security. We actually train people up there and then move them, once they’re ready, into Dev. Of course, it’s all SQL Server, so maybe it’s different out in Oracle country.

  • Anonymous

    Couldn’t agree more … I’m one of those rare developers that believes developers really shouldn’t write SQL or design databases.

    A good DBA can run rings around my SQL skills, they can make stored procedures that are so efficient they make my eyes water.

    Just because I can write C# and C++, why does that make me the best person to write TSQL or PLSQL … when a DBA does only one thing all day, write good SQL.

    SO given a choice I want a DBA on my development team, as next best I want the DBA team to be assisting very closely with the development, or as last resort I’ll do the work but complain very loudly that it could probably be done better by getting someone with the right skills.

    And yes, I have encountered the ‘GOD’ complex DBAs many times… after all it IS their database 🙂

  • Anonymous

    Good For Me!!
    As a SQL Server consultant, I am VERY happy that most shops don’t have/use a Development DBA. I have made a very good career out of cleaning up the messes that non-DBA’s inevitably make when they design/develop database applications! :-))

  • GSquared

    Test/Dev DBA
    I firmly believe that the best DBA in the shop should be on the development and testing databases. That will make sure that bad database code/design never makes it into production, where the production DBA has to deal with the problems it creates.

    A query that works well enough in a dev database may cause huge problems in the live database, if, for example, it causes too many locks. That may not show up in a dev database or even a test database, and only show up when it starts running on the live servers. Immediately, your production DBA has to deal with what should have been prevented in the first place.

    This is especially true when you consider that no amount of testing by IT pros will even come up with all the oddball things that real users will try to make your database do. That means the code has to be the best possible before it makes it off the dev server to the test server, and then made even better when tested. That means you should have your most skilled DBA on the dev server. Then the less skilled DBAs on the production server will have better code to deal with, and won’t need as much skill.

    It also means, in case of emergency, the dev DBA can be called on by the production DBA, and will be familiar with the newly released code and can help if it does ever blow up when released to production. If the production DBA is the best, and the dev DBA is an out-of-practice script-runner, then nobody will really know what’s going on in the database and that’s a recipe for disaster.

  • Anonymous

    Dev DBA
    I have to agree with “Good for Me”. Most places I have worked, the DBA was seldom brought in at the beginning of a project and seldom did the database design.

    SQL Server’s front end has given the idea to a generation of developers that with EM or Mgt Studio, there’s no reason to have a DBA. And that thinking leads to a lot of clean up. If folks would check their egos at the door when coming to the office, more real work could get accomplished.

  • Regan Galbraith

    Good article
    I guess my story is similar to many above. I’ve worked as several places that have had varying views on the ‘Data Guy’.

    In my experience, larger organizations tends to have teams large enough to have development DBAs, whereas smaller places (with 1 notable exception in my experience to date) do not.

    The reason I felt I should add in my 2 bits was just to re-enforce the point that strong DBA’s in the developement environment are more than just a nice to have.

    The term I like is ‘quality-by-design’ – and by that I mean that a solution that has been designed as well as possible, is likely to have less problems in live. So, if I am a CIO (and it starts raining pink elephants), I would want to make sure that my development streams today are not creating my problems of tomorrow.

    It sounds cliched, but ‘a stitch in time saves 9’. Put in real terms – how long does it take to realize that there are performance problems in live (i.e. customers have already been impacted), find the cause (live DBA’s having to drop other tasks), determine a solution (that pesky missing index, or badly coded, iterative (someone say cursor??) stored procedure, create solution and (if it involved code changes) re-test and finally implement? How long would it have taken if that same DBA had seen in it the Dev environment?

    The best environment (to date) that I worked in had a pair of LIVE DBA’s looking after the live environment, while I (titled data architect, but in effect Dev DBA) worked closely with the team of 12 developers & architects. Database designs were either done by me, or reviewed by me. Stored procedures likewise. Deployments likewise. Development environment support was my baby.

    I am sure there were times that the developers ‘just wanted a small change’, but having someone whose speciality is databases, in charge of the DOES save projects time, and in some cases, even deadlines – automation of DB environment preparation for builds saved on average 2 days per 2 week project for that company.

  • Regan Galbraith

    Disagree with ‘Good for me’
    I can see why you see benefits for your role, but at the end of the day, having DBA’s seen as un-essential will eventually lead to degrading of all of those who work in the field. Yes, you might be the ‘shining knight’ – but only if the get you in, and until you’ve proven yourself, your a ‘DBA’ – who needs on?

    We, as DBA’s, must make sure that people do NOT tag us with the phrase I first overhead when I started my professional career:
    DBA stands for ‘Does Bugger All’

    That is the tag that we must, at all costs, avoid

  • Skeleton

    Development vs. Production DBA
    I was an application developer, database developer, and DBA for 38 years. Now I’m a production DBA, and all we do is clean up after developers and development DBA’s who don’t live in the real world. We have to live with whatever they throw over the wall, hacking data to fix issues from bugs we can’t get them to fix, because they’re ‘too busy with development’. All of this to satisfy SOX auditors who demand the segregation. They don’t live in the real world either. I retired once, and then stupidly came back as a contractor all because we all have our price.
    If you want development done right, have a support person do it in the first place.

  • Anonymous

    choosing the right path
    now am working as a senior application developer in my company
    and am getting an oppurtunity for DBA which mosrtly involves solving the issues that dev teams make…

    could someone sugggest whether i can stay back as developer or should i become DBA???

  • bharath

    I agree
    Hey Me I am a Devloper DBA, nd totally agree with the article… infact we devloper dba are true winners as we make more friends in the job we do,than a production DBA..opps I have to be later a Production DBA..

  • Leshracevil

    Old article but anyways… I have seen this discussion plenty of times, my point of view is this, either you are a developer and as such you have to possess knowledge of programming languages, object models, design patterns, business domains, relational models (the whole stuff, database included) or you’re not a developer. If your development team can’t figure out a table model of your business, it’s not because you’re lacking a dev dba, it’s because your programmers are just code monkeys. In my opinion, the dba’s have been pushed to datacenter staff. The almighty dba software architect days are gone (back then the systems WERE the databases)

  • marykdba

    I disagree
    OK, so this is a really old article. I have been a "development DBA" for my entire DBA career – and I thought that means I did SQL Server development and light administration vs. being a full-time administration-only DBA. I was responsible for all environments – dev, staging, and production. I created all the databases and database objects. I have never seen an environment where there is a DBA dedicated to just the dev and test environments.