• by Kaila Colbin , Featured Contributor, July 13, 2012

Here are two characteristics that will give you a major competitive advantage, no matter what your field of endeavor: 1) learning to identify your own assumptions, and 2) learning to set them aside when considering a problem.

It’s impossible to do this entirely, of course, mainly because we cannot perceive what we cannot perceive. This is true not only metaphorically but also literally: You have an anatomical blind spot in each eye where your optic nerve connects to the back of the retina, but you don’t notice the holes in your visual landscape because your brain fills in the gaps. Assumptions can be insidious precisely because we so often don’t even notice we’re making them.

And yet so many of our decisions ride on unquestioned assumptions. We assume that people have to work for a living. We assume that sustainable development is more expensive than traditional development. We assume that software developers are Coke- and pizza-fuelled loners who work best if they can wear giant headphones and maintain a minimum 20-foot distance from any other human.

Whether you’re making these assumptions or others, your mind is taking shortcuts it doesn’t bother to tell you about. There is no point in lamenting this fact, just as there’s no point lamenting the fact that our short-term willpower is weaker than our long-term aspirations. The trick is to create a structure that acknowledges these facts of our nature, and forces us to act differently.

The other night I met an extraordinary duo who are doing exactly that. Joe Justice and Tim Myer are from Team Wikispeed, who created a 100mpg car using Agile processes and an open-source team. They came in 12th in the X-Prize competition; it’s worth the ten minutes to watch Joe tell the story.

Among the many topics we covered at dinner, Joe explained test-driven development to me. If I ask someone to build me a catalytic converter, he said, and they’re really good at building catalytic converters, they might build me the most awesome catalytic converter ever made, with amazing bells and whistles, far more of a catalytic converter than I might ever need. If, on the other hand, they don’t have a good understanding of catalytic converters, I might get a catalytic converter that doesn’t even work.

But with test-driven development, you don’t ask for a catalytic converter. You start the development process by designing a test: What is it you want this thing to do? You don’t make any assumptions about whether the best solution to pass the test is a catalytic converter or a flux capacitor. You just want something that is no larger than these dimensions and weighs no more than so many ounces and takes toxic gases and makes them less toxic, ideally not toxic at all.

Joe and Tim’s application of test-driven development was taken from the world of software and applied to the world of automotive design -- where development cycles normally last up to 10 years. And, because development cycles normally last up to 10 years, most people in the automotive design industry assume they must always last up to 10 years. But Joe and Team Wikispeed made their car in just three months.

Test-driven design frees you. It frees you from the mental picture of “catalytic converter” and all the assumptions that come with that. It frees you from incremental improvement and opens the door to transformation. It forces you to continually question the “why” of what you’re doing and refocuses you on the outcome.

It’s not weak to rely on a structure to release you from the limitations of your assumptions. It’s smart. You are, after all, only human.

At least, I assume you are.