Highly readable post by Tim Bray about how technical reasoning can never provide sufficent answers to most interesting technical questions.The case in point is XML, correctness and how we deal with errors and you could do a lot worse than remembering the following:
There's a spectrum of situations: at one end, if an electronic-trading system receives an XML message for a transaction valued at €2,000,000, and there's a problem with a missing end tag, you do not want the system guessing what the message meant, you want to report an error. At the other end, if someone sends a blog post from their cellphone with a picture of a cute kitten, you don't want to reject it because there's an “&” in the wrong spot. The world is complicated.When I developed domain registration backends for Ascio we had an interesting mix of customers at both ends of this spectrum. We tried to cater both to B2B domain shops that were basically 1 or 2 really good salespeople with zero technical chops or expectations (other than "it has to work") and large retail shops that hated any and all kinds of variation and questions and manual processes because it completely killed their margins (the 'because' is my guess, but from the kind of requests we got it seemed plausible). Catering to both kinds of customers with one system is really hard: The first kind of customer wants a friendly email whenever he does something that's not supposed to work, and then he wants a nice conversation with someone about what he should have done to make it work. He hates it when you turn down an order, because of some minor problem with the paper work. The second kind of customer just wants to not have to think about being our customer, so he'd much rather if we just said no - we can't do that whenever there was any kind of doubt or risk that some kind of manual labor would result from a transaction. Posted by Claus at January 31, 2007 1:05 PM