Breaking Down Barriers to Agile Database Development

Having a cross-functional team that works together to solve a problem is a basic property of an agile development environment.  It's impossible to list all the things that can impede the development of an agile database environment.  There are, however, some particular scenarios worthy of note.

One common case, especially in smaller organizations, is that the person who works on the database design is also a programmer.  In that case, fostering a collaborative environment is probably not too difficult.  Don’t let people catch you talking to yourself too often, though.  They might decide you have cracked under the pressure.

Another scenario that is ever-increasing in its frequency is when you have an agile development team with a “database guy” or a “database gal.”  In this situation it is important for programmers and the “database folk” to work together.  However, it’s still not that hard.

The toughest nut to crack is when you have an organizational boundary between a team of programmers and one or more database people, and those database people serve not only as database developers but also as “gatekeepers” to some production databases.  Oftentimes, the gatekeepers are vehemently against anything agile as well as anything automated touching their jealously guarded database structures.

I’m not exactly known as some great builder of bridges.  I’m actually better known for my “scorched earth” manner of dealing with people who I see as “in the way.”

However, there is one trick that has worked for me on the rare occasions when I was able to take a deep breath and count to a thousand before opening my mouth.  That trick is giving the gatekeeper control over the new processes I want implemented.  Instead of persuading them to let me have the most agile thing I can possibly get, software development teams in control of database design, I settle for the next best thing.  I try to persuade the "database guy" to take on the test-driven development and and object-oriented design activities I want implemented.

An example would be trying to get them involved in things like writing transition tests.

People tend to want to do the right thing and, when they are doing the wrong thing, it’s usually because they don’t understand the negative impact.  The other major reason is fear of no longer being needed.  It’s not so important who implements good practices as it is that they are implemented.

Giving control over certain aspects of an agile database development process to someone who is already in control of the database development process often neutralizes both the major impediments to adoption.  The gatekeeper will be able to make sure things are done his way and can be assured that he will remain relevant while slowly growing more accustomed to the modern ways of doing things. 

Special Thanks: Seth McCarthy

As the hour of Test-Driven Database Development: Unlocking Agility draws nearer, I'm left with less to do and more time to reflect.  It was a lot of work and, no doubt, I did much of the work.  There are numerous people who have been in some way responsible for the current shape of the book.

One of those people is Seth McCarthy.  Seth is a friend I acquired upon moving to Central Oregon.  As a good friend, he offered to read early chapters of the book.

One thing that makes Seth unique as a friend is that he is not afraid to give harsh criticism when it is deserved.  For some people, I'm sure, that's a problem but for me it worked perfectly.  There's a reason that you won't see any of the original chapters if you read my book and most of it derives from Seth being willing to tell me I was pompous, long-winded and (worst of all) off topic.

Thanks, Seth, for being technically competent and forthright enough to spare me the abject failure the first incarnation of my book surely would have been.

Is it me or is "Tron: Legacy" a really clever title?

If you haven't seen the movie, don't read this blog entry.  It may constitute a spoiler.

On my longish drive in to work, this morning, I found myself listening to the soundtrack from Tron: Legacy.  It got me thinking... that's a really clever title.

I try not to superimpose meaning onto movies.  So many people fall into that trap and it gets a little obnoxious after awhile.  In this case, though, it's hard not to do that.  Think about it...

In the late eighties or early nineties, this guy has the genius idea that he can build the perfect system.  He sets his grand project in motion with no criteria for success beyond the vague requirement "create the perfect system."

Over time, this creation becomes increasingly powerful until, eventually, this guy loses control over it.  It traps him and begins the process of enslaving the system that hosts it.  Along the way, something of real value is discovered.  This value threatens the runaway system and so it is destroyed.

Eventually, through an act of great sacrifice, the man who created the cancerous system destroys it.  The new generation is left free of its grasp, left with bad memories and the tiny scrap of value that survived the process.  This value is the legacy of the Flynn.

Or is it?  Does that story sound familiar to anyone?

It's pretty much the back story for every legacy system, if you let the date of creation and who makes the sacrifice to destroy it.

The studio is Disney, after all, I wouldn't put it past them to hire a bunch of subject matter experts to create a real meaningful allegory.  The cost of doing so would be a drop in the bucket for them and, if it keeps people chattering on about the movie, it would be more than worth the cost and they're all about doing things that are more than worth the cost.

...and if all of that is so, them I'm really impressed.  That's some mighty fine double entendre, there, Lou.

An Introduction to Fault Arithmetic

When people collaborate to create a problem, that problem can become very difficult to fix.  One reason, I've recently realized, is that people have difficulty properly assigning blame.

Take a typical codependency problem.  Person A depends on person B.  Person B enables person A.

It seems to me that most people would say that each is half responsible for the situation but fault arithmetic doesn't work that way.  In fact, person A is 100% responsible for the situation and person B is also 100% responsible.  Here's why:

If person A decides to stop being dependent, the situation ends.  So person B's decision is not sufficient to the problem.  If person B decides to stop enabling, the situation ends.  So person A's decision is not sufficient to the problem either.  In fact, since either person can end the cycle with their decision alone, both of them are necessary.

If your participation in an activity is necessary for its continuation, you carry full responsibility for its consequences.  So division of blame doesn't work like division of, say, a bushel of apples.

(9.31 gallons) / (2 bags) = 4.65 gallons per bag

...but...

(100% blame) / (2 necessary participants) = 100% blame per necessary participant

Before You Freak out, Read the Executive Orders

I heard that Obama is going to disarm the people with an executive order or something like that.  I was mildly annoyed until I remembered one thing: people are fucking liars.

I think it's pretty well known that I am no fan of the current president.  I really haven't been a fan of any president since I was born.  However, he seems to me to have done this one right.

Great care appears to have been taken so as to create two effects:

1. Avoid violating the second amendment or, really, even treading near its protections.
2. Avoid fixating on guns as the problem and stay focused on gun violence.

I think that last bit is a little dumb.  There is no gun violence problem in america.  There are gun violence incidents and, everyone reasonable seems to agree, there's no way you are going to prevent every incident of gun violence.

Half the executive orders amount to simply declaring he will do his job.  Like nominating a director of the ATF.  Oh no.  Not a director!  Some of them are things like encouraging the states to share information with the federal government.  There's no violation there, of the second or ninth amendments.  If anything, it's more recognition of the latter than I've seen in years.

Some of them are just common sense, like reminding doctors that they are not federally obligated to keep in confidence their concern that a patient might harm themselves or others.  Three times.  Another common sense order is reminding gun stores that they are not obligated to sell guns to crazy people and offering them training on how to spot a nut.

Nestled in there are even a few good ideas.  I'm not going to tell you what they are, though, because I want you to read the orders for yourself.  If you do - if you actually read the orders and evaluate them against the text of the constitution - you probably will realize you should reserve your outrage for other problems...

...like when he tries to push an unconstitutional assault weapon ban through later this year.