Share via

The Model T and the Prius: Simplicity vs Complexity, yet again

  • Article

My favorite conundrum, the difficulty of being simple, pops up everywhere I look these days. 

I had an epiphany shortly after buying a Toyota Prius recently:  The thing is an absolute Rube Goldberg machine under the hood, but is if anything simpler to operate than an ordinary car. By contrast, the Ford Model T was so simple in design that it came with all the tools needed to maintain and repair it, and a generation or two of backyard mechanics learned how to do just that.  It got 25 miles per gallon, better than Ford's typical product today. The Prius, on the other hand, is so backyard mechanic-unfriendly that the 12 volt battery is sealed away under the trunk; there is apparently no way even to use it to perform that one bit of auto repair that almost anyone can do, jump-start another vehicle.  But that complexity returns a big benefit - a Prius has all the interior size and environmental comforts of a conventional midsize sedan, but twice the fuel efficiency of the simple, uncomfortable Model T (and 3-4x that of Ford's current best seller).  The complexity is mostly hidden away from the driver; the only  leaks in the abstractions that make it look like an ordinary car are the tricks one can use to optimize fuel economy.

I noticed that Len Bullard recently made essentially the same point I am trying to make:

So it is with the modern combustion engine: it works, it is efficient with respect to the power delivered for the fuel and the weight of the overall vehicle, thus adding more efficiency, but it is not something that the average backyard mechanic can rebuild. The tools required, the parts required and the knowledge of how they work in combination exceed his or her resources, understanding and nerve.

Complexity is just as much in the nature of the evolution of systems as simplicity is desirable. At some point, the demands of an environment or a market require complex solutions. While simplicity is a goal, it can also become a religion just as harmful as fundamentalism when pursued with a sword. Complex systems can do what simple systems cannot do. The goal that all systems be accessible can be met with open standards, but the goal that they be powerful, workable and light might not even as the principles over which they are built remain the same.

Now Donald Norman, the guru of high design, weighs in:

“We want simplicity” cry the people befuddled by all the features of their latest whatever. Do they really mean it? No.

But when it came time for the journalists to review the simple products they had gathered together, they complained that they lacked what they considered to be “critical” features. So, what do people mean when they ask for simplicity? One-button operation, of course, but with all of their favorite features.

Joel Spolsky elaborates:

In the case of the iPod, the way beauty is provided happens to be through a clean and simple design, but it doesn't have to be. The Hummer is aesthetically appealing precisely because it's ugly and complicated.

I think it is a misattribution to say, for example, that the iPod is successful because it lacks features. If you start to believe that, you'll believe, among other things, that you should take out features to increase your product’s success. With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features

Gadgetopia summarizes -- "you need features, but they need to appear  simple to the end users". 

There's a name for the discipline of working within a network of complex constraints to produce something simply usable - engineering.  It's not easy to get the complicated system of batteries, motors, charging systems, and drivetrain in a modern hybrid car to work together efficiently, but some very clever engineers managed to do that.  Those who dismiss various XML technologies, or XML itself, because of ugly complexities or unpleasant constraints may someday look as prescient as the folks in the auto industry who killed off the electric car in the 1990's, only to be humbled by the engineers who made the hybrid system practical a few years later.

OpenXML, WS-*, XSD, and XML for that matter are not doomed because they are complex, nor are they destined for success because they attempt to hide their complexity from the end user.   Those who build infrastructures and applications on top of them are challenged to do good engineering to make their purported features actually work and to appear simple to the ultimate consumers.  In the long run we'll probably end up more or less where automobiles are now - complexity under the hood that would inspire Rube Goldberg, but engineering quality that makes it appear simple to the driver.

Reasonable people can disagree on whether we are currently on the right track to making this happen.  If we are, the yelping in the blogosphere might be dismissed as backyard mechanics lamenting the fact that "enterprisey" applications can't be built with hand tools anymore.  If the critics are right, we could plausibly be in the midst of a disruption akin to the 1970's consumer revolt against Detroit-made gas guzzling behemoths in favor of smaller, better-designed imports. We shall see, but the answer is not at all obvious despite various "Mission Accomplished" declarations by one faction or another.

 Here what  I (personally ... obligatory disclaimer about not speaking with the xmlteam hat on) think about the technologies listed at the top of this post with respect to the simplicity/complexity dilemma:

OpenXML document format vs the Open Document Format? Nobody wins, neither loses.  Specialized libraries and hard work will make OpenXML appear simple enough for most purposes; the underspecification in ODF (e.g. for spreadsheet formulas) will be remedied with spec revisions that add complexity. Actual users will seldom know or care about the underlying formats because modern office apps are already doing a decent job of making all that stuff look simple.

W3C XML Schema vs RELAX NG? There's lots of room for evolution here; neither will win in the long run, but something will emerge that steals ideas from both.  XSD 1.1 already addresses some of 1.0's  more egregious flaws and incorporates a lot of ideas from Schematron.  In the "2.0" timeframe I'd expect a hybrid schema language that incorporates the best ideas from all three (although I don't know which organization or company that will come from).  It will be as "complex" as XSD measured in features, spec size, etc. but more like RElAX NG in terms of formal underpinnings and readability.

WS-* vs REST?  We'll end up with a composite Web/Enterprise architecture that has simple REST-like concepts at the core that will continue to be used by "Web 1.0", but can be more cleanly (than the current WS-* stack) extended to allow multi-hop / multi-protocol reliable messaging, security protocol negotiations, etc.  Even if the WS-* stuff disappeared, someone would quickly reinvent something very similar because the REST primitives are just too primitive to appear simple to any but the most zealous backyard mechanics.

XML vs JSON? I'm still undecided about this.  I'm feeling just a bit smugly prescient these days because I was once a flamethrower in the "XML is too complex" wars, and people are finally voting with their feet against XML's complexity.  On the other hand, XML has gotten so pervasive now that I don't see how JSON can achieve success as a data interchange standard (outside the AJAX realm) by the classic disruptive route of  competing with non-consumption.  It would be lots of fun to reinvent a JSON-based stack-o-stuff to give it a schema language, transformation language, query language ... not to mention a "LINQ to JSON" API!  I'm not so sure that our customers would find it fun to endure that disruption, however.  A well known and vocal colleague [hint: he likes to remind me that DOM means 'dumb' in Dutch] thinks I'm a corporate drone wimp  :-) for that view ... what do you think?

Comments

  • Anonymous
    December 10, 2006
    The comment has been removed

  • Anonymous
    December 10, 2006
    " Those who build infrastructures and applications on top of them are challenged to do good engineering to make their purported features actually work and to appear simple to the ultimate consumers. " Well, what do you mean by that? Do you mean that people who build XML Schema validators are challenged to do good engineering or that the users of XML Schema to describe their data structures are challenged to do Good Engineering? I suppose that the both is of course true, but surely one  example of really good engineering would be not using XML Schema to describe ones data structures given the well known incompatibilities between validators in a number of areas. If I am starting out on a project shouldn't one of the primary considerations be choosing tools that are stable? The same applies to WS-*

  • Anonymous
    December 11, 2006
    The comment has been removed

  • Anonymous
    December 11, 2006
    This argument sounds a bit forced to me. Part of your argument seems to be <i>it is a poor artist who blames his tools</i>. You suggest that it is your users (developers) who must make the effort to make the system beautiful, but it sounds a bit too much like a tool-maker griping. If it is indeed true that these complex tools are not only capable of being used to create beautiful systems, but actually <b>required</b>, then the proof will come with the applications. No amount of talk will convince anyone. The backyard mechanics were not silenced by reasoned arguments, they were (for the most part) silenced by the newer cars themselves and how the public embraced them. What I think is important to remember is that there is tension between complexity and simplicity at various scales. You address the fact that users want complex systems that appear simple. But it is also the case that developers want to use simple tools to build complex systems that appear simple to users. This is not unreasonable. Our entire industry is predicated on the power of abstraction: the encapsulation of complex functionality in simple interfaces. The only way to build more complicated layers of technology is to simplify the way the previous layer is used. You can't just push the burden of abstraction up to the next level. I don't think any inherent complexity of WS-* or XML is really problematic. What is problematic is much more mundane: incompatible implementations and a difficult debugging story for WS-*, and verbosity for XML. If the complex functionality enabled by these technologies was simple to use, I don't think you'd see the same complaints about complexity. Instead, we are surrounded by working examples that force us to ask what we stand to gain from these more unwieldy tools. Consider the Ruby language: even the most partisan user of the language would agree that the internals of the runtime are frighteningly inelegant, yet the language itself is heralded as a shining example of a simple-yet-powerful tool for developers. While you may see this as an issue of developers resisting the new capabilities of these technologies, your post could also be characterized a claim that "hard to use" is positively correlated with "more capable."

  • Anonymous
    December 11, 2006
    Good stuff. I think the most important thing is to understand what tradeoffs you are making and why. From a security perspective this is called risk management. From a security design standpoint, yes a vanilla REST implementation looks a lot simpler than SOAP and WS-Security, but what happens if you figure out that SSL is terminated about 6 hops away from your app? Then you realize that message level security actually is important, and bolting it onto the side of your REST app may actually make something that is less secure (less proven) and more complex. Bad tradeoff. This is just one example, YMMV even in a Prius.

  • Anonymous
    December 11, 2006
    Anthony, yes the argument by analogy is a bit forced, as are all arguments by analogy :-)  The whole thing is just a meditation on my epiphany that the hybrid car architecture mind numbingly complex ... but I don't care. (Assuming it continues to work for the expected lifetime of the car ... obviously that's a risk I'm taking as a relatively early adopter). That's an interesting point that "you can't push the burden of abstraction up to the next level".  I'll have to think about that -- whether I agree, and what it implies for XML-ish stuff.   I'm certainly not claiming that hard to use == more capable.  I'm claiming that complexity per se is not a showstopper, contrary to the implications of numerous sneers against WS-* or XSD. "Hard to use" is a showstopper at the user level, so the question is whether the more complex stuff can be more easily wrapped up in a simple interface than the simple stuff.  Developers should be resisting XSD now because it's too hard.  Is the way forward to hide it behind databinding / mapping / code generation tools, or ask people to learn something "simpler" but still not what they are asking for? I don't think there's an obvious answer.

  • Anonymous
    December 11, 2006
    The comment has been removed