Joe Gregorio
At a previous employer we made tensile testing equipment. Now for tensile testing a material you cut it into a dogbone shape and then pull at each end of the dogbone, plotting out the change in length of the specimen against how much load is on the specimen. Once you have all that data you can plot stress-strain curves and learn all sorts of interesting things about said material.
Now if you are developing a new material, or in general working in a laboratory setting, the amount of material to test isn't large, and the amount of work of preparing specimens and loading them into a tester and reading off the results falls into that's-what-we-have-interns-for.
If, on the other hand, you are in a manufacturing environment and the results of your tensile testing are used as inputs into your SQC/SPC process to control your manufacturing line then the amount of testing falls into that's-why-they're-unionized.
For those special folks willing to shell out enough money, we offered a robotics 'package'. By which, I mean, that our intrepid sales folks would offer a robotic automation system to a customer, they would feign interest, my boss the engineering manager would pull a ridiculously large number out of thin air in an attempt to dissuade the customer, the sales guy would 'negotiate' with them, and the price would drift down low enough that the customer would accept, and the VP of the week for our division would drool, and then we'd be forced into building one. The only problem was that we didn't have a robotics package, and so every time we got an order we had build up the entire system from scratch.
Every time the delivery date would slide closer and closer, and Joel, the engineer put in charge of designing these systems, would be out on the manufacturing floor assembling a Medusa looking nest of wires and robotics, testing and tweaking. We would all help out, but invariably as the time got closer we'd joke that he should really get it working, because if it wasn't done in time, we could always ship them a Joel-in-a-box until we did get it working. And we could, you know, because being an engineer, he wasn't unionized.
This all came rushing back to me the other day when I was reading Ian Hickson's draft of the Web Socket protocol. It was written in a very clear and precise manner, but also very clearly directed at someone that is going to be implementing the protocol, either on the client or the server end. It was refreshing to read, and in sharp contrast to many of the specifications I've had to read recently. Somewhere between now and Jon Postel we lost something in spec writing. Over time specifications have drifted towards being written in a stiff and officious manner, laden with a sense of, but no actual, rigour; as if they were the Doings of Serious Men. In the old days RFCs were written more along the lines of "A letter to the implementer", with directions on how to implement the protocol. Heck, some of them even went so far as to include code. Actual code! The faux rigour was something that I fought against, and largely lost, in the writing of RFC 5023. Reading the Web Sockets protocol specification did give be that flash back to better spec writing. And it also brought back memories of Joel. So here's the rub: Any spec is a good spec if it doesn't require a Joel-in-a-box to get it up and running.