Share via

It Ain't Easy to be Simple

  • Article

 

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.

 

Of course one could be snarky and note that "JSR-* is 1000x more heavyweight" than WS-*, :-) but that would miss a very real point here. As Stephen O'Grady puts it in All Hail the New Simplicity

Folksonomies. Hula. REST. RSS. XMLHTTPRequest. I think they're symbolic of a technology pendulum that is swinging back towards the simple over the complex.

 

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.

 

Mike Champion

(revised March 3, 2005 to fix formatting)

Comments

  • Anonymous
    March 08, 2005
    I like what Merriam Webster has to say about "simple";

    "9. readily understood or performed"

    As in "It's simpler to integrate services when they expose the same interface, than it is when they expose different ones".
  • Anonymous
    March 09, 2005
    Not that we've ever argued about this before :-) but to me, "interface" means the specification of the operations, and the data, and the details of any higher-level application protocol that is exposed in a multipart service. By the time you do all that in a real-world, machine-machine, multi-stage, mission-critical REST application, you will have reinvented much of WS-*. In that case, you end up something that is "simple as in clean" , but with numerous details of the formats, not to mention the details of the hypermedia that defines the application state machine, that make it any thing but "simple as in easy."
  • Anonymous
    March 09, 2005
    Are you sure we've been over this one before? 8-) I'll try to simplify (as in "make readily understood" 8-) my point by removing data from the equation ...

    When getting exactly the same data from multiple services, it's simpler if all those services expose the same interface, since it means that in order to support N services, I only need to do one chunk of work rather than N.

    Complexity is not always preserved. Simplification is possible. Architectural constraints which induce simplicity are required.
  • Anonymous
    March 09, 2005
    Oh, I recently wrote on Derek's blog that I need a "simple" API. Now I see how shallow it was.
  • Anonymous
    March 09, 2005
    Oleg is referring to my colleague Derek Denny-Brown, who talks about the XML API challenge we are wrestling with at http://nothing-more.blogspot.com/2005/03/serving-many-masters.html. "Shallow" or not, my question to you Oleg is what kind of simplicity do you want? Do you want XOM's design goals of being "easy" (for people who deeply understand XML anyway)? Or do you want more conceptual "cleanness"? That is pretty hard to achieve with XML, because it is rather conceptually messy once you get past elements/attributes/text, and challenging because the XML schema types don't mesh cleanly with the .NET types (or Java types, which XOM neatly gets around by not supporting schemas ... but our customers are not so willing to let us get away with that!). In other words, do you want an API that is simple to learn in that it has a minimal number of classes and methods, or one that is simple to use because it has lots of built-in features to do all sorts of common combinations of operations?

    Most importantly, is anybody really willing to give up the comfortable "simplicity" of what they already know, and go to the effort of learning a "simpler" API?
  • Anonymous
    March 10, 2005
    Hey, I'm not snarky - I have fun! ;-)
  • Anonymous
    March 10, 2005
    I was being snarky by letting you do the talking :-)
  • Anonymous
    March 13, 2005
    Mike,

    Thanks for the link. I think that you're absolutely correct here, not in contravention to what I previously wrote, but that the struggle for simplicity often tends to become an issue of what vector in the complexity bundle you most wish to optimize.

    I have long believed that your statement "Today it seems that keeping protocols simple and placing more significance on the message doesn't decrease complexity, it just moves it around." is true about programming in general. Programming is the art of of figuring out where best to dump the complexity inherent in any human domain problem, and I've often wondered if complexity is inherently a zero-sum game: you can never destroy complexity, you can only redistribute it.

    -- Kurt
  • Anonymous
    April 22, 2005
    I've been a bit out of the habit of writing here - for the last couple of months most of my free time...
  • Anonymous
    September 18, 2005
    Who said "There's only really one metric to me for future software development, which is
    -- do you...
  • Anonymous
    June 09, 2009
    PingBack from http://greenteafatburner.info/story.php?id=4528