I attended Robogames in San Francisco this past weekend with my 3 sons. We had a great time watching the robots try to kill each other. I let out a Tim Allen grunt at several points, especially when we saw one of the robots with a flame thrower.

I had some time for reflection in between matches, and my pattern-recognition-heavy brain kicked into gear to find out what was similar between the engineering efforts behind robot building and software engineering. Not everything lines up, but I did notice that some of my thoughts of simplicity and robustness carried over to the world of attack robots. In no particular order:

  • Staying moving is more important than having a good weapon. While it did occasionally happen that a kick ass weapon ended a match (and when it did, it was supremely cool!), it was certainly not the majority. Instead of weapons, most of the time the other robot was defeated by getting "stuck" in one way or another, either by being flipped upside down or stuck on an obstacle.

    How does this translate to the software world? If you have a great piece of software, but it doesn’t work, it won’t be successful. Never let any new weapon feature compromise stability and robustness.

  • Simplicity wins - The more moving parts, the more things that can go wrong and break. It was easy to see the robots products that were over-engineered by the uber geeks. I laughed when I saw these robots quickly die because something simple went wrong. My favorite example was a group of "rocket scientists" that built a robot with two ginormous spinning wheels as weapons. Each wheel was turned by an elaborate contraption of gears and pulleys. You know the end of the story. Resist the temptation to over-engineer, and pride yourself on the simplest solution that accomplishes the goals. Or, to quote Albert Einstein,

    Everything should be made as simple as possible, but not simpler.

  • Test, Test, Test - you could really tell a difference between the "mature" robots who had seen a couple of fights, and you could really tell the robots that their owners decide to use them for the first time in the ring. Thorough testing should be done before the robot a product goes into battle the real world
  • Quality construction and materials. This was almost as important as design. Flimsy aluminum and other cheap materials quickly gave way under battle, and poorly engineered welds or connections suffered the same fate. Same goes in software - spaghetti code may look like it’s going to work, but won’t stand up to a fierce battle.

It’s always fun when we can learn from the convergence of two different sciences.