hackability

Adam Bosworth has some good advice for would-be standards developers in the form of a 7 item list. It is strangely reassuring to know that someone in the US Federal Government called someone like Adam for advice about standards…even if it was at some inhuman hour. Number 5 really resonated with me:

Always have real implementations that are actually being used as part of [the] design of any standard … And the real implementations should be supportable by a single engineer in a few weeks.

It is interesting because I think it could be argued that #1, #2, #4, #6 and #7 largely fall out from really doing #5.

  • Keep the standard as simple and stupid as possible.
  • The data being exchanged should be human readable and easy to understand.
  • Standards should have precise encodings.
  • Put in hysteresis for the unexpected.
  • Make the spec itself free, public on the web, and include lots of simple examples on the web site.

That leaves #3 Standards work best when they are focused — which seems to be a really tricky one to get right. Maybe it comes down to being able to say No to the right things, to keep scope creep at bay. Or to be able to say:

Stop It. Just Stop.

to ward off complexity, like Joel Spolsky’s Duct Tape Programmer. But I think #3 is really about being able to say Yes to the right things. The right things are the things that bind together the most people involved in the effort. Maybe it’s the “rough consensus” in the Tao of the IETF:

We reject kings, presidents and voting. We believe in rough consensus and running code.

Whatever it is, it seems slippery and subtle — a zen-like appreciation for what is best in people, mixed with being in the right place at the right time.

Creative Commons License
hackability by Ed Summers, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 4.0 International License.

One thought on “hackability

Leave a Reply