Situation: The dba is an offsite contractor who keeps the entire DAL code checked out in TFS. It would be nice as the front end developer to be able to add columns, and tweak procs and whatnot, without having to rely on waiting for this dude to respond to your emails to do the work.

Question: What would be a recommended solution/process that would allow for more rapid/agile development, while maintaining data integrity as well as peace love and happiness among the team?

  • I am worried here about why did you need to add a column and what business rules are associated with this column. You may find ways around it and eventually add the column but what if you used the wrong data type, null settings, index definition, worse what if the column should not belong to the table or if you are missing an intersection table altogether? I think someone must be responsible for the business impact of defining new data and also someone should be responsible for the impact of a database change on the code (other than the DBA). The 2 roles may be played by the same person.
    – NoChance
    Sep 14, 2011 at 13:52
  • Require the DBA To work in his own branch. Do not give them checkout rights to the main development branch. Alternately create your own dev branch and merge your changes as needed. Sep 14, 2011 at 18:59

7 Answers 7


Martin Fowler and Pramod Sadalage have written an excellent article on this subject.

Every developer has his own database to which changes can be made. These changes are then communicated back (as a changeset) to the DBA who implements them in the master database, so he's still involved in the process, he probably knows best about the structures and needs of the database anyway. I think that's the best approach as it's satisfactory for all people involved in the process and it's also very agile.

You can change the DAL in a similar manner. Just make your changes and provide a changeset for the DBA when you think you're done, so he can review it and merge it into his master.

  • 1
    oooh i like... this is my first Q here so i cant upvote yet but you got one comin for sure... maybe/probably the answer too, but i like to wait a bit to see what other people say Sep 14, 2011 at 13:27
  • The problem with this is that the developer does all his work on an assumption that the dba will approve.
    – HLGEM
    Sep 14, 2011 at 14:23
  • @HLEGM: In my experience this is a seldom case, most of the times the DBA will approve it or change it only slightly. It's still better than having idle devs sitting around. Moreover, it will probably lead to the best solution if the DBA and the dev are both reasonable people.
    – Falcon
    Sep 14, 2011 at 14:26
  • +1 for explaining why this is an excellent article instead of just posting a link.
    – JeffO
    Sep 14, 2011 at 14:44
  • @HLGEM - I think it requires both parties to justify what they are doing. The DBA should get a benefit of the doubt in db matters, but both have to answer to someone else who would have the final decision.
    – JeffO
    Sep 14, 2011 at 14:47

Wellll, when I'm doing the DBA thing, I have been known to lock everything up so the damn dirty programmers can't get their mits on it. Everybody thinks they know how to do it better, and they "tweak" things to make them easier for themselves, and it causes an unholy mess.

The other alternative is to throw it wide open, and let the programmers melee on it for a while, then jump in and impose order as things begin to wind to a close...This is certainly more "agile", but it can be a real nightmare depending on what has to be cut out or changed...DBAs often have a better understanding of the project as a whole, and some changes that seem innocuous can be problematical.

If he's going to be the sole gatekeeper, he needs to either have a fixed spec, or be able to "sell" his vision to the rest of the devs.

  • we are pretty damn dirty... and sometimes we are pretty damn impatient as well and need to get stuff done ourselves Sep 14, 2011 at 13:32
  • @spaghetti: Yea...I'm probably worse than most because I've done a lot of DBA work, so I have twice the "I know how to do it better!" than most programmers. I will say this: with databases, it's a lot more important to get it right early...If you keep adding until late in the project, it's almost certainly going to cause issues. Sep 14, 2011 at 13:35

There is a major problem that supercedes any other problem:

  1. Why does the contractor always have the code checked out?

Why is he allowed to do this? No one should have a file checked out unless they're actively making edits. There should be a team policy about checkouts.

The contractor (whether they like it or not) works as part of a team, and sometimes other members of the team may need to make changes. This is a communication issue. There's no automated way to fix this communication issue, unfortunately.


Instead of horizontal layers, I prefer to work in silo's across layers.

That way no 1 person/team can block in this fashion.

It also means you're developers are multi-skilled and able to move around features much more easily.

Of course, there are sections (UI design, and DB design) that may need more speciality work, but you get the idea.


Simple, If you don't already, you should have a 3 Environments:

  • Development Environment
  • QA Environment
  • Production Environment

The develoment environment should be administered by your developers.

You might also want to add an RC environment.

Another answer, If multiple environments isn't possible, you could develop against a mocked repository... This way you build your models and then your contractor is responsable for making your models match the DB. In a way this is better since it frees your developers from worrying about the database.

  • 1
    The OP is talking about code that is checked out. Differing environments would not have an impact.
    – NotMe
    Sep 14, 2011 at 15:39

You problem appears to me to be one of manpower. It is apropriate and necessary for all potential daatbase changes to be approved by a database specialist. If the current person cannot keep up with the work in a timely manner, you need more database specialists.

  • +1: This can also be a cause of the problem. Many companies have too few DBAs.
    – Falcon
    Sep 14, 2011 at 14:50

This is a management issue as much as a technical one.

There are certainly valid reasons for a DBA (regardless of whether onsite or off, contractor or employee) to keep developers away from making any type of database changes.

However the main issue you defined is one of availability. Does your manager know that time/money is wasted waiting on this person? If not, you might want to bring it up how everyone is sitting around.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.