Skip to main content

Most developers are morons, and the rest are assholes. I have at various times counted myself in both groups, so I can say this with the utmost confidence.


Assholes read specs with a fine-toothed comb, looking for loopholes, oversights, or simple typos. Then they write code that is meticulously spec-compliant, but useless. If someone yells at them for writing useless software, they smugly point to the sentence in the spec that clearly spells out how their horribly broken software is technically correct, and then they crow about it on their blogs.

There is a faction of assholes that write test cases. These people are good to have around while writing a spec, because they can occasionally be managed into channeling their infinite time and energy into finding loopholes before the spec is final. Unfortunately, managing assholes is even harder and more time-consuming than it sounds. This is why writing good specs takes so long: most of the time is frittered away on asshole management.


Morons, on the other hand, don't read specs until someone yells at them. Instead, they take a few examples that they find "in the wild" and write code that seems to work based on their limited sample. Soon after they ship, they inevitably get yelled at because their product is nowhere near conforming to the part of the spec that someone else happens to be using. Someone points them to the sentence in the spec that clearly spells out how horribly broken their software is, and they fix it.

Besides the run-of-the-mill morons, there are two factions of morons that are worth special mention. The first work from examples, and ship code, and get yelled at, just like all the other morons. But then when they finally bother to read the spec, they magically turn into assholes and argue that the spec is ambiguous, or misleading in some way, or ignoreable because nobody else implements it, or simply wrong. These people are called sociopaths. They will never write conformant code regardless of how good the spec is, so they can safely be ignored.

The second faction of morons work from examples, ship code, and get yelled at. But when they get around to reading the spec, they magically turn into advocates and write up tutorials on what they learned from their mistakes. These people are called experts. Virtually every useful tutorial in the world was written by a moron-turned-expert.


Some people would argue that not all developers are morons or assholes, but they are mistaken. For example, some people posit the existence of what I will call the "angel" developer. "Angels" read specs closely, write code, and then thoroughly test it against the accompanying test suite before shipping their product. Angels do not actually exist, but they are a useful fiction to make spec writers to feel better about themselves.

Why specs matter

If your spec isn't good enough, morons have no chance of ever getting things right. For everyone who complains that their software is broken, there will be two assholes who claim that it's not. The spec, whose primary purpose is to arbitrate disputes between morons and assholes, will fail to resolve anything, and the arguments will smolder for years.

If your spec is good enough, morons have a fighting chance of getting things right the second time around, without being besieged by assholes. Meanwhile, the assholes who have nothing better to do than look for loopholes won't find any, and they'll eventually get bored and wander off in search of someone else to harass.


$ lynx -head -dump | grep Content-Type
Content-Type: text/plain; charset=utf-8

[Safari rendering Hixie's XHTML advocacy page]

According to comments by Jens Alfke, the next version of Safari will extend this behavior to sniff for feeds as well:

Also, there is a bit of code way down in WebCore that sniffs the incoming page and, when it detects the start of an XML document that contains RSS or Atom, it auto-corrects the MIME type to application/xml+rss or application/xml+atom.

Words fail me.


Tim Bray is learning Python and using my feed parser to parse the feeds at Planet Sun. I am suitably flattered, and I sincerely hope that one of the 57 lines in Tim's first Python program checks the bozo bit so Tim can ignore the 13 Planet Sun feeds which are not well-formed XML.

One is served as text/plain, which means it can never be well-formed.

Two (a, b) contain invalid XML characters.

Ten (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) are served as text/xml with no charset parameter. Clients are required to parse such feeds as us-ascii, but the feeds contain non-ASCII characters and are therefore not well-formed XML.

On a positive note, it's nice to see that Norman Walsh has an Atom feed (#10 in that list). Pity it's not well-formed. I'm sure he'll fix that in short order. He's no bozo.

You know what I want for Christmas? Markup Barbie. You pull a string and she says "XML is tough."


I was walking across a bridge one day, and I saw a man standing on the edge, about to jump off. So I ran over and said, "Stop! Don't do it!"

"I can't help it," he cried. "I've lost my will to live."

"What do you do for a living?" I asked.

He said, "I create web services specifications."

"Me too!" I said. "Do you use REST web services or SOAP web services?"

He said, "REST web services."

"Me too!" I said. "Do you use text-based XML or binary XML?"

He said, "Text-based XML."

"Me too!" I said. "Do you use XML 1.0 or XML 1.1?"

He said, "XML 1.0."

"Me too!" I said. "Do you use UTF-8 or UTF-16?"

He said, "UTF-8."

"Me too!" I said. "Do you use Unicode Normalization Form C or Unicode Normalization Form KC?"

He said, "Unicode Normalization Form KC."

"Die, heretic scum!" I shouted, and I pushed him over the edge.

(with apologies to Emo Philips)


Following up on my experiment with styling my Atom feed with CSS...

There were 3 major complaints that I noticed in comments, email, and elsewhere around the web:

  1. It required additional markup in the feed, which seemed wasteful
  2. Entry titles weren't displayed as links
  3. It didn't work well in IE

Next step: XSLT. Atom feed + XSLT = styled feed. (View source on each; the last one will surprise you!)

I removed all extra XHTML markup in the feed itself (it's rolled into feed.xsl). I removed the info element that explained the purpose of the feed (also moved to feed.xsl). This Atom feed is as svelte as it can be, but it looks like a regular page in IE 6 and Mozilla. Even the entry links work.

There is apparently some confusion about how this works. Won't it be wasteful for feed readers to download all those images and crap? No, it doesn't work like that. Feed readers download the feed, nothing else. They don't even see the images. How can they not see the images? The images are linked in from the CSS file.

Well, won't it be wasteful for feed readers to download a separate CSS file? No, it doesn't work like that either. Feed readers download the feed, nothing else. They don't even see the CSS file, because it's never mentioned in the feed. So how does your browser find it? When you view the feed in your browser, it transforms the XML into HTML+CSS on the fly, using XSLT (based on the rules in the feed.xsl file).

But I don't want to see your styles in my feed reader! You won't. Feed readers download the feed, nothing else. They don't apply XSLT transformations; they'll still display the feed however they display feeds. But modern browsers like IE and Mozilla look for a particular line in the feed (that feed readers ignore) that tells them to do something more useful than dumping raw XML on the screen:

<?xml-stylesheet type="text/xsl" href="feed.xsl"?>

But now users can't see your XML! When they click on your feed link, you need to show them your XML and get them excited about XML technology! That's the dumbest thing I've ever heard.