Rethinking Agility in Databases - Part V: Collaboration

Skip Navigation Links

Rethinking Agility in Databases 3/28/2008 6:25 AM

view as multiple pages

By Max Guernsey, III - Managing Member, Hexagon Software LLC

Introduction

This episode is definitely a divergence from this series. At least, in a sense… in previous installments we talk about how Agile practices in the database world must differ from their software counterparts. Here, we will talk about how an Agile practice (XP really deserves the credit, if I’m not mistaken) can be ported straight across to databases as a way of reinforcing the other methodologies we’ve discussed.

While databases differ from programs significantly, the people who work on them do not. Programmers are people. Testers are people. Business analysts are people. Guess what? DBAs are people, too.

As you are probably aware, by virtue of monitoring this series of articles, we recently put on a seminar on changing Agility in the database world. This series went very well – better than we could have hoped, really – and one of the great unforeseen products was the set of questions asked.

One of the attendees seemed to be sold on the methodologies and raised a concern that I had not really considered. It’s kind of funny because I’ve dealt with it, I just didn’t consider it in all of my preparations, in the development of DataConstructor, or in collaboration with any of my friends. The problem is that he has to get buy-in from the people who currently have the keys to the databases.

The Problem

Database developers are accustomed to SQL (and DDL… and DML). It’s what they are good at and it’s what they understand extremely well. As a result, a lot of them want to see a SQL script when the time comes to deploy. Even though a DataConstructor script is usually about 95% SQL, they are usually still going to push back if you just dump a DataConstructor script in their lap when it comes time to deploy.

An attempt at circumnavigation would be a mistake. First of all, DBAs usually have considerable political clout. After all, they are the guardians of the sacred temple which houses one of your company’s most precious assets: information. More importantly, and less likely to fade away over time, DBAs are good at database development. In insulating yourself from their political leverage, you are failing to capitalize on a resource that could add a considerable amount of value and quality to what you deliver.

A Solution

I am not the “great persuader.” I am not even “a good persuader.” I’m more like “Dr. No,” in real life, to be honest. So, by no means, should this advice be taken as canon. However, after a few days of reflection, I’ve come to the conclusion that there is really only one way to handle this problem. You’ve got to get the database people to own your tests.

You, of course, will need to own the tests, too. When you own something and someone else owns that same thing, what do we call that? We call it a partnership. What I think you need to do is bring them in early. Get buy-in before it’s time to roll out your database. Get buy-in as early as you possibly can. What is the earliest point in time that you can possibly include a DBA in the process? It seems like it has to be when you are writing your database tests.

DataConstructor is a tool that lets you express things as mostly SQL – the language in which DBAs are comfortable – while making sure your database growth path is will tested – a space in which programmers can shine. I would bring the DBA into your office. Explain to them why you want to use transition tests, why you want a predictable build tool, and why plain SQL is not really good enough. Maybe tell them that, since you’re just getting started, you were hoping they could give you some insight on the kinds of tests you need to run.

Once the stage is set – once the programmer and the DBA see the value they can provide to each other, and the value of developing a reliable database build tool – the solution is to pair. It’s exactly the same thing as what we would do in the software world; take people with two skill sets and have them pair on building test and product code. …and of course it’s that way: the people piece of the puzzle hasn’t changed, so why would the practices we use?

Conclusion

Recognize and capitalize upon the value in what a DBA has to offer. Harness it and give them ownership in the tests. Show them how powerful and valuable transition testing is to them. Controlling the SQL that goes into the database let’s them exert force at the last moment and only in their presence. Having say in how a suite of tests (acceptance, unit, and transition) develops will project influence into the team continuously. Even in a DBA’s absence, their concerns are represented by the tests in a way that affects the product as a whole.

In short: I think the key is to show database developers who are resistant to these techniques how much more power they have as someone who enables early than they could ever get being the person who says “no” at the end.