The many and the few

Standard

My last post reminded me of another Nova program I [re]watched recently. One that continues the complex/simple theme. This show involved robots, cars, and DARPA, so I was instantly engaged. (So was my son). DARPA issued a challenge to inventors: create a robot-controlled vehicle with the brains to navigate a 132-mile course all on it’s little lonesome. Dozens of teams assembled to take up the challenge, some as small as one, others as large as…many. More than I could count on two hands, that’s for sure. I tried.

Two teams in particular were the focus of the show: a huge team from Carnegie Mellon that actually had the funding and the headcount to run two heavily customized Humvees in the challenge, and a small team from Stanford that used a mostly stock Volkswagen.

The Stanford team won. Let’s get that out of the way, because I want to talk about how their philosophical approach differed and why it matters.

The differences were apparent throughout the show, but the epitomizer (alert: new term!) came on the night before the challenge. Each team received a CD with GPS coordinates for the course. The Stanford team downloaded the information into their vehicle and went to bed; the Carnegie Mellon team devoted a small army to dissecting and studying every detail of the data then painstakingly inputting very specific instructions to account for every twist, turn, hill, or bump.

I couldn’t help it: I thought about labor costs and efficiency. And the military. I’ve seen command centers before and this is exactly what CM’s tent looked like that night.

The CM approach reflected a philosophy of control: everything had the potential for failure; every contingency had to be accounted for; every variable controlled. From the hardware to the software to any externalities, every potential failure had to be mitigated and redundancies implemented. This necessitated swapping out and modifying a large percentage of the vehicles’ hardware and the design and construction of complex optics, as well as the creation and constant alteration of lines of software code. The result was a lot of people creating a lot of complexity.

By contrast, the Stanford team used mostly off-the-shelf components, including mass-produced laser range finders and a vehicle that was outfitted for disabled drivers. They decided to rely on parts that had been proven to work already and instead focused their energy on solving for the single unproven variable: the software. Their philosophy was one of acceptance: they chose to believe that components produced by others were of sufficiently good design and quality that they didn’t need to be considered as possible point of failure. And this philosophy allowed the Stanford team to produce a superior result utilizing a much simpler process.

Just for fun, I’ve guesstimated the labor cost difference for the two teams. This is totally pulled out of my…well, here are the numbers:

  • Carnegie Mellon
  • Headcount: 25
  • Average salary: $50,000 (they get off cheap because many seemed to be students)
  • Total cost for 25 FTEs: $1.25 million
  • Standford
  • Headcount: 7
  • Average salary: $90,000 (many of them seemed to be teachers/researchers)
  • Total costs for 7 FTEs: $630,000

We humans seem to be drawn to the complex like moths to a flame. I know I find complexity fascinating. (Which means I might also have control issues, but that is a different post). But, fascinating as it is, it’s often the least best (and most expensive) way to get things done.

Advertisements

Thank you for your input

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s