< link rel="DCTERMS.isreplacedby" href="http://www.darklock.com/blog/" >

A Voice in the Dark

In AD 2101 war was beginning. What happen? Someone set up us the bomb! We get signal. What? Main screen turn on. It's you. How are you gentlemen!! All your base are belong to us!! You are on the way to destruction. What you say? You have no chance to survive. Make your time. HA HA HA HA.... Take off every 'Zig' You know what you doing! Move 'Zig' For great justice.

Tuesday, August 16, 2005

How to Succeed

Paul Graham has written a brilliant article about What Business Can Learn from Open Source.

Joel Spolsky has written a brilliant article about Hitting the High Notes, his metaphor for writing great software.

I wish I could write a brilliant article about these things. I've been saying much the same sort of stuff for years, I'm just not as good at saying it.

Joel said one particular thing that resonated with me: "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years." For years, I've referred to this phenomenon as the Infinite Monkeys Fallacy.

It's said that if an infinite number of monkeys sat at an infinite number of typewriters for an infinite number of years, one of them would eventually produce the complete works of Shakespeare. This is wrong. What actually happens is they eat all your bananas, break all the typewriters, and start flinging poop around the room. Which is pretty much what you get when you try to replace a high-end worker with a collection of low-end workers: they consume your resources, break your equipment, and just make a big mess.

Paul also says something that resonates with me, "The sterility of offices is supposed to suggest efficiency. But suggesting efficiency is a different thing from actually being efficient." That also calls to mind something that I've said for many years: efficiency is bad for you.

Efficiency is all about getting the greatest return for the smallest investment. To an employer, it's about getting more work for less money. To an employee, it's about getting more money for less work. This puts the employer and the employee on opposite ends of a rope, struggling for all they're worth to win the tug-of-war and get what they want. And what's missing from that equation is the concept of BETTER work, which is what we really want in the first place. To (improperly?) extend the tug-of-war metaphor, the rope never gets appreciably longer no matter how hard you pull.

Efficiency can become the enemy in software development. Every so often, a television program will show a classic comedic scene. The protagonist is attempting to cook something, but it takes too long. So to speed things up, the following thought process is followed:

If it takes TWENTY minutes at three HUNDRED degrees,
it only takes TWO minutes at three THOUSAND degrees.

Hilarity ensues, because this simply does not work. We all understand that. Some people may not understand *why*, but they still know it doesn't work. It's just intuitive.

And yet, I often find that when I say "this project will take four days", my clients are confused when I don't spend every second of those four days doing things related to the project. They complain that what I am doing isn't in their interest. I try to explain that the project is "in the oven", so to speak, and will take time to "cook" before it's ready to come out... but they seem to think I should be working on something else for them while it's in the oven.

To an extent, I should. When the roast is in the oven, salad may be tossed and wine may be uncorked to breathe and a vegetable side dish may be prepared on top of the stove. But you can't bake a cake. If you tried, it would absorb a significant amount of flavor from the roast, and you would have meatcake.

Efficiency really comes in two forms. One is where you are doing lots of work, and one is where you are producing desirable results. People really need to start looking for the latter instead of the former.

And on a high note, I won a caption contest at Outside the Beltway.


<< Home