Let's face it: Agile programming is full of some pretty far fetched ideas. Pair programming is the concept that two people devoted to a one person job can be more efficient. Unit testing is the idea that writing approximately twice as much code will make your project finish earlier. Refactoring is the concept that you can stabilize your system most effectively by rewriting the working parts. Constantly.
Of course those of us who have turned to agile techniques have done so because we know that these seemingly crazy ideas simply work. Two sets of eyes can produce better code faster. Automated tests not only speed development, but also fire a warning flare if something gets broken. Refactoring keeps your system coherent. The trouble is, all of this wisdom is hard to explain. It's hard to see the benefits of pair programming until you have witnessed the damage that one misguided engineer can do in a single day. You need to have an install fail because of a unnoticed bug that was introduced six months ago to really appreciate unit testing. And you need to shed actual tears over the pulsing mutant glob that your system has become because no one had the guts to rewrite the GUI code. Since most nontechnical people lack these important life experiences, trying to get the agile ideas across to them can be tedious.
There is one part of agile programming that I have had some success selling to the non technical folks: avoiding a complete up front design. Over the past few years I have used the same single sentence to explain why it is a bad idea to make all of your design decisions up front. So much success, in fact, that people have occasionally referred to that one sentence as Olsen's Law of Continuing Education, or simply Olsen's Law. So without further ado I give you the magic sentence:
Olsen is as stupid today as he ever will be.
It has a certain musical charm, don't you think? The point is, of course, that if you force Olsen to make all possible decisions at the earliest possible minute, some of those decisions are guaranteed to be worse than the decisions that Olsen will make tomorrow. This is because Olsen is getting smarter with each passing day. Smarter in general: I like to think I am getting better as an engineer. But also smarter in tightly focused ways: tomorrow I will understand your requirements, configuration, users, and font preferences better than I do right now. So let's agree to put off whatever decisions can be put off and let that smarter guy handle them.
Of course Olsen's law is not terribly original. It is simply a restatement of the agile principle that making all your design decisions up front is a bad idea. What Olsen's law has going for it is a brutal bluntness. None of this pie in the sky stuff about software teams flocking like migrating birds or finding the design like a sculpture hidden in a block of marble. No, just a naked admission of stupidity. It's hard to argue with.
Still, I'm not really sure why those ten words work so well. But check back with me tomorrow. I may have figured it out.
– Russ
