Neil's News

Teamwork

21 October 2006

The robotics course at Carleton is an enormous amount of fun. Mapping, wall following, emergent behaviours, kinematics, path planning. Every week there's a brutal lab where one has to implement one of these topics on a temperamental little two-wheeled bot. Below is a trace of random wandering; the blue line is the robot's actual path, the red line is the robot's perception of where it is based on wheel turns.

As one can see, the angle starts to drift over time (which is expected given that the wheel encoders only have a 22.5° resolution). Part of the joy was doing everything in 2KB with integer math. It's fun to examine the other results from the class. Many of them simplified the problem by only turning on the spot or by beaming the raw data back to a PC where they could crunch the numbers in Java. It was a tough problem.

I had a significant and unfair advantage. While everyone else was stuck working in teams of two, my assigned lab partner dropped the course. Working alone makes the process much easier. One doesn't have to spend time explaining how things work. One doesn't have to come in after-hours to quietly rewrite one's partner's contribution. One doesn't have to deal with unstructured, unmaintainable, buggy programming. One can simply do it right, the first time.

Programming as a team does work on rare occasions. The last project I collaborated on with someone (in person) who wrote trustworthy code was MOOzilla with Lao. I think the trick is finding people who code at similar quality levels. If one can't trust one's partner's code to execute as intended, then being a team is of little value. Team programming is a bit like parachuting: the result is either really great, or really bad, without much middle ground.

< Previous | Next >