Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery
Everything should be made as simple as possible, but no simpler – Albert Einstein
For every problem, there is a solution that is simple, neat, and wrong. – HL Mencken.
There’s a lot of talk recently about the complexity of the XML and web services specs and tools, and advocacy for various alternatives that are supposed to be more “simple.” One recent example is Sun CEO Jonathan Schwartz’s weblog, in which he wondered whether “web services may collapse under its own weight.”
As you know, I also believe simplicity and volume always win – and that today’s web services initiatives are in danger of vastly overcomplicating a very simple (really simple) solution.
There is little doubt that much of the success shown by these technologies is due to their basic simplicity, which makes them fast to develop and easy to use. This idea is not exactly new to XML developers. In fact, the pendulum has swung back and forth a couple of time already in XML’s short history. For example, there was a great XML simplification movement about 5 years ago, and I wrote a little manifesto about what I thought we learned from the experience. More recently, there was a rather long XML developers mailing list thread discussing whether it would be desirable or practical to further simplify XML.
Part of the reason that the pendulum keeps swinging back and forth rather than coming to rest on simplicity is that there are at least three things people mean by “simple” in terms of XML and the tools that work with it:
Clean – simple to understand because something uses a minimum number of concepts. “Elegant”, “having conceptual integrity” are other terms that capture what I mean by this. Minimalist theories such as the Relational Model of Data that account for or prescribe quite elaborate behavior from very similar premises are “clean.” Programming tools such as the LISP family of languages, which have relatively few primitive constructs and are based on a mathematical theory, are also.
Easy – simple to actually use. As O’Grady put it, there is “a relatively low learning curve and few if any barriers to entry.” This is quite different from elegance; few argue that the pure relational model or LISP are easy for ordinary mortals to use. APIs that are designed for ease of use often tend to heavily use overloading, add lots of constructors, and generally add lots of convenience methods, all of which tend to draw the scorn of purists who would prefer to work on the bare metal.
Familiar – Draws on widely understood patterns and principles, making it simple for humans to figure out. “Standards based” is a similar concept if we think of a “standard” as a convention that is followed as opposed to a norm that should be followed. What is familiar to a member of some technology community, however, may be neither elegant nor easy for outsiders to pick up. People have gotten used to APIs such as DOM, or even baroque interfaces such as that of emacs, and find it “simpler” to keep doing what they have been doing as they move to a new environment or project.
The appropriate tradeoffs across these properties vary across projects, technologies, time, and so on. For example, I would have once enthusiastically endorsed this thought by Kurt Cagle:
… by keeping the protocol streams simple, placing more significance on the message than on either sender or recipient [you’ll get better reliability] …. The “Keep It Simple, Stupid” KISS principle is as much a warning to future software developers as it is too anyone else, and vendors in particular forget this warning at their peril.
Today it seems that keeping protocols simple and placing more significance on the message doesn’t decrease complexity, it just moves it around. The SOAP-as-distributed-object paradigm assumes that there is a specific contract that determines what the content of a message might be and how to map it onto programming objects. That’s more complex to specify in advance, but simpler to process. REST says nothing about the content or even the type of resource representation being transferred, adding essentially no contractual burden, but putting all the responsibility for processing the data that is transferred on the application.
This isn’t to say that simplicity isn’t important, just that it isn’t, well, simple. Ideally we want elegance at the core, layers of technology that make that easy to use, and eventually the best interfaces will become so widely accepted that it is intuitive how to use them. Elegant principles such as the relational model, REST, automata theory, and so on certainly have a value, especially to the people who build enterprise infrastructure tools such as DBMS and XML APIs. On the other hand, they generally need to be hidden away from the majority of users who want their technology to be easy to use, not simple for Microsoft to implement, and who want to focus on meeting their users’ needs rather than learning about speech act theory and pi calculus or whatever.
We in the WebData XML team spend a fair amount of time wrestling with these questions. Being geeks, in our hearts many of us would prefer the clean and elegant over the convenient and conventional. Needless to say, that isn’t always the top priority of the people who pay us, or the people who buy our products. Likewise, products based on the technological Right Thing, such as LISP machines or pure relational DBMS, very seldom succeed in the marketplace. But those that attempt to present the illusion of simplicity on top of a foundation that has no conceptual integrity tend not to succeed either. We know you want things to be “simple”, and we’re trying to find the right balance among the goals of elegance, ease of use, and familiarity to those in the XML development community.
(revised March 3, 2005 to fix formatting)