9

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?

spaghetticowboy
  • 193
  • 4
  • 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 '11 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. – SoylentGray Sep 14 '11 at 18:59

7 Answers7

11

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.

Falcon
  • 19,248
  • 4
  • 78
  • 93
  • 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 – spaghetticowboy Sep 14 '11 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 '11 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 '11 at 14:26
  • +1 for explaining why this is an excellent article instead of just posting a link. – JeffO Sep 14 '11 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 '11 at 14:47
  • This seems like a good answer to me. The DBA is probably most concerned with making sure that a bad check-in doesn't wreck the database. – jprete Sep 20 '11 at 00:58
3

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.

Satanicpuppy
  • 6,210
  • 24
  • 28
  • we are pretty damn dirty... and sometimes we are pretty damn impatient as well and need to get stuff done ourselves – spaghetticowboy Sep 14 '11 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. – Satanicpuppy Sep 14 '11 at 13:35
3

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.

George Stocker
  • 6,388
  • 2
  • 31
  • 55
1

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.

ozz
  • 8,322
  • 2
  • 29
  • 62
1

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.

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

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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
1

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.

NotMe
  • 1,063
  • 6
  • 13