lesscode.org


Motherhood and Apple Pie  

By Ryan Tomayko under Then they laugh at you... on 21. July 2005

The internet is not an accident. The internet was not bound to happen. There was no guarantee that the internet would reach its current state as a side effect of emerging digital processing and communications capabilities. We did not recover complex alien technology.

The internet, that place where all eventual business will be transacted, all content and media will be distributed, all correspondence will be exchanged, all history will be recorded, and all pornography will be is being admired, has a design - and its meant for exactly these purposes.

Many of the principles that led to this design are still with us today, although I would challenge you to ascertain them by observing the mainstream technologies being peddled by leading vendors, publications, and analyst firms. Those who rose to power in a much different environment, where the short-term profits of disconnected, dead-end business software was deemed more important than laying a fertile ground where millions of new ideas (and hence new profits) could bloom.

But the dead-end has long been reached and so these industry leaders have turned their attention to this new place, built on principles and values very different from their own, and have somehow reached the conclusion that this thriving ecosystem must be re-arranged such that they have somewhere to place their baggage. Instead of embracing the people, principals, and technologies that gave rise to this phenomenon they have chosen to subvert its history and to implant the ridiculous notion that it is “incapable of meeting the stringent demands of the business community.”

Not only have these business radicals claimed the internet as their own but they have also somehow gained the confidence of all the worlds industry in their ability to deliver a new and sparkling internet, one no doubt capable of reproducing the complexities and flaws that plague existing mediums so as to make it feel more like home. They’ve brought their own principles and agendas, asserting them as obvious and correct while ignoring the wisdom we’ve gained and shared and gained and shared over years of collaborative practice and observation of working systems at this scale.

But business is something for which I’ve acquired admittedly little competence and so I would like to transition now and lay rest to this insulting notion that the tools and methods that dominate the modern web are of lesser quality and modernity than their big-vendor, enterprise class, industry accepted counterparts. The arrogant assumption that the people who built this place have been waiting idly by with suboptimal processes, tools, and protocols in the hopes that one day the masters of proprietary business software would bless us with their advanced capabilities. The rhetoric that suggests that the tools used to provide a brunt of the value on the internet are somehow expired, inelegant, or lacking in technical merit.

In an attempt to bring some semblance of reality to the conversation, I would like to present to you, Tim Berners-Lee’s Axioms of Web Architecture, otherwise known as “Motherhood and Apple Pie”. First recorded in one place by Tim in 1998, these principles had been around and were well known for many years before. Some trace back to early computing and some predate computing and were taken from such practices as mathematics.

These are the principles of design that have brought us where we are today and you can observe them working as designed in protocols and formats such as HTTP, URIs, MIME, HTML, and even XML (sometimes), and architectures such as REST. And you can observe them working in systems that facilitate the internet - tools such as Apache httpd, PHP, Perl, Python, C, UNIX, and newcomers such as Linux, PostgreSQL, Ruby, etc.

I present these principles now as evidence that we are quite aware what it is we’re doing and that these tools and protocols are the way they are for a reason. We realize that they are in many ways quite different from their analogs in the old-world of narrowly distributed business software but we ask that you please consider their design in the context of the ecosystem where they flourish and ponder whether this might not be coincidence.

The principles of design that have shaped the web and tools that underly it (again, from Axioms of Web Architecture):

  1. Simplicity
  2. Modular Design
  3. Tolerance
  4. Decentralization
  5. Test of Independent Invention
  6. Principle of Least Power

Simplicity

We begin our look at the design principles of the web with the most important aspect of design in any system - simplicity. Note that the best way of mixing the basic aspects of design (simplicity, consistency, correctness, and completeness) is a topic that’s been debated for decades. However, all major styles of design agree that “simplicity” ranks first.

From Berners-Lee’s Axioms:

A language which uses fewer basic elements to achieve the same power is simpler.

Sometimes simplicity is confused with “easy to understand”. For example, a two-line solution which uses recursion is pretty simple, even though some people might find it easier to work through a 10-line solution which avoids recursion.

Simplicity is sometimes defined as a measure of the number of parts required to make a thing work while retaining clarity. If one design requires many parts while another requires few, the latter is said to have a greater level of simplicity.

As an example, which of the following equivalent operations is more desirable?

2 ** 5

or…

2 * 2 * 2 * 2 * 2

While the first solution requires a slightly higher level of understanding it is indeed the simpler because it more clearly captures intent using fewer parts.

Note that “simplicity” is not a synonym for “a hack” or “quick-and-dirty”. Neither is it equivalent to “dumbed-down”. Another example might illustrate these differences:

One way to print a simple message …

public class WeReallyLikeClasses
{
   public static void main(String[] args)
   {
      System.out.println("hello world");
   }
}

and another way…

print 'hello world'

The former provides very little advantage over the latter while requiring more elements. The second example is said to be the simpler and thus is highly desirable. This is an admittedly simple case, which is kind of the point, but this might be a better example.

So I would like to impress upon you that the languages that dominate the web are not the way they are because we lack the ability to build more complex, sophisticated, flashy tools and languages, they are that way because we assume extra complexity is unnecessary until proven required and we see very little evidence to support the inclusion of the complexities that have been introduced into “enterprise class” software over the past decade.

Modular Design

The web’s core architecture and many of the tools that facilitate its operation are extremely modular in design. In fact, in my recent writing about the “LAMP stack” I’ve grown an aversion to the term because what I really wish to convey is not simply the base Linux, Apache, MySQL, and PHP components but near 20 very specific and modular pieces that can be combined in various ways to craft a targeted overall solution to a given problem domain. What about the BSD, lighttpd, PostgreSQL, Ruby configurations? The term LAMP should not exclude them — you can mix any one of the LAMP components into this configuration due to the high level of modularity of each piece.

Again we quote TBL:

When you design a system, or a language, then if the features can be broken into relatively loosely bound groups of relatively closely bound features, then that division is a good thing to be made a part of the design. This is just good engineering. It means that when you want to change the system, you can with luck in the future change only one part, which will only require you to understand (and test) that part. This will allow other people to independently change other parts at the same time. This is just classic good software design and books have been written about it. The corollary, the TOII is less frequently met.

And so it is with great interest that those who understand the principle of modularity and the benefits it provides in web-like environments watch as industry leaders now make such senseless claims as these:

Having products that are engineered to work together–something open-source competitors cannot do–will ultimately make Microsoft products easier to run and more cost-effective over time, said Paul Flessner, senior vice president of server applications.

As you can infer from the quote, it is not the principle of modularity that drives these components into separate pieces but an inability of “open-source competitors” to make things “work together”.

This is especially disturbing when the company making the claim has demonstrably poor modularity that is widely considered to be one of the most significant deterrents to progress on their platform.

Tolerance

Tolerance is another well-understood and very obvious principle of the web and the tools that support it:

“Be liberal in what you require but conservative in what you do”

This is the expression of a principle which applies pretty well in life, (it is a typical UU tenet), and is commonly employed in design across the Internet.

Write HTML 4.0-strict. Accept HTML-4.0-Transitional (a superset of strict).

This principle can be contentious. When browsers are lax about what they expect, the system works better but also it encourages laxness on the part of web page writers. The principle of tolerance does not blunt the need for a perfectly clear protocol specification which draws a precise distinction between a conformance and non-conformance. The principle of tolerance is no excuse for a product which contravenes a standard.

Again, adoption of this principle by leading vendors in their attempts to bring the business community to the web are sorely lacking. The complexities and required aspects of vendor driven specifications and tools guarantee that they will never be capable of doing for the business community what the web has done for the general public.

Decentralization

This is a principle of the design of distributed systems, including societies. It points out that any single common point which is involved in any operation trends to limit the way the system scales, and produce a single point of complete failure.

While AOL and Microsoft’s Passport are perfect examples of how ignoring the web’s basic principles can lead to disaster, I won’t go into it due to severe lack of challenge and therefore motivation.

However, I would like to note that this principle applies not only to technology but also to the structure of business, vendors, and communities. There are far too few vendors providing far too many services to the business community. Many vendors and analysts actually encourage companies to become completely dependent on a single vendor (as in, “we’re an IBM shop”). A better strategy for businesses is to diversify their technology providers between many smaller vendors that each provide tools and services adhering to the basic principles of the web and thus providing a base level of interoperability and freedom.

Those vendors don’t exist in great numbers at present, but they will.

Test of Independent Invention

This has strong ties to the principle of modularity and, again, is observable in most of the pieces we consider part of LAMP/friends.

If someone else had already invented your system, would theirs work with yours?

Does this system have to be the only one of its kind? This simple thought test is described in more detail in “Evolution” in these Design Issues. It is modularity inside-out: designing a system not to be modular in itself, but to be a part of an as-yet unspecified larger system. A critical property here is that the system tries to do one thing well, and leaves other things to other modules. It also has to avoid conceptual or other centralization, as no two modules can claim the need to be the unique center of a larger system.

Principle of Least Power

The Principle of Least Power is perhaps the most visible in the tools and technologies that have gained wide spread acceptance on the web and at the same time the least understood. Languages like HTML, PHP, and RSS are perfect examples of the strange adoption rates “least power” systems enjoy.

I will quote TBL in his entirety because he explains the principle so well:

In choosing computer languages, there are classes of program which range from the plainly descriptive (such as Dublin Core metadata, or the content of most databases, or HTML) though logical languages of limited power (such as access control lists, or conneg content negotiation) which include limited propositional logic, though declarative languages which verge on the Turing Complete (PDF) through those which are in fact Turing Complete though one is led not to use them that way (XSLT, SQL) to those which are unashamedly procedural (Java, C).

The choice of language is a common design choice. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer.

Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person.

I hope that is a good enough explanation of this principle. There are millions of examples of the choice. I chose HTML not to be a programming language because I wanted different programs to do different things with it: present it differently, extract tables of contents, index it, and so on.

I hope re-stating these principles at this point in the evolution of business on the web might help illuminate why leading vendors currently seem incapable of bringing the magic of the web to the business community - they don’t understand its basic principles. And instead of attempting to understand these basic principles so that they may apply them for the benefit of their investors, customers, and industry partners, they are attempting to discredit them.

This should also clear up any questions as to why IBM and other progressive companies are moving to adopt technologies such as Linux and PHP, why Google and Yahoo are so successful, and why many of us feel Python and Ruby have an edge on more traditional languages designed for the slowly deteriorating world of unconnected business software.

The good news in all this is that there is a resurgence of interest in the web’s basic principles that is somewhat oriented toward the business community. I believe this renewal of interest to be the result of increased communication through weblogs and other web-friendly collaboration tools combined with massive adoption of free and open source development methods. The bad news is that a huge portion of the software industry isn’t involved and are in many ways blocking progress using techniques that are hard to describe as anything other than dishonest.

(I reserve the right to make changes to this document after sleeping a bit. Please log suggestions and corrections using the comments sections below)

24 Responses to “Motherhood and Apple Pie”

  1. Le Roux:

    This is the best thing I’ve read in a while. I love this site and your writing and I’m sending the link to all teh programmers I know. Especially the java guys - whom I feel sorry for. In too many companies technology decisions are made by the wrong people and for the wrong reasons.

    I’m very excited - I think things are about to change. I think Python, Ruby, etc. are reaching a critical mass and more people are starting to take notice. A lot is happening lately. (Django is the first thing that came to mind - can’t wait to play with it!)

    comment at 21. July 2005

  2. The Hand of FuManChu:

    Are we on the downhill side yet?

    Ryan Tomayko hits one out of the park with his post, Motherhood and Apple Pie. It is the best summary I have read of the state of affairs in software development today, and the competing direc…

    trackback at 21. July 2005

  3. DJ Adams:

    Agree entirely. Nice post, very well put. Coincidentally I had written something on the same day that touches on the same theme - Whither SAP? - on SAP finding it difficult to change from resisting to embracing the tools and technologies you mention.

    comment at 22. July 2005

  4. philmccluskey.com codestream » Blog Archive » Axioms:

    […] A terrific essay by Ryan Tomayko on the design principles that underlie the web. […]

    pingback at 22. July 2005

  5. Bill Higgins:

    Hi, I haven’t had a chance to read through the whole essay yet (it looks interesting but the length is an inhibitor until the weekend). Just wanted to drop a couple of book recommendations on this subject matter:

    comment at 22. July 2005

  6. DavidOHara.Net » Blog Archive » “And for his next trick…”:

    […] Once again, Ryan is able to produce writing that is clear and concise as well as on point for the current state of web development with “Motherhood and Apple Pie”. The revolution is coming and whether “Big Business” likes it or not, it looks like the future will not be “owned” by any specific vendor or platform but an amalgamation of the best tools to get the job done (and done right). Some may be open source, some may be proprietary but all MUST be good at what they do to survive. Man, this excites me… […]

    pingback at 22. July 2005

  7. maetl:

    It’s funny, I was just wondering how often peoples resume’s actually list skills like “developing distributed hypermedia applications”…

    I’ve been looking around, and it seems like hardly anywhere, in a sea of tutorials, guides, how-to’s, on frameworks, methodologies, design approaches, is there a focus on resource design being of singular importance, of HTTP being the command line interface to distributed media. Why do so many people think that URI’s are irrelevant to the design of their web applications?

    It’s funny that the world of HTTP, dom scripting, etc, the text file ecosystem that was promised 6 or 7 years ago is only just now starting to reach its potential, but even the fact that I can say that it is, must be a very positive and encouraging sign. People are finally starting to understand why the web has been set up the way it has. The sad thing is that it’s been like that all along.

    A commendable post - much appreciated.

    comment at 24. July 2005

  8. Bill Higgins:

    Finally made it through this essay - good stuff. I could probably comment on five or more different parts of it, but I will select just one for brevity.

    Your discussion of simplicity was a good one, but I’d like to discuss one point. You said:

    Simplicity is sometimes defined as a measure of the
    number of parts required to make a thing work while
    retaining clarity. If one design requires many parts
    while another requires few, the latter is said to
    have a greater level of simplicity.

    I think we have to say that “simplicity is in the eye of the beholder”. In other words, what is simple to one person may be intractably complex to another. E.g. your 2 ** 5 example - while you and I can agree that 2 ** 5 is a simpler representation of the solution, to a 9 year-old who is just learning multiplication, 2 * 2 * 2 * 2 * 2 may be simpler, despite its relative verboseness.

    Moving past this trivial example into the world of programming, I remember when I was a freshman in college just learning to program in C, I would occaisionally see graduate students’ solutions to some problem in very dense, terse code that captured a great deal of knowledge and technique in very few elements. Unfortunately, because I was so new to programming I could stare at a short program for an hour and have no idea what it was saying.

    So from these examples, I think we can agree that simplicity is relative based on the knowledge and skill of the observer. So we can do one of two things:

    1. Be willing to dumb-down certain designs that would otherwise be incomprehensible to a large number of people, or
    2. Be willing to mentor people who don’t understand more sophisticated design patterns

    Now, in the case of your “print ‘hello world’” example, this isn’t even an issue because the elements used are already so simple that anyone should be able to understand them - especially vs. the convoluted Java equivalent.

    One other thing re: “simplicity is in the eye of the beholder”, this is definitely true when we think about the actual number of parts required to make something work vs. the apparent parts. I can’t think of a good example so this will have to be abstract, but simply put, a line of code is ultimately translated into one or more actual machine instructions that the CPU executes. So it’s possible that if we have two representations of the same solution (e.g. 2 ** 3 vs. 2 * 2 * 2) that the solution that’s simpler from the programmer’s perspective may in fact result in more CPU instructions (not in this example perhaps but I’m sure you can extrapolate). I’m not saying that this is a bad thing - remember: “premature optimization is the root of all evils” - but it helps fortify my position that simplicity is very subjective.

    comment at 24. July 2005

  9. Web Thinking (with bonus Feynman quotes) [@lesscode.org]:

    […] But even if you don’t care about databases or Atom/RSS (let’s say you build loan approval or payroll processing applications) you can still get a lot from this talk by simply observing the style of thinking Adam demonstrates. This is exactly what I’m trying to encourage with Motherhood and Apple Pie and I’d like to use Adam’s talk to illustrate the different ways you can think about the web because Bosworth’s talk is a perfect example of The Right Way. […]

    pingback at 25. July 2005

  10. Viamentis Technologies:

    Principles of Design

    Wow. This is cool. Here’s a nice article called Motherhood and Apple Pie by Ryan Tomayko on lesscode.org. Though the article rephrases mostly Tim Benners-Lee’s Principles of Design, it led me across some very interesting articles - which led me to re…

    trackback at 26. July 2005

  11. Prashanth Rao’s Weblog » Blog Archive » Principles of the Internet:

    […] Ryan describes the origins and principles of the Internet in a rather idealistic manner proposing a polarity between the founding principles of the Internet and the needs of the business world. He has a particular disdain for the big “tool” vendors and their arrogant claims for representing the best interests of the Internet. Ryan’s views, though idealistic (which I also agree with), perceive the Internet as something that is NOT to be controlled by global corporations. The Internet, for him, is something that was created based on sound technical and social principles. And these principles are now being subverted not for the greater good of humanity, but rather for the financial profit of large corporations. Nevertheless, the Internet is too vast and varied for any single force to dominate, which is where open-source, REST, the P-languages come into play. […]

    pingback at 26. July 2005

  12. Neil Ward-Dutton:

    A good, thought-provoking piece Ryan.
    But I agree with Bill Higgins (8): simplicity is absolutely in the eye of the beholder. The corollary of this (not explicitly brought out by Bill) is related the beliefs/experiences of the companies providing “enterprise class” software, and is at least part of the reason why comparatively few, large companies control a lot of the tech real estate that exists in mainstream businesses.
    In general, businesses can’t hire the best programmers. Software companies tend to that. The universe of “business programmers” has widely varying levels of skill. Some want and need highly expressive tools and languages: most (and certainly the business bosses of most) just want to get things done as quickly and easily as possible. Those vendors you keep obliquely referring to often have to target this diverse group of averagely skilled people. The result is… well, the result that you often see.
    Some of what you say makes perfect sense to programmers who love neat technology, and have the skill and time to use it to get the best possible results. Most of the people building software in the world are not in this category.
    I have plenty else to say but I think this is about the polite length limit for a comment!

    comment at 27. July 2005

  13. Ludo|Blog » Lesscode:

    […] L’ho consigliato su Qix qualche tempo fa ma non fa male ripeterlo qui: se vi interessa l’evoluzione prossima futura del Web e volete controbilanciare un po’ i troppi post di PR o dei soliti egomaniaci, fatevi un giro su lesscode.org. Particolarmente consigliati: Web Thinking, Web Architecture Roundup, Motherhood and Apple Pie. […]

    pingback at 28. July 2005

  14. Douglas Clifton:

    I had trouble reading your essay and these comments and not seeing anyone mention another outstanding document published by the W3C: Architecture of the World Wide Web, Volume One.

    Run, don’t walk. ~d

    comment at 01. August 2005

  15. developers.org.ua » Blog Archive » Weekly linkdump:

    […] Motherhood and Apple Pie - The principles of design that have shaped the web and tools that underly it. […]

    pingback at 06. August 2005

  16. [@lesscode.org]:

    […] […]

    pingback at 28. August 2005

  17. Kishore Balakrishnan’s Blog » Blog Archive » links for 2005-09-02:

    […] Motherhood and Apple Pie [@lesscode.org] (tags: 2do/read article) […]

    pingback at 01. September 2005

  18. John Cowan:

    Compare Eric Raymond’s list of Unix design principles, which express the essence of the Web architecture before the Web even existed.

    comment at 15. October 2005

  19. Rajblog » Blog Archive » Another perspective on Java:

    […] This is really interesing rant again Java. In the same vein, this article was mentioned in the comments. Filed under: computers […]

    pingback at 03. November 2005

  20. as days pass by » Quickies:

    […] A couple of good Joel Spolsky pieces on usability testing and how there really are ‘the best programmers’. That last point ties in, sort of, with another excellent Paul Graham essay on What Business Can Learn from Open Source. That essay contains many fabulously quotable bits, including numerous bits about the spectre of “professionalism“, a code word for “it’s more important that you wear a suit and spout the company line than that you actually do good work“. There’s lots more on this over at lesscode.org including an excellent essay, Motherhood and Apple Pie. […]

    pingback at 18. November 2005

  21. nedrichards :: Nick Richards » links for 2006-01-27:

    […] Motherhood and Apple Pie How the web is designed (tags: architecture article design internet philosophy webdesign simplicity) […]

    pingback at 27. January 2006

  22. Patio Pundit » Taking a stand:

    […] What is the distinction of Taking a Stand? What do I stand for? What does that mean? How is standing for distinct from good things that I like? It is a cliche to say that you stand for motherhood and apple pie — everyone does. Or do they? Is it a cliche to stand for Truth, Justice and the American Way? Or is part of Superman’s popularity stem from his stand for those things? […]

    pingback at 17. April 2006

  23. leroux.blog » Blog Archive » This Will Work Because It Will Be Good If It Did:

    […] I came across some really good articles recently that all loosly follow the same theme: http://www.adambosworth.net/archives/000031.html http://www.shirky.com/writings/semantic_syllogism.html http://lesscode.org/2005/07/21/motherhood-and-apple-pie/ […]

    pingback at 17. October 2006

  24. Un peu de lecture 02 at Aurélien Pelletier’s Weblog:

    […] Motherhood and Apple Pie ou the design principles that underlie the web. […]

    pingback at 17. December 2006