Liberate Wall Street

Are you tired of the Occupy movement?  I am.  It looks to me like a bunch of dirty hippies whining about the fact that they bought houses they can't afford and created an economic meltdown.  How the hell is that Wall Street's fault?

Occupiers: You jackasses committed fraud and got away with it.  Or, at the very least, your mortgage brokers did.  Sure.  There was a little bit of economic fallout from your decisions and the Wall Street people definitely didn't do anything to arrest the downturn you created.  That hardly entitles you guys to bitch about them.  It's not their job to look out for you.

Here's what I think we should do.  We have a long history of liberating pansies who can't seem to take it upon themselves to fight back when occupied; most notably the French.  Why don't we get together as Americans and start liberating Occupied spaces?  We can start where it all began: Wall Street.

Liberate Wall Street!

The Gift that Keeps on Giving

Christmas is approaching as rapidly as ever.  In fact, it's approaching at exactly the same pace it always have and probably always will.  I don't know what everyone wants but I do know what most people desperately need.  They need the thing that helps them get through life, cold and twisted a thing as it is.

Unfortunately, if you're in the ninety-nine percent who don't seem to have this, nobody can give it to you.  That is, nobody can give it to you but you.

This year, give yourself the gift that keeps on giving: a fucking sense of humor.

The Reason for the Season

Hey everybody!  Thanksgiving is coming up and I'm very excited.  Of course, there's the feast but it's also a special day on which we all get together and celebrate the circumstances that afford us this free and comfortable lifestyle to which we have all grown so accustomed.

So this year, invite everyone you love to come over to your place.  Gather around the table.  Join hands.  Pray, if you're the religious sorts.  However you do it give thanks for the thing that allowed us to be us.  Was it Columbus?  No.  Was it the corn and beans thing?  I think not.

I wouldn't waste any precious thanks on those things.  Instead, let's remember how it really happened and let that remind us of who we really are.  We're the people who figured out how to make blankets into a weapon of mass destruction because winning a war with bullets, cannons, superior infrastructure, and trick beads wasn't going fast enough.

This Thanksgiving, instead of saying "Happy Thanksgiving," why not something that rings a little more true:

"They never knew what hit them."

"5 Whys" on the Economic Meltdown

The economy crashed.
Why? Because banks were profiteering off of loans the borrowers couldn't afford.
Why? Because people were borrowing more than they could afford.
Why? Because prices were sky-rocketing.
Why? Because government created artificially low interest rates.
Why? Because the economy crashed.

Occupy the Slippery Slope

"You know what?  Maybe it's not just the top 1% who's the problem.  That second percent is pretty rich and therefore responsible for my lot in life, too."  It's not unlikely that the #Occupy movement will take that turn and this is what it looks like...

1% becomes 2%.
2% becomes 4%.
4% becomes 10%.
10% becomes 25%.
25% becomes 49%.

Nearly half of all Americans would be screwed by them trying to "make things fair."

Then, if they get what they want (read their literature), we'll have full scale communism which screws almost everyone all the time.

So here is my modest call to action.  Go to the places where they are organizing and counter organize.  Help them see that they are their own problem and nobody else is responsible for the choices they make but them.  Be relentless with your reason and maybe we can avert the storm they are gathering.

I think it's time to invade China

Check this out:

http://blogs.hbr.org/cs/2011/08/apple_stores_in_china_the_one.html

I know how we could enforce trademarks over there.  We could threaten to default on our loans to them.  We could place an embargo on them.  We could start a good ol'fashion war with them.  It's about time a World War didn't start in Europe, anyway.

Term Coined

A very short while ago, a friend of mind posed this question: "What do you call a handjob from a chick with no hands?"

After numerous trials and errors, we came up with this:

http://www.urbandictionary.com/define.php?term=chernobyl+stump+stroke

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.