Hacker News new | ask | show | jobs
by ap22213 5071 days ago
I've worked on standards committees off and on for many years, and his experience seems typical of the issues that crop up. There are many problems with standards groups and the way that they work.

One major one is that, often, the participants come from different areas with different perspectives and visions of the outcome. Since participants rarely go to work with a firm set of agreed upon requirements or use cases, it leaves each member room to craft their own understandings of the goals. I've seen way too many working groups attempt to create a 'master' spec that takes into account all possibilities. Or, alternatively, clusters of people form from similar problem domains, and powerful clusters can take the work off course.

A second major problem is that there often is a lack of real user participants. Standards work is as close to the dullest engineering work one can get. Worse, it seems to attract certain types of engineers that love building specifications. Because of this, usually the real users flee immediately. This usually leaves a body of over-educated, overly-technical people to argue a lot over sometimes irrelevant details. Those types of people are definitely necessary for the standard to work in the end. But, because the real users flee, their influence is usually unchecked.

A third reason is that working groups rarely seem to use iterative and incremental life cycles. There's rarely any working code, often little V&V, and participants and users often can't experiment with their ideas. As we know, what's good in theory, sometimes doesn't work well in practice.

I think there are systematic reasons much standards work fails. The 'design-by-committee' outcomes arise from 1) lack of firm use cases to bound the work, 2) dissimilarity between participants, 3) lack of real user participants, 4) lack of iterative / incremental cycles.

2 comments

"There's rarely any working code,..."

Once upon a time, the IETF claimed to be interested in "rough consensus and running code". "Rough consensus" went out the window a long time ago; I suppose running code had to follow sometime.

If I were ever involved in a standards process, my gut feeling is that I'd want working code for all serious proposals. Does that seem feasible?

Perhaps the WG would produce a set of use-case prototypes which proposals are built on.

Or at least require each and every voting member to implement the standard in a freely chosen programming language. On second thought... Might not work so good for large standards as HTML5 though, writing your own parser, renderer and layouter :)
Or maybe only browser makers should be deciding what HTML is?