The Power of No
February 1, 2006
I remember a trip to Tijuana, where on Revolución Avenue, a carved chess set caught my eye. For several minutes I gazed admiringly at it, feeling the rough texture of the carved stone pieces. It was a very special one, the shopkeeper assured me, but since he got a such a good deal on it he could let it go for $100. The rest of my group had already left, so I politely headed for the door to join them. "Wait!" the shopkeeper called. "$80?" Twenty dollars off wasn't bad, but still, I had to get going. I moved toward the door again without saying anything. "$60?" he called out to me. I hesitated. "$40?"
In conversations on the general topic of XML annoyances--and I've been in more than my fair share of them--the discussion inevitably centers around lament over specific features. "Why did they add (insert feature name here) to XML?" or less gentle variations thereof. Yet the forces that aggravate XML pros and newbies alike can almost always be attributed to a great power I first noticed on that trip to Mexico: the Power of No, which I think might actually be the primary natural force in the universe. Let's take a closer look at the Power of No and some examples.
XML itself is based on the Power of No: XML imposes a level of structure beyond plain text. The vast majority of random strings of characters won't qualify as XML. This ties in with basic definitions of information, uncertainty, and entropy. I think my favorite is the definition of uncertainty as "weighted average surprisal." By way of rules that reject non-well-formed sequences, what's left over--that is, XML itself--has less potential for "surprisal". As a result, writing a conforming XML parser is orders of magnitude easier than writing a parser for, say, general stuff you might find on the Web. Or so the theory goes.
Specific XML vocabularies too are based on the Power of No. Defining a specific application of XML narrows down a set of possible XML documents to ones meeting specific criteria: element names, content models, attribute names, namespaces, and so on. Further, a well-designed vocabulary will have even more constraints, though possibly harder to quantify, such as separation of concerns, or use of intentional markup.
Microformats are even more constrained, since they exist within the framework of an encompassing vocabulary--a rejection of more flexible schools of markup language design. A large portion of the criticism directed at microformats can be described in terms of taking constraints too far.
Advocates of REST also use the Power of No, but again phrased in the language of constraints. These examples show that the Power of No is pervasive and fundamental, manifesting itself time and again in widely varying systems and subsystems. The examples so far also haven't been very controversial, showing what many would consider important features of the Web and modern computing practice.
No As Found in Natural Systems
Discussion to this point has focused on explicitly technical levels--architectures, patterns, and designs. Can the Power of No extend to areas outside of computer science, into the slippery realm of nature and human nature?
Think about a software product launch in its entire sprawling form over time--much more than engineering. Involved are levels of product managers, marketing folks, beta testers, QA staff, and others all working towards a common goal. The overall effectiveness of the project depends to a great deal on the ability of individual players to make wise decisions. As a result, the process has countless potential outcomes in which a product might have flaws or annoyances, but very few outcomes that come out flawlessly. The nos push the result toward the ideal.
One more example: take a typical fluff question in an interview, like, "If money were no object, what would you do?" Don't get too carried away on a shopping spree--even if money is unlimited, one person can enjoy only so many things in life. Available time is constrained, so careful trade-offs need to be made--deciding not whether but when to say no.
I could cite more examples, like the Tijuana experience. Suffice it to say that the Power of No appears in lots of places if you're willing to look hard enough.
With Great Power (of No) Comes Great Responsibility
Getting back to the arena of standards, recall that the XML specification was forged by a process that has strong hints of natural selection and managing constrained resources, modifying an existing standard to meet a new set of requirements. The W3C maintains an elaborate process document describing in painstaking detail the official process used at any given time to develop Recommendations and other technical reports. The primary tenet of the process, though, lies in consensus, which the document also describes in detail. Consensus works because the ability of participants to say no virtually ensures that incoming proposals get optimized before getting signed off.
The most successful projects I've seen at the W3C had a small core of talented architects, often just a single person, surrounded by a larger group that had relatively few problems forming consensus around the brilliant original design. In groups that lacked a cohesive architectural center, the results tended more towards the dreaded "design by committee."
In particular, Working Groups with large numbers of participants early on seem to have a poor track record in the area of focus. Diverse subsets of the overall group each push for features they care about, with the resulting technical report covering the entire union of many different proposals. Things that come from this sort of group often become popular due to sheer political force, but leave developers gnashing their teeth along the way.
The opposite can be a problem too--a group can become too focused, relying on an echo-chamber effect in lieu of genuine consensus from a wide spectrum of interested parties. Such groups also tend to have a limited or overly literal view of what problem they really are trying to solve. One result of this is the word "standard" becoming nearly an epithet in certain circles. A badly formed or "rubber-stamped" standard is far more annoying than no standard at all.
Putting the Power of No to Work for You
Thinking in terms of the Power of No can offer a fresh perspective on many aspects of XML and XML projects. Many times removing code, features, or requirements can make the difference between a good product and a great one. Pay attention to the negative space in a vocabulary or product design. Keep in mind specific anti-goals that should be avoided.
It goes without saying that a major development project should have a solid architect at the core. A good architect needs to be able to separate personal preferences and prejudices from legitimate good design points--in other words, get the focus right. A concrete measure of an architect is whether outside groups--even ones that wouldn't normally be directly involved--are able to understand and accept the architecture. There will be times where it's just not possible to please everyone to the level of consensus, but still it provides a measuring rod against which to evaluate a design (or a designer).
To anyone considering designing a new XML vocabulary: remember the Power of No. If you absolutely have to design a new vocabulary, shoot for a minimum of weighted average surprisal.
Finally, for those annoying things which we have no power to change, at least understanding a bit more about how they came to be can help ease the suffering of dealing with them on a recurring basis.
And as for the Tijuana chess set--I ended up saying no.