Improving the experience of programmers and the effectiveness of code

[Greg McKaskle]

I think this is a good summary looking to the future. The thing that could probably be stated more directly would be to allow programming to proceed without the robot. In my book that means test harnesses so that code logic can be validated more quickly and more safely somewhat independent of the robot. After all, NASA rarely launches another rocket just so the programmers can see if they've fixed a bug.

One way to accomplish some of the other elements on the list would be to form cross-functional teams. This is a common occurrence at NI. If you want the HW and SW guys to understand each others tasks better, to communicate better, you put them on the same team and give them a higher level goal. This would be equivalent to saying that the manipulator team was composed of some mechanical, some electrical, and some programmer members. I'm not certain if it builds a better robot, but perhaps it builds a better team. One of the enabling tools for this is a code architecture that allows it to be written by different subteams and integrated without stepping all over each other.

The other way to look at this is that programming isn't just for programmers. NI's tools are intentionally aimed wider than that and aim to let a EE's and ME's write good code too. One of my favorite robot stories is from Dave Barrett from the MIT DARPA urban team. It starts at 25:30 and ends at 28:30 on the following URL movie. The rest of the keynote is very interesting as well.

http://zone.ni.com/wv/app/doc/p/id/wv-1709/upvisited/y

So, while specialization is important in the modern world, it isn't the only way to tackle a problem. Thanks to easy access to a useful tool, we no longer take our notes to the typing pool to get them formatted for distribution. We open a productivity tool, type away, and it helps with formatting, spelling, grammar, finding references, etc. Perhaps some amount of programming is heading this direction as well.

Greg McKaskle