TruerWords Logo
Google
 
Web www.truerwords.net

Search TruerWords

Welcome
Sign Up  Log On

Adam Bosworth on Keeping Technology Simple, Sloppy

Adam Bosworth on Keeping Technology Simple and Sloppy

Adam Bosworth gave a speech about simplified technologies. His basic message is that simple, sloppy, flexible technology is far more likely to succeed than that which is structured, tight, orderly, and rigid.

I agree with much of what he has to say, especially at the point where technology and humans meet. Web page design and mp3 player controls are both great examples: simple and transparent wins. This is an area where I, personally, have failed miserably a couple of times.

However, I think Adam actually over-simplified his message a bit. He seems to want to apply it to all technology, not just the parts that interact with lay people. The example being discussed all around the web right now is HTML, and the fact that browsers do their best to render really bad html in some sensible way. Adam says that html never would have taken off if it had required CSS: the separation would have been too confusing for the average person.

HTML -- the code itself, not just the web page it produces in your browser -- is a big part of the human-computer interface on the web. Lots of people still learn HTML with the "view source" command in most browsers. It doesn't take anybody long to realize that the bold words they see in the browser match up perfectly with the words surrounded by <b>bold</b> tags.

Yet, I think a separation is needed which Adam omitted. That is, technology infrastructure absolutely does require strictness, conformity, and orderliness in ways that the human interface do not. We don't generally interact with the internet at the infrastructural level: I've never had to write a packet by hand. Thank goodness network stacks and routers don't have to accept sloppiness the way a browser does!

Most HTML these days is not generated by hand, but by software. Long gone are the days when everybody hand coded all their pages, and bragged about it. That doesn't mean that HTML should lose its simplicity, as people can and will continue to learn it with View Source, but it's certainly less essential than it used to be.

Adam goes on to attack SOAP, WSDL, and XML-Schema... three technologies that I've been soaking in for the last couple of weeks.

On the other hand we have the world of SOAP and WSDL and XML SCHEMA and WS_ROUTING and WS_POLICY and WS_SECURITY and WS_EVENTING and WS_ADDRESSING and WS_RELIABLEMESSAGING and attempts to formalize rich conversation models. Each spec is thicker and far more complex than the initial XML one. It is a world with which the IT departments of the corporations are profoundly comfortable. It appears to represent ironclad control. It appears to be auditable. It appears to be controllable. If the world of RSS is streams and rivers and estuaries, laden with silt picked up along the way, this is a world of Locks, Concrete Channels, Dams and Pure Water Filters. It is a world for experts, arcane, complex, and esoteric. The code written to process these messages is so early bound that it is precompiled from the WSDL's and, as many have found, when it doesn't work, no human can figure out why. The difference between HTTP, with its small number of simple verbs, and this world with its innumerable layers which must be composed together in Byzantine complexity cannot be overstated. It is, in short, a world only IBM and MSFT could love. And they do.

Here I both agree and disagree. I agree that SOAP, WSDL, XML-Schema, etc., are thick and very complex. When something goes wrong, it's insanely difficult to figure out what happened (and here I'm speaking from very recent experience). Yet, I disagree with the idea that it should be otherwise. SOAP, WSDL, and XML-Schema are, without a doubt, infrastructure technologies. The common user of web services (for which these technologies were developed) has no more need to understand a SOAP envelope than she does a UDP datagram.

Infrastructure is the foundation on which everything else is built. Would you rather build your home on a giant slab of rock, or on the shifting sands of a desert? It's a lot easier to dig in the sand, or to sink beams, but will the end result be more useful? (Consider other examples, too, like the awesome benefits of the incredibly hard work that went into building the U.S.'s Eisenhower Highway system.)

Yet, the hard work of building a solid infrastructure like SOAP and WSDL can make things much easier for the end users. For example, a WSDL file allows development tools like MS Visual Studio or Eclipse (or even Mozilla!) to parse the entire SOAP API offered by a web service. In VS that allows the web service's objects and methods to be called directly, and they'll even show up in the IntelliSense displays (such as for automatic code completion). In Eclipse and Mozilla, you can automatically create a proxy object for the web service, again making it very easy to access the web service's features.

SOAP is basically an ultra-high-level networking protocol, and WSDL is an ultra-high-level API definition. What would Adam prefer? Should sloppiness be allowed in SOAP messages, so that interpretation is required at the endpoint? Should one SOAP server be able to interpret a poorly-formed request as "translate this message from English into French" while another server understood it to mean "translate this French to English?" That's the kind of mess we get with weak infrastructure and loose protocols.

(I purposely avoided examples involving bank transactions or network security. Use your imagination.)

Page last updated: 11/29/2004




TruerWords
is Seth Dillingham's
personal web site.
From now on, ending a sentence with a preposition is something up with which I will not put. - WC