experiments

Are You Losing Enough Battles?

Portrait of McClellan. Image credit: Wikimedia Commons.

General George B. McClellan was a brilliant planner, but his overly cautious style may have tacked years onto the U.S. civil war. Lincoln became frustrated, commenting with devastating wit that “McClellan is always almost ready to fight.” Eventually McClellan’s risk aversion forced Linoln to relieve him of command, after sending a telegram that read, “If General McClellan isn’t going to use his army, I’d like to borrow it for a time.”

Contrast Colin Powell, who recommends: “Once information is in the 40% to 70% [certainty] range, go with your gut.”

I don’t recommend that you take stupid risks, that you make no effort to gather data, or that you spend your political capital carelessly. But I do recommend that you follow Powell’s example, not McClellan’s. To quote Powell again, “You don’t know what you can get away with until you try.”

Thomas Edison tried 1000 times to invent a light bulb before he succeeded. Why do we expect in software to get our designs right on the first attempt? I submit that if you aren’t losing a battle now and then–if you don’t make any failed experiments–you are not working smart enough or courageously enough.

If you don’t lose the occasional battle, you will never win the war.

Losing an occasional battle keeps us humble. It means we’re grounded in reality rather than ivory tower imagination. It means we value balance and pragmatism over theoretical perfection, and it helps build a healthy regard for the needs of other people.

Go try. A lost battle of the sort we fight with software is never an Antietam or Gettysburg.

“To live a creative life, we must lose our fear of being wrong.” Joseph Chilton Pearce.

Related articles

Baby Steps

Film poster, displayed under fair use as documented on Wikimedia Commons.

If you’ve seen the delightful comedy movie, What About Bob?, you are no doubt smiling at my title.

Bob is a neurotic and thoroughly irritating patient who depends on his psychotherapist for lots of emotional strokes and life coaching. He ingratiates himself with the therapist’s family and gets himself invited to be their guest on a weekend getaway, against the protests of the therapist. He then proceeds to drive the therapist crazy.

One of Bob’s favorite phrases is “baby steps,” which captures the therapist’s advice to solve problems a little bit at a time, rather than in overwhelming chunks.

“Baby steps” is surprisingly good advice for many questions in software design. It doesn’t apply in all cases, but it applies far more often than it ends up being used.

The Purpose of Design

We create UML diagrams, personas, design docs, lo-fi mockups, and other artifacts to capture our architectural thinking because they provide us with a roadmap of sorts. We need to identify and steer to a consistent point of the compass if we want to produce complex artifacts that meet customer needs. The bigger and more diversified our teams get, and the more moving parts we’re orchestrating into our software, the more important this is.

However, all of these artifacts are means to an end. To whit: Continue reading →