lesscode.org

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)

Comment RSS - Both comments and pings are currently closed.