Programming with Kids and Adults

It has been five years since I joined Microsoft and started writing MSF. There are a couple of milestones that this anniversary brings that I would like to share with you. First, the MSF book is not published and you have a right to ask why. Second, the robotics team that I have been mentoring (all 11-13 year olds) won the NC State championship and will advance to the National one. All of these kids can program extremely well as they have been working on building and programming robots for three years straight. Third, I continue to see the same negative patterns in (recovery) projects and I have been wondering if there is a way to process some of these patterns out of existence.

Some of you may not be aware that I have been working with two robotics team, one younger and one older. As I was working with the older Robotics team (high school kids), I happened to see a problem that I frequently encounter on projects. We were trying to test the robot in a museum on a simulated ice floor. The code for the drive control system was being finished on the way to the museum which is similar to the way many adult projects are done. When we got to the museum, we couldn't download the code to the robot.

Now, it turns out that we had fried the drive controller by static electricity from the simulated ice floor so it didn't matter. But as I thought about the current project that I was working on, it occurred to me that it had the same problem. One fellow who was working on it was out for the week and had no realistic backup. He had changed some of the code and it wasn't working as intended. We hadn't found the problem until he had left for vacation. It was an honest mistake (and one where he will have a pair from now on). But the delay cost the project.

A stitch in time saves nine.

I look back on the original manuscript for the MSF book and I don't like it. The whole introduction about second generation agile processes needs to go. My thinking was clearly flawed (some would say on several aspects :-)).

We are rewriting a piece of one project that I am working on because we now know more about this area than we originally did. The area works but it isn't elegant and certain bugs are unfixable. We have learned by doing once and then doing right.

But sometimes, like good wines, things have to age.

What has this got to do with programming kids, the MSF book, my projects, and my anniversary? I suspect that all have been influenced by stitches in time and aging. But sorting out the things to age and the things to rush is always the hard part. I suspect that we should always strive to do something and then evaluate how well we did. That is far better than waiting until we get it 100% right.