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):
- Simplicity
- Modular Design
- Tolerance
- Decentralization
- Test of Independent Invention
- 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)