Philip Greenspun cites the software engineering classic The Mythical Man Month today in a response to a question about open source. A key message of that book seems to have been lost on people who are using control arguments to talk down RSS.


In the book Fred Brooks develops the notion of conceptual integrity:

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. (p. 42, 20th anniversary ed.)

You should be able to appreciate his point if you've spent much time looking through code that hasn't been tightly managed, or that has been managed by a succession of different people with different ideas at different times. Such code is generally harder to understand and harder to program against than code that has conceptual integrity.


Brooks submits that

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. (p. 44, 20th anniversary ed.)

This conclusion is entirely rational but also entirely at odds with those who advocate for a democratic software design process. In a recent Guardian story about Dave Winer's RFC to merge RSS and Atom, Ben Hammersley writes that

The style of the Atom project differs greatly from the RSS 2.0. Whereas RSS 2.0 is controlled by a steering committee of Dave Winer and two others, Atom has been developed by an adhocracy of interested developers, with decisions reached by consensus.

This statement is interesting. You could read a bias into the word choices, assigning negative connotation to the terms appearing around RSS ("controlled", "steering committee") and positive connotation to the terms apearing around Atom ("adhocracy","interest","consensus"). I think there's something to this notion, at least in the author's mind. But from a software engineering standpoint, you would assign the values the other way, because control by a few gives you a chance at achieving conceptual integrity.


We resist the idea, because we're all brilliant developers and surely our feature ideas are worthy and should be included in the spec. But our gut feeling is wrong on this one. And I think the people in charge of Atom probably know this, even if they don't talk loudly about it. You can't have a vote on every feature. At some point somebody has to make decisions, and it's better to have the same one or two people making all of the decisions guided by a consistent notion of how the system should work. The alternative is chaos.


This fact does not devalue the individual. Everyone should be able to air their ideas for consideration by the system designers. And the system designers should be able to incorporate or shoot these ideas down as they see fit. More importantly, there's no reason that a person can't be a leader on one project and a follower on another. Given that we can't all be leaders, most of us are going to have to learn to be followers most of the time.


None of the above is it at odds with the idea of open standards. The Open Standards principles and practice document does not prescribe the number of people that get to design a standard, nor how those people should be chosen. And it shouldn't.