September 3, 2006

When is "just good" good enough?

Bear with me for a moment, because this won't make much sense at
first. This morning I was helping my son put his toy race track away.
You know, the kind with the long plastic strips and differently shaped
connectors that share some common portion. The "optimal" way to
separate track from connectors would have been to examine each piece,
noting the best part to hold onto and to pull it from its section of
track.

Being a lazy software guy, I just lightly wrapped my hand around the
whole bunch of them and drew back several times. Sometimes pieces
came apart, sometimes not. It probably took me 3 or 4 tries more than
the optimal method, but eventually got the job done. My technique
required no specialization or extra analysis, just a cheap
non-differentiated operation performed in parallel.

Return to the world of commercial software development. I bet you are
like me. You've written code that works but doesn't make you proud.
You did the simple, cheap thing, verified it works all the time (you
do write tests?) and checked it in. Now you have writer's remorse.
You want to take it back. You want to buy the time to make things
right.

Most young businesses don't have the luxury of "doing it right", of
finding the "optimal algorithm". Lack of money pressures them into
delivering early. We've all heard those stories. Anybody who reads
reddit, digg, even slashdot is nodding along, saying "so what?"

Well established businesses, averse to risk, act much the same. They
don't want to spend time (again money) hunting for something that
might only give a 5-10% increase in whatever but costs 5 times as much
in developer time to discover. (Remember, people are the most
expensive resource you've got).

For businesses, where product is profit, an "optimal implementation"
would require too much upfront thought and experimentation (read as
cost). During that time we are failing the real task: delivering a
product that delights the customer. Sure, everyone wants the praise
of friends and collegues. Everyone wants to be the smartest.
Pragmatism is rarely lauded by geeks; elegance and cleverness are the
coins of the realm. Well kids, being clever is necessary but so is
delivering. Get the ugly first hack out there, the one that enables
users, that gives them power over the machine. With luck and if the
market smiles, you get the time and money to make it faster, prettier,
"optimal".

Who's left? Academia. After all, a young grad student can make his
bones on a new idea with no mouths to feed, just a thesis to prepare.
Hell, he may even still like the taste of Top Ramen. (Come on, who's
with me?).

I'm not sure where I'm going with this, but I want to admit that I'm
an engineer. A pragmatist. I find it more fulfilling to deliver and
to see the customer's reaction than to ceaselessly polish the knob,
hoping for an extra 5%.

Posted by cbrown at September 3, 2006 10:00 PM
Comments
Post a comment









Remember personal info?