Term Coined

This summary is not available. Please click here to view the post.

My Work is Now Cut out for Me

Okay.  So I let myself get sidetracked on the development of my book as a result of having a lot to do at my current job.  That's the bad news.  The good news is that everything has been "percolating" during this time and I've come up with  a really good mental map of how I'm going to guide the reader through all the problems involved in agile database development.

Here it is...

Basically, the idea is as follows.

Goals:
We have the goal of increasing the speed with which value can be delivered by reducing the "bottleneck effect" that generally surrounds database changes.  However, we cannot do that at the expense of things we've already gotten good at; namely preserving the knowledge stored in a database and maintaining the availability of its service as experienced by a user via an intermediary application.

Obstacles:
There are risks posed to the things we are already good at by increasing the speed of change.  Changing structure, the way we do it now, implies risk to existing knowledge stored in a database.  It also introduces the chance that an application coupled to a database might not have had time to adapt to a change in structure by the time a change is rolled out.

There is also an obstacle to agile database development in that whatever infrastructure is required to mitigate the previously mentioned risks will probably not be available for legacy databases.

(From the Other Angle) Axioms:
Databases store knowledge - that is their primary role.  To acquire knowledge and make use of it, databases absorb and emit information.  Another thing to assume is that people will make mistakes.

Here's the big one: databases are objects.  They are objects that store knowledge on behalf of other entities, like applications.

In any environment, where there is risk or instability, test-driven development mitigates those dangers to the point of rendering them almost non-existent.  This is especially true in a good object-oriented environment where behaviors can be easily isolated and tested.

Solution:
Good object oriented platforms, and really even mediocre ones, provide the notion of a class.  That is: an encapsulated, refactorable unit of design that provides a reliable way to instantiate objects with predictable behavior and easy-to-couple-to interfaces.

Implementation:
We cannot simply take existing mechanisms for defining classes and apply them to databases because the forces around a database are different - they have "inertia" in the form of knowledge that cannot be lost in the course of a design change.

The core of the implementation is to introduce a predictable, highly structured create-or-upgrade path that minimizes errors, protects existing knowledge, and regulates how change is introduced to any given database instance.

The next step is to specify exactly how changes are introduced to a database by test-driving them.  This all-but-eliminates the chance that a database will lose knowledge in the course of changing its design.

Once that is accomplished, provide a strong interface for your database to ensure that application developers are warned of breaking changes as soon as they possibly can be.  You, yourself, can be warned of these changes by using test-driven development to specify the behavior of the current database.

Finally, there must be a way to handle errors.  This is a function of good database development practices - like taking regular backups - and providing a mechanism for rapidly introducing corrections to errors that have already been committed to production.  Once you have that system in place, by definition, you will have a process that can be used to enroll legacy databases into your agile database development process.

Where Does the Buck Stop?

So I just watched another Michael Moore propaganda film and the theme of individual non-accountability continues.

I have a question for anyone who is swayed to believe that homeowners are not responsible for the consequences of their actions or that workers aren't responsible for choosing to work a job where they are underpaid.

If individuals should not be accountable for the consequences of their actions, who should?

The Law of Damocles

People keep talking about the Law of Demeter.  It's a pretty good law - although it seems like a hard one to break in a modern programming environment.

Anyway, I'd like to propose another law based on a classical mythical character: The Law of Damocles: All code exists with a sword poised above its head.

Shit code is better deleted than mutated.  Ensure the behaviors are properly specified with tests, delete it, and start writing good code until the tests are all green again.