I was reminded of this twice recently, the first last Saturday, the latest being tonight.
Last Saturday I was talking with family while at a parade. The discussion of brainstorming came up. The somewhat well-known story, or so I'm told, was reiterated to me on Saturday. It has to do with a power company trying to figure out how to remove ice from electical lines. When the ice would build up the lines were in danger of breaking under the weight of the ice. Here's what they came up with during a brainstorming session on how to fix it:
"during one of the breaks, one of the linesmen shared with
some of the participants about how came face to face with a big, brown bear
when he was servicing the power lines, and how he narrowly escaped being mawed
by it.
when they returned for the meeting, someone suggested training
the brown bears to climb the poles to shake off the ice from the wires. brown
bears were very common in the areas that they were looking at and they are
strong enough to cause the poles to shake when they climb the poles.
someone else then suggested putting honey pots at the top
of the poles to entice the bears to climb the poles.
they then started to discuss about how to put the pots of
honey at the top of the poles and someone threw out the idea of using helicopters
to do the job."
The idea however was quickly abandoned for a more simpler solution when a secretary pointed out the following:
"a secretary in the meeting pointed out that the down wash from
the helicopters could possibly break the ice and blow it off the wires."
The helicopter idea works, and is still in use to this day (
read the whole story), but how cool would it be to sit back and say, "I trained some bears to climb a tree in search of honey to solve our problem." The story is typically used to illustrate how even crazy ideas in brainstorming sometimes aid in finding a simple solution. As a programmer however, I learn from the story the fact that they implemented the helicopter solution because it was easy, safe, cost-effective, and quick to implement.
The second, and latest, reminder occurred tonight when talking to a co-worker at a client cocktail party. The co-worker was talking to me about a conversation with a client who's main complaint is that we have to provide everything "whiz bang". Typically "whiz bang" denotes something cool or neat, however, the gripe was not that what we delivered was bad or wrong, but that in our pursuit to "wow", we didn't "wow" the client because it took a long time to implement.
Over-architecting. This is a seemingly common trait in developers. If you work on a team it's likely that you're constantly having to fight this from somewhere within the team. On days where I'm dutifully adhering to the YAGNI principle and building shippable software, someone else on my team may be in the throes of a battle of over architecting. Likewise while everyone is adding real features, I may be dreaming and scheming of ways to make a program über-great.
I have to keep reminding myself that shipping software is the most important aspect of a software company. It seems too simple to carry any real weight; like something as simple as a shippable product is enough. It's really a novel idea considering how much software I've shipped recently.