[Alan Anderson]

Dave, I infer from your posts that you consider the source code for a software module to be the equivalent of the blueprint for a hardware assembly, and the compiled bits to be the equivalent of the assembly itself. Is that a fair assessment of your opinion?

I draw the line between design and "fabrication" a little higher. The way I see it, the design is in the structure and the algorithms, rather than in the specific way those algorithms are embodied in actual lines of code. I think it's the .h and .c files that correspond to the frame members and sprockets. Sure, there is usually a particularly obvious way to write a function to implement an algorithm, especially when the structure of the program is well-defined in advance, but that just means the next embodiment of the design will come out looking the same as the previous one most of the time.

The software rule from last year means you're not allowed to pull a module out of the version control system and drop it into this year's project unchanged; you're required to re-implement it. That's a perfectly reasonable rule in my worldview. It means someone has to actively do some programming in order for that functionality to be available. If you want to consider that wasted effort, fine, but I think it's the same sort of effort required to assemble a KOP gearbox when you already have four assembled ones sitting on a shelf from the previous year.

I write software for a living, and I definitely consider software to be a part of the robot. Is your position otherwise?