Bad Metaphors

Several years ago, I left a dinner table of colleagues wishing a question had gone unasked. We were having dinner before a big release which included a major migration for a business unit, and a product manager said something like ‘This is like the night before the big game to you guys, right?”

I sat upright, and launched into, what was, to me, an impassioned motivational speech about comparing a multi-year software project’s final deployment to a game where the likelihood of success stood around 50%. I think it’s very important to keep in mind that modern engineering requires at least a 90% delivery probability, if not 100%. Sports is a competition whose mechanics can be good metaphor, but whose outcomes probably can’t.

A good baseball player’s batting average is around .300, which would be a terrible success rate for any engineering project. And the winningest teams are rarely undefeated. A good software development team has to leverage all their skills to be, and remain,  undefeated. Not only that, but a software team has several external benchmarks (disregarding the internal ones of it being good software):

Did the system get delivered on time and to spec?

Was the system able to be maintained?

Did the system meet its business goals?

Did the system result in pleased users?

IAD

I give as an example the main terminal of Dulles Airport, designed by Eero Saarinen. If you’ve been there, you know what I mean: The main terminal is beautiful and showcases all of the optimism of the 60s. But it’s 1200 feet long and 200 feet wide.

That makes the main terminal into a nightmare of long lines and poor ergonomics. There is no room between the check-in desks and the exterior windows, making the place look like there is a constant evacuation underway.

The people movers that carry users between the terminals (originally designed to directly unload planes), are pretty bad ideas.  The people movers were obsolete shortly after their delivery, and there are actually two ‘genders’ of them: if I recall correctly, which limit parts interchangeability and increases maintenance costs. The ‘gender’ thing is what galls me the most. Some have two humps on their roof, and some don’t. Why? There is now an underground train to replace them, which cost $1.4bn to build.

Ignoring whether it was delivered on time, or meets spec (it is an airport), it can be argued, that if delivered as software, it would not necessarily be hailed as a success.

Back to Dinner

So to come back to our dinner. We were not out to cap a year-long project by going out on the field and giving it our all for a 50-50 change of a win. Letting the opposing team (the computers) win would not be very good for our long-term employment prospects. We were were going to execute out plan and succeed. It wasn’t so much that there was no risk of losing – there was. But we vastly outmatched our adversary and had planned very well. Sports odds were not the right odds to be using.

Our success rate as software developers does not lend itself to sports metaphors very well, and, belatedly, I apologize to my diner party for having treated them to this discourse.