The message that I took away from this article was that good software has to deal with the likely exceptions it will run into in the real world, using real worl

The message that I took away from this article was that good software has to deal with the likely exceptions it will run into in the real world, using real world data. When I built the first version of the Ambient Clock (http://ambientclock.com http://ambientclock.com), I groveled through the vagaries of iCal implementations. It was a nightmare. I breathed a sigh of relief when we decided to use GData: a nice, clean API. But what bit me next was the USER data that was in there. Weirdly formatted, strange timezones, oddball recurrences and other stuff. The nice, clean API can only hide you from so much. My point is that it is hard to write software that deals with human-generated content, in some structured way. As soon as you hit actual people, you can assume that they'll do things differently than expected: using semicolons rather than commas to break up bands, using a different DATE format when specifying things... I believe Joel's definition of 'good software' is software that has learned to deal. And so can be used in a vast number of situations, by a vast number of people.