Recently, I gave a talk on the subject of test-driven database development at the
Portland chapter of the organization known as DAMA (DAta MAnagement).
I was surprised by a couple things during this talk. For one thing, the group was a lot more engaged than I've ever seen at this kind of talk. For another, I expected the audience to resist the ideas a lot more than they did. Finally, I expected to encounter new classes of objections that I had not previously addressed but none were raised.
A Great Group
It's not often that I get to (read: "choose to") say positive things about an entire group of people but this is one of those times. The group was attentive. They were very focused on what I was saying. That's not a back door complement for myself either. I've delivered virtually the same talk to other crowds and seen a lot more droopy eyes. This is just a voracious group that wants to hear someone's ideas.
That level of attention to detail, naturally, gave rise to an unprecedented level of engagement and involvement. The questions were piercing and pointed. They demanded good answers. They gave many opportunities to elaborate. Yet, there wasn't "that guy."
Everybody who's been involved in public speaking knows
that guy. There's almost always on in every crowd. The person who objects for the wrong reasons. Sometimes it's because they like the sound of their own voice. Sometimes, because they want others to hear how smart they think they are. On occasion, they object for objection's sake, subscribing to the same basic motives as a vandal.
This group, at least when I talked to them, didn't have
that guy and it made the speaking process
so much more enjoyable. Not only were there a lot of good questions, but there were
only good questions. Not only was it a lot of engagement, but it was all
thoughtful engagement.
Little Resistance
I was a little nervous because I have traditionally engaged programmers who are affected by database development processes and this was an entirely different audience: mostly people who's primary skill was database development, administration, or support. In many cases, especially in large organizations with so-called "centers of excellence" (read: "centers of delay"), application developers and data managers are at odds with one another. At least, the application developers with whom I converse present things that way.
This talk served as evidence that things are that simple. The group was very open to new ideas and to enhanced collaboration. In fact, some of their questions seemed to imply that they were concerned with how to get application developers to adopt these concepts.
I now suspect that, in many organizations, data manager types and application developer types each see the other group as stubborn and distant almost entirely on account of the inefficiency introduced by the management structure in which they work. That is, the people are reasonable and are willing to work together but their organizations impede collaboration by concentrating into skills-based groups rather than product-based groups. This invalidates some of what I wrote in
a previous entry entitled "Breaking Down Barriers to Agile Database Development" but maybe not all of it.
The resistance I did meet was mostly good, coming in the form of tough questions posed by people with real obstacles to overcome.
Bases Covered
Apparently, I'm getting good at this or something. There wasn't a single question asked that couldn't be answered either by something from my book or by basic TDD/Agile wisdom. This was surprising. I really thought that, given the new type of audience, I would be facing some new tough questions.
In reality, something like a third of the questions were directly addressed by the content I brought with me. That was really gratifying because a lot of the time I got to say "That's covered in a future slide...<click>...this one!"
Another third was covered by chapters in
Test-Driven Database Development: Unlocking Agility. There's not a lot you can do about that. You're allotted a certain amount of time. If you have more material than that block will support, you either cut scope or depth. This talk was already a surface-view of the problem and solution, so cutting depth wasn't an option. Besides, there's nothing wrong with having concepts that entice people to buy my book, right?
The last third was just basic agility or TDD questions. I could have covered more agility and TDD concepts at the beginning of the talk but that would have forced me to cut even more scope at the end.
Regardless, the questions that were asked were easily addressed. That's not to say I convinced everyone of everything - especially people who were at the beginning of their journey to agility. However, the fact that there was an answer to every question made me happy.
Conclusion
It was an enjoyable and rewarding talk.
If you've got a talk that you thin might apply to this group, I highly recommend them. I know I'm not the only one, either, because their speaking calendar is filled something like a half year in advance.
. Recently, I did a talk at Better Software East on the same topic. I would like to re-deliver that talk at a number of locations in the United States and I'm looking for companies or user groups that are willing to host a ninety-minute talk on the topic of test-driven database development. I'm trying to do these talks at times when I'm already going to be in a city.