Showing posts with label systems. Show all posts
Showing posts with label systems. Show all posts

Tuesday, February 27, 2024

Root Cause Analysis

Time for the post mortem, as you know, some take it seriously
The need to revisit, the urge to explain what happened previously
For an ounce of prevention is said to be worth a pound of cure
Let's get to the bottom of things and figure out the root cause

Oftentimes it's a simple mistake, a moment of inattention
Or sometimes it's really just idle exploration
One minute you wonder, what does this button do?
Then the thing happens that you can't recant
Oops, you realize you just shut down the power plant

Human fallibility tends to be the root cause

Ah right, power. It's quite fitting in this era of modernity
That one can't sing too highly of the virtues of Electricity
So essential, we almost always overlook this august substance
We only rue its wonder when confronted by its absence
And now we've lost power and everything must stop
Oops, lights out. In Ghana we call it dumsor

Power failures are prime candidates for the root cause

The next affliction, sadly, is all too common
Like ants, human beings just like to burrow
When in a mad rush to lay down some pipes, it's nigh inevitable
So busy that we never checked to see what could be an obstacle
Dig: bureaucracy got in the way, they were moving too slow
Oops, the contractor cut the critical cable with his backhoe

All too often, cable cuts tend to be the root cause

Things fall apart, they say,
   equipment sputters, machines fail
They blow hot and cold, or crack when used,
   there's wear and tear
Material scientists make a roaring trade
   as do structural engineers
That, sadly, alchemists never overcame nature's challenge
   is the lesson learned
Oops, the widget broke,
   a reminder that no condition is permanent

In this industrial age, hardware failures are a likely root cause

Sometimes you're just too popular,
   so crowded no one can get in or breathe
Congestion is the operative word,
   in matters of scale, a crowd changes things
Your service is the flavor of the month,
   and now you've become essential
Oops, you're completely unprepared for when you go viral

Woe is me, lack of capacity is frequently the root cause

And then we come to the bad actors,
   forever on the attack
Always probing for an opening,
   for vulnerabilities in your stack
And that's even before we consider
   the gremlins and parasites
Iconoclastic beasts with distinctive manners
   and singular appetites
Every complex ecosystem in history
   has had to deal with grifters
Oops, your hospital is held to ransom
   by a band of sneaky hackers

Always protect yourself, a lapse in security is invariably the root cause

There's more in this vein,
   mankind has never built a system without error
From the Tower of Babel to that fancy car,
   or even that blasted word processor
The raw materials of life,
   whether it's the design or the initial conception
Imposing one's will,
   it might be a flaw in the ultimate implementation

You probably have your own experience and area of expertise
Your own rules of thumb about these puzzling mysteries
Let me tell you something
   from my profession of software engineer
If you only knew,
   to defend a system in depth is an exercise in fear
How close we come to catastrophe,
   partial or complete, every day
Trust me, you really don't want to see how the sausage is made

Now one could argue about the order
   of this short list of failure modes
It is only in retrospect that one is truly able to diagnose
The human burden is to keep moving
   in the face of systemic error
To mitigate the worst,
   to build the fail-safes and systematic procedures

Spare a thought for the moron in a hurry,
   for one day it could be you
That, through omission or commision,
   will be blamed for the miscue
We haven't scratched the surface
   of how much the human factor has an impact
Fall back to folk wisdom,
   suffice to say that curiosity killed the cat

And what of the wider world,
   say failed love affairs, or even wars?
It's only human to search for simple answers
   and the root cause
Our prophets and philosophers have long emphasized
   moral suasion and the golden rule
You could do hardly do worse than social living
   and the mosquito principle

Focus on best practices, usability, and layers of protection
Try to put a process in place and make it official!
Make sure that it takes many, many big red buttons
   to launch that nuclear missile
If there's any moral to this tall tale of root cause analysis
Take heed, and wherever possible, make use of the checklists


wide load coming through


After
  • How Complex Systems Fail (Being a Short Treatise on the Nature of Failure; How Failure is Evaluated; How Failure is Attributed to Proximate Cause; and the Resulting New Understanding of Patient Safety) by Richard I. Cook
  • a quip about network outages from Sean Donelan

Root Cause, a playlist


A soundtrack for this note (spotify version)
See also: The Dining Philosophers Problem, Resilience and Adaptability, and Version Hell Revisited

This belated entry on failure modes is part of the Toli Technology Series

File under: , , , , , , , , , , , , , , , , , , ,

Writing log: April 3, 2022

Tuesday, February 02, 2010

Black Sheep

Every feel unwanted? Ever feel like a pariah? What if your country starts disappearing from the global zeitgeist? When, I wonder, did Ghana start to fade from view? All right, let's get concrete here. Try this on your iPod Touch or iPhone (I was given a first generation iPod touch - now running iPhone OS 3.1.2 - a while back as a kind of consolation prize when my job seemed in doubt - but I shouldn't digress about the pathologies of corporate America). Anyway, where was I? Yes, take your i-something, open the Contacts App, create a new contact and add a new address. Alternatively just try to edit an existing address. Now try to change the country field to Ghana. Note, if you will, the result: Ghana is not in the list of countries. Search under "Africa (Western)" and you'll see nary a trace of Ghana. Heck, look through the entire list of countries and realize that we didn't make the cut. Ghana is not a country in the eyes of Apple.

ipod touch country list bug: Ghana must go

I came across this issue over Christmas when I was home and trying to enter new addresses in this, my conflicted glorified organizer thingimijig. It's just a bug of course, and presumably if I complain loudly enough or write up a bug report against Apple, it will get fixed. Whoever wrote the Contacts app is certainly not trying to whitewash Ghana from history. They just don't have many Ghanaians using iPhones, nor indeed testing the feature hence the omission slipped through the cracks, embarrassing as it may be. Moreover I've been on the other side of the fence, producing software that at times has been seized upon for subtle local insensitivity. I've even written in the past about the cultural difficulties that any piece of technology can elicit so I won't be calling for boycotts or apologia.

But wait, there's more. It seems that Ghana has been disappearing left, right and center from dropdowns and country selection boxes all over the web. I keep coming across this kind of ethnic cleansing in my browsing. Who decided that Ghana must go? It is one thing to be a literal exiled soul, a man of many countries but no home, but it's adding insult to injury to be cast into virtual exile. What gives? Why are form widgets all of a sudden slimming down and discarding Ghana? Why are even these fleeting elements of identity, that pleasing sight of Ghana nestled in between Germany and Gibraltar, being denied me and my countrymen. For example, in the past week I've been trying to buy gift subscriptions to some magazines for my uncles (Economist, Newsweek, New Yorker) and noticed that the online payment processors that these websites use simply don't feature Ghana in the list... go take a look: Gabon, Gambia, Georgia, Germany, Gibraltar. Where did Ghana go?

new yorker country list bug

newsweek country list bug

economist country list bug

I opened an investigation into this onset of web deportations but, first, let me tell a story...

My routine, ever since 1998, has been to spend my Christmas vacation in Ghana. As a fairly dutiful engineer son this means that 24 hours or so of my vacation is spent on tech support. I either bring new computers or coax the parental unit's setup into shape. They've tended to use Windows as their operating system so, as a matter of course, I would install or renew the subscription to Norton anti-virus or some software firewall or other, paying penance to the insecurity of the Microsoft ecosystem. Since 2005 however, I have been unable to renew the subscription with Symantec from Ghana. It's the usual thing, any credit card transaction from a Ghanaian or Nigerian IP address would fail silently with only a cryptic error message. I had a US billing address and yet my transaction would keep getting denied.

After repeated instances of this, I eventually worked out that the payment processor that Symantec uses had declared Ghana a nation non grata. Thus for the past 5 years, I would renew the subscription when I returned to the United States, or by using the corporate VPN (back when I was actually foolish enough to take a work computer with me on vacation) in effect pretending to be in the USA. Sidenote: the other alternative that most Ghanaians take is to simply install bootleg software or some open source or more wallet-friendly package (virtually no one actually pays Microsoft or other vendors for their wares).

Containers: cybercafe

Ghanaians have great difficulty using credit cards, PayPal, Google Checkout and the like. If we take ecommerce as one component of modern global citizenship then we are illegal aliens of sorts, and our participation is marginal at best. While remittances are a major part of our economy, we continue to pay a heavy price in all our financial transactions. Banks, wire transfer and check cashing joints salivate at the profits they make on our backs and yet the kind of routine monetary transactions that any idiot with a credit card can do in the West is a pipe dream.

The major reason of course is that a large amount of 419 scams, advance-fee schemes and outright frauds seem to emanate from our virtual lands. Payment processors tend to filter with a broad brush and their geolocation heuristics often tar almost all IP ranges from Ghana. The same story goes with spam filtering and some ISPs are known to ban entire countries arbitrarily as mitigation measure (I've seen this applied to countries like Russia, China, Korea). I have lots of Nigerian friends and their emails are often consigned to the spam folder even in GMail whose spam filtering capabilities seem to be the most discriminating. I can recall a member of the security services in Ghana quipping that two thirds of the 419 scams in the world could be stopped if police could simply round up everybody at Busy Internet and other internet cafes in Accra at the right hour. Thankfully that broad brush hasn't been applied - think of the rule of law, false positives, and Minority Report a priori censorship. Still, the actions of an unruly minority are making life difficult for us all.

Busy Internet

What is most galling now is that even our Nigerian brethren in e-criminality are on the list of countries in the above 4 cases. We have the workings of a different bug. With tongue firmly in cheek, I would say that Ghana is uniquely blacklisted. If you live in America, you expect that you won't see North Korea, Iran, Cuba or the like in your commercial browsing since sanctions and embargos pertain. Why would Ghana be in such august company?

One hypothesis, for the websites at least, is that the bug is at the level of the payment processor: Entrust, or Visa, MasterCard etc. Or perhaps our unreliable postal system is at fault. Another alternative is simply that there is a canned type of widget that is being used around the web. I know how these things work: most programmers cut and paste code when they are developing their sites, I know I do that often enough. A cursory inspection shows that the Condé Nast sites are using the jQuery toolkit, a potential source of the bug, but it could be any of the other popular toolkits, Dojo, YUI, Scriptaculous etc. These are pre-canned form widgets and one can envision that a popular tutorial site or user interface toolkit has the bug and has been widely copied.

But, what about the bug in Apple's iPhone Contacts app, one wonders? That seems like an outlier unless it too was written as a web app using much the same widgets. Does anyone have any theories on the matter?

I won't get into how Orbitz and Expedia have now followed the lead of Travelocity in removing Accra from the list of places you can book travel to - this, even though major airlines like Delta, KLM and British Airways fly there. I know that my small country doesn't warrant much attention, I know my place. But this is different, all I want to do is enter some addresses in my organizer or send my uncles some magazines. Magazines that are ostensibly a dying business won't even let me send my hard earned money to them. Someone help me, I feel like a black sheep.

File under: , , , , , , , , , , , , , , ,

Sunday, June 18, 2006

The Low End Theory of Networks

Ethan Zuckerman has been pondering generativity and aggregation, prompted by Jonathan Zittrain's paper, The Generative Internet and its implications. Many of these themes have been stewing in my head for quite some time so I thought I'd finally join in the conversation with some of my armchair punditry. As seems to be my custom, a one paragraph comment somehow turned into this note. Sadly I don't quite have a toli code to contribute to the fun, and I've already narrated a couple of gospels recently. Thus I'll switch tack and change the frame. This time I give you a theory: the Low End Theory.

Control versus Participation in Networks


It's interesting that the lawyers, from Lawrence Lessig on, are weighing in on these network things and it's about time... Generativity huh? Zittrain argues a legal case built on abundant economic evidence (and one hopes the linguists would also weigh in). It's a nice restatement of the End-to-End principle in terms palatable to lobbyists. And the argument is much like Lawrence Solum and Minn Chung's paper The Layers Principle: Internet Architecture and the Law from a few years ago.

Reed, Saltzer and Clark described the End-to-End principle quite simply in terms of systems design. The heart of the matter is this oft-overlooked sentence
Functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.
They knew when they were writing that this notion had wider applicability than the telecommunication networks that were their initial focus hence they labeled their work "end-to-end arguments in system design". The costs that are borne by the "system" are a generativity tax if we use Zittrain's terminology.

In economic terms, if you read the system as a market, restating this principle turns it into a matter of preserving options value. Black and Scholes have a lot to say on this front.

I see this same notion everywhere in the software engineering that I practice. The most successful system in distributed computing has been the web which, by design (pdf) and to a fault, falls back on minimalist protocols and data formats to handle coordination costs and the human factor.

But there are also tensions at work in the design of any system, and hidden assumptions or vested interests at work.

There will always be a difference between the value of a system to its users and its value to its operators and this is perfectly expressed in networks. At issue in this discussion is who gets to see their utility maximized. As Martin Geddes puts it
If there’s one lesson of the Stupid Network, it’s that there’s a massive increase in consumer surplus. The value to users diverges from that to owners. You can’t measure user value by looking at industry revenue.
A priori you have no idea what options are possible at the edge of your market. This means that the design of the core of your system is a political decision. Like an options trader you are gambling on outcomes in the marketplace and attempting to manage risk. Your design decision is anything but neutral despite what the so-called "network neutrality" proponents say (even if I do agree with their endpoint market outcome).

We know that price discrimination is an optimal pricing strategy from many standpoints and, in market utility terms, it makes sense to optimize system design to enable some modicum of price discrimination. The evidence throughout history, however, is that participants in a market hate price discrimination and favour uniform or predictable pricing. For example, flat rate pricing made the fortunes of AOL, and block pricing is remaking the cell-phone industry. By analogy, Paris Metro pricing is not widespread in transportation systems and on the internet because of these explicit user preferences.

Part of the challenges the US airline companies currently face is that we aren't sympathetic to them. One major reason for our disdain is the pricing games that are played with plane tickets. We value fairness even though we are creatures of a rough jungle and there's likely an anthropological basis for our sense of indignation at price discrimination. Perhaps our past ancestors were optimistic planners by nature. However the presence of price discrimination in a market, coupled with flexibility of pricing, and the liquidity of relative transparency allows for the existence of middlemen and the possibility of arbitrage and disintermediation. On the whole, these are good market outcomes but, like many "options", they can't be characterized up front.

Where there are networks, we will find power laws that apply. Similarly where there are markets, we will have sharp elbows and monopolistic temptations as we scramble for the loot. There are echoes of F. Scott-Fitzgerald's notion that "the rich are very different from you and me". These factors are found in every part of the technology industry and, when combined, they play out in the Great Game of consolidation and lobbying. The big network operators will happily oblige in their strategies since lots of advantages accrue to the early movers and great powers, and they can leverage consumer inertia. In the internet we have many intermediaries at the network level; firewalls, middleboxes and the domain name system are potential, and actual, Great Powers (see the Verisign Tax ® we all pay and the "offers you can't refuse" that content delivery networks like Akamai make).

Moving up a level, intermediaries are acknowledged up front in the web architecture as design constraints. I have cast the web's embrace of visibility to intermediaries as Caesar's Tax Collector Principle and I think it is fitting, taxes are good, on the whole, and especially estate taxes - they keep the trains running and the streets clean at least in my neck of the woods.

The Rumsfeld Taxonomy of Networks


If we take Donald Rumsfeld's taxonomy of knowledge as the starting point for our analysis of networks, we find the following.

Unknown Unknowns


Legislators and vested interests tend to worry about "unknown unknowns" and, like Rumsfeld, will focus on threat models and such. This is a matter of governance and regulation; among the core competencies of most governments are the management of information and regulation. Excessive focus on these leads almost inevitably to data mining, intimidation, the co-option of a complaisant although ostensibly independent press, spying by the NSA , movie-plot security and the like, your basic Global Wars on Everyone.

Unknown Knowns


The "unknown knowns" are our unconscious biases that frame of the discussion of networks. The metaphors that different sides use are instructive and perhaps even my casting the conversation in terms of "sides" betrays my viewing this arena as a game of sorts (hopefully not Mortal Kombat or something). Others may view the networks scene as a Clash of Civilizations which would lead to apocalyptic wars and the End of History if one follows Manifest Destiny.

Known Knowns


The "known knowns" in networks have been visibly demonstrated in the economic verve and activity that is taking place on the internet. Even if the four horsemen of the internet ™ were oversold, we can still point to the ongoing transformation wrought by the Four Horsemen of the Web. As an engineer, I tend to think in terms of protocol, hence my nomination of The HUHXtable Quartet (HTTP, URI, HTML, XML) towards that designation. Your mileage may vary and various prognosticators seem to be weighing in with speculations about the identity of these horsemen. With corporations being legal humans, they have assembled an intriguing cast of characters to liven up the debate.

These same historical forces were at work in the history of communication and transportation networks (pdf) and, although we celebrate the Wright Brothers and Henry Ford, who is really celebrating Samuel Homfray, Richard Trevithick, and the various others who played a role in the history of railroads or even, more recently, the extraordinary innovation brought about by the lowly shipping container?

Known Unknowns


The sweet spots in our analysis are the "known unknowns". These are the things that make venture capitalists salivate, and monopolists turn to paranoia and worse. It's that seductive notion of the startup in the garage that can change the world, of the eBay or Craigslist economy, of the manufactured serendipity and furious and creative energy that has been on display in the past decade or so on the web. This is where that Long Tail notion comes into play, to shamelessly mine another meme. There is the sense that all you need is an idea, and good connections. The fully leveraged network can be a great leveler and promoter of the innovative forces in a system.

Sidenote: This bit about manufacturing serendipity on the road to riches meshes well with the American Dream ™ and it is worth commenting on a little. Paul Graham, in his hermetically-sealed world, apparently believes that a start-up culture is a particularism of the United States (or condensation as he puts it). What a peculiar notion. While he's sleeping soundly at night, after a lullaby of unshakable Manifest Destiny, I'm sure that some Teutonic engineering will suddenly emerge (and he misreads the German economy so completely that he's a front runner for the huhudious awards 2006), or would it be an easterly wind that blows in from Korea or thereabouts that will give him fits early in the morning. I would have thought that the lesson was that the unknowns by definition are unknowable and, if you go ahead, following the Rumsfeld example, and discount even the knowns, you end up traveling in a lightly-armored Humvee on the road from Baghdad airport with a convoy of outsourced mercenaries. Good luck on that front.

The Low End Theory of Networks


But back to my topic... I'll quote Martin Geddes again since he is, as ever, eminently quotable
the end-to-end principle is really an appeal to preserve option value in a world of rapid technology change and innovation. By resisting this force, you’re either betting you can suppress rival distribution channels for competing innovation, or you can yourself be a lead innovator.
Thus Zittrain's pitch about generativity versus responsibility boils down to a tension between architectures of control and architectures of participation (using a much broader sense of participation than the current buzzword).

Stated another way, and since I traffic in coinages, indulge me if you will with Koranteng's first postulate of networks:
The End-to-End Principle in networks is another incarnation of the Low End Theory.
Recall if you will the core tenets of the Low End Theory which follows the Rule of Four as any good code should. Such is the mantra that schoolgirls the world over are reciting as they study Technology Adoption and System Design 101, and it is worth dwelling on:
  • Ruthlessly leverage disruptions in the system
  • Lower coordination costs through layer stripping
  • Favour participation over control
  • Temper the human factor to encourage adoption
As should be clear, each tenet of the Low End Theory encourages externalities to accrue in the system in support of preserving options value. Combined, they harness the collective energies of participants and harness innovation. We see these building blocks at work in hardware, in distributed computing and in the various Great Games that are taking place in the technology world. In this respect, I've suggested previously that REST, the web style, was the Low End Theory of Distributed Computing and have also written about The Low End Theory in Hardware. I don't see any reason why networks shouldn't be able to join in the fun, hence my current synthesis.

I like that Ethan is shrewdly focusing on the question of aggregation - that is also a restatement of the examples of eBay and Amazon. A good marketplace will surely allow for middlemen and aggregators, that's the bit about favouring participation. Aggregation however is only one of the styles that are likely to prevail in the market. Astute participants can focus on different areas and make hay.

As an example, it pays to identify the disruptions that underlie the evolution of the system, if you can hitch a ride at the right point, you can build mansions in Redmond. As to the second plank of our game theory, layer stripping restates the end-to-end notion of overlay systems, intelligence at the ends, and the daily reality of leaky abstractions. Similarly the human factor is a double-edged sword. On the one hand, there is the incoherence of the Tower of Babel which is the bit about coordination costs. On the other hand there are network effects to be gained in communication and group forming that argue for emphasizing community features in the system. From hunter-gatherers on, anything that enabled collaboration has given selective advantages in our evolutionary systems. We want to encourage the sharing of knowledge and information but encounter considerable costs in doing so. The ongoing dilemma we face is about how to build systems recognize the people along with the processes.

Operational efficiency is something that companies like Wal-Mart and Dell are good at, and operational efficiency at the margins is all the rage in the staid banking sector. As Willie Sutton quipped about robbing banks, it's "Cause that’s where the money is". Thus there are other ways to prevail in this marketplace. Rather than optimizing your processes around innovation you can optimize around operations, billing, search, storage, creating markets, or lubricating whatever friction there is in the system. To take an obvious example, the economics of peering is an interesting problem to tackle. Briefly stated it's Animal Farm all over again: some peers are more equal than others. Or call it real estate: location, location, location.

Similarly we are only beginning to realize the social implications of mobility in networks, of intermittent connectivity, of periodic synchronization and of the fluidity of our communal relations. Mobility is thus another of the major disruptions at work in the network marketplace and one that many users have voted on with cold cash all over the world. I'll note anecdotally that many colleagues of mine who were working on desktop collaboration software just years ago are now firmly ensconced at Nokia.

Where there is the realm of the social, there is the realm of conversation and its corollary, the market. To raise the tenor of this conversation, I'll repeat the insight of those 20th century philosophers, the Pet Shop Boys, and their master treatise:
There's lots of opportunities

You've got the brawn
I've got the brains
Let's make lot of money
Thus there is room in the network game for the innovation of Juniper and Skype and all the companies weighing in on the disruption of the internet protocols, and the operational effectiveness of say equipment manufacturers like Nokia and Samsung, and the more astute network operators. Everyone has their own exemplars on this last front: phone, cable, cell, fiber, copper, fixed wireless, wi-fi, ethernet... The TCP/IP suite that is the core of the internet has succeeded and scaled because the abstractions used embraced transparency and existing systems. The incredible ascendancy of ethernet over three decades (and of late wi-fi) is a testament to the value of simplicity and uniformity in network system design, and the concomitant scale and leverage that the low end mass market provides. Like the personal computer, these technologies are canonical disruptions and those who embrace their Fung Wah Bus aesthetic are inexorably moving up-market.

Some have suggested that good starting points for determining strategy are tomes like The Gorilla Game or The Innovator's Dilemma, I believe the jury is still out and the MBA types are best positioned to expound on their merit. I would point to Jim Gray's Distributed Computing Economics as my favourite starting point in determining to the best strategy. In any case, the game is on. In the interim, we are simply picking and choosing which of the hard problems we want to address. Still game theory remains theory; in real life games we have that nagging human factor.

Engineers are currently hobbled in our advocacy of the internet because we don't have good instruments for determining metrics for things like resilience and adaptability that could inform the decisions of policy makers, lawyers, economists, and those who really matter: Mr. and Mrs. Big Money. Politicians everywhere like statistics and large numbers in what passes for their policy debates, especially in this current silly season of nostalgia. We do have large numbers in the internet, the users, but unfortunately we only have waffly options pricing to throw around as statistics. I would hazard that muttering "options value pricing for networks" doesn't quite cut it when compared to the red meat of the corn and sugar lobbies or the pork of the military industrial complex.

Sonny Rollins Way Out West


One needs to dangle some glitter when we talk to congressmen, or votes or something. Thus I'm an alchemist searching for Black Gold. They told me it was a goldfield; it turns out that it's an abandoned coal mine in Pennsylvania, a dud concession. Still I've heard there are good things Out West on the frontier, that area called the internet, that web style I need to adopt. Thus the Low End Theory is a work in progress and one could easily get taken to the cleaners by the loaded dice of the other players.

Deadwood


Everybody wants their cut and, if you can tilt the playing field at whatever level you reside at in the network ecosystem, it makes sense to do so, especially if you are judged every quarter by the baying hounds of Wall Street. If you take the market view, the lobbying capabilities of large corporations, a long history of regulation in this sector, and governments' existential need to pass laws or exercise control or compliance of some sort (whether in the name of security, expedience or getting things done) are going to weigh heavily.

We engineers have been lucky to have built enough of the internet and web infrastructure before the lawyers, lobbyists and governments realized what was there. The underlying architecture has proven sound enough to have scaled several orders of magnitude and looks set for several more as the next few billions of humanity come on board. The fact that the internet (after three decades) and the web (in its second decade) are now treated as infrastructure says it all, and this is a Good Thing ®.

The language is also important, and I continue to wince at George Gilder's revolutionary talk although he is now (slightly) chastened. My reading is that we need to emphasize a sedate, gray-suited discourse to keep the bankers and traders happy and the loud "content" industry at bay. Infrastructure should be boring despite the breathless prose we see in the business rags. Technology was made prematurely sexy in the dot com era; the implications of technology are what are important, not the technology itself. The markets for cement and most other commodities don't raise eyebrows and nor should networks. The logical lesson of the end-to-end principle is that communication networks are about connectivity, everything else is gravy.

I'll suggest then that normalcy is what engineers should aim for in this discussion. The Generative Internet is a good contribution to the debate as it is rooted in an understanding of the engineering insight of the end-to-end principle and the way platforms are developed and evolve. The dissection of the personal computer industry is instructive too as an argument by analogy in the technology world. The exploitation of Moore's Law and the black gold of silicon, the sweet spot of the mass-market where Intel and now AMD have been able to make hay, the platform effects that Microsoft has been able to leverage in the mass market etc., all these continue to drive that Great Game.

The weakest part of Zittrain's paper is where he declares that the end-to-end argument needs to be superseded and that "end-to-end does not fully capture the overall project of maintaining generativity". The primary reason for this postulate is the rhetorical strawman he constructs of end-to-end neutrality. Those advocating what they call "network neutrality" are simply being cute. They are implying, for quite pragmatic and rhetorical reasons (read effectiveness of lobbying), that there are no costs to neutrality; that neutrality is value neutral. It's a nice trick as far as framing a debate goes, but it is a trick nevertheless and it should be discounted accordingly.

Odlyzko has noted that spending on communication services (and especially the connectivity component) is huge, dwarfing many other segments of the economy (and before Rumsfeld's folly it was even trending towards the amount spent on national defense in the United States). Those vested interests and a $300 billion dollar sector will buy lots of slick rhetoric and astute framing. Zittrain carries on to suggest that the inevitable endpoint of the end-to-end argument is a network teeming with, on the one hand, viruses and spam and, on the other, silos and walled gardens. Having raised the spectre of these undoubted bogeymen that obviously need regulation, we then require new paradigms and frameworks.

This is either misguided or flawed, depending on where you stand. The end-to-end argument, as restated in the low-end theory, stands up well to these charges. It is an argument about lowering coordination costs. Nowhere is it acknowledged in the original paper that there are no costs to be borne, or that there is any such thing as end-to-end neutrality. To take a concrete example of engineering expediency at work consider the implementation of congestion control in the TCP/IP suite of protocols. This is characterized by some purists as a layering hack. The upshot of current practice is that we have repeated injunctions for other network applications to be "TCP friendly" in order to preserve the commons and the kind of congestion collapse that was observed as the internet began to see increased usage in the 1980s. We can and do embed functions inside of the network systems that we develop and sometimes we even cross layers if necessary, this is simply pragmatism at work.

Thus the very premise of the end-to-end argument is that this is a matter of tradeoffs and decisions about who bears costs. Engineering decisions are never neutral, the low end theory is political and is competing with different styles in the marketplace. Its emphasis on favouring participation over control simply aims to tilt the marketplace in a direction that encourages externalities to accrue to the end rather than the core. Similarly layer stripping as a design principle in the core is about reducing complexity. In other words, it suggests a strategy for those who run the network about how they can reduce their operating costs and accrue their value in the marketplace.

Lastly I'll note that everybody has to deal with gremlins and parasites and, as Cory Doctorow has noted, "all complex ecosystems have parasites"; they are transaction costs in every marketplace. Things always fall off the back of a lorry, the banking sector tolerates a certain level of fraud etc. Further, these transactions costs are acknowledged upfront in the end-to-end argument. Also, the empirical evidence throughout human history is that silos and walled gardens (from the Berlin Wall to CompuServe) are unsustainable in the long run and that it is shrewd to bet on participation over control (and I hope Burma and North Korea don't give the lie to my optimistic outlook). Still this prognostication is only a small part of Zittrain's remit and perhaps detracts from his wider argument.

I'll acknowledge here that linguistically the generative internet is a good coinage, and perhaps it even works better than End-to-End when pitched to the average congressman. This suggests to me that the enduring value of Zittrain's analysis is likely to be in the branding of the debate. Still as the lawyers and economists gear up and build up their legal frameworks and paraphernalia of economic models to throw at us about the design of networks, we engineers should confront them with prosaic notions of building communities and enabling conversations and marketplaces. I hope the Low End Theory can similarly enrich our vocabulary in this light.

We do have secret weapons in this debate... My grandmother is a surprisingly fierce and effective lobbyist when she puts her mind to it, on topics that sometimes mystify me. Her desire to interact with her progeny and to get on the web to converse with us should not be underestimated. The evidence is clear that she'll even tolerate any amount of spam and the ever-present gremlins and parasites that prevail - in moderation of course. More generally there is the desire to reconnect with old friends (and perhaps old flames), the socialization impulse that lurks in all of us. This is why I try at every opportunity to advocate pragmatism and that we strive to build Sexy Mom Factor Software. Where soccer moms are the demographic the politicians go after, in networks we need to encourage the Grandma Lobby like those cunning financial folks who went after Scottish Widows.

To conclude, participation is winning out over control for the moment, but it is the eternal struggle and I am hoping that the current ascendancy on the internet is not a temporary respite. As with democracy in the Great Game of Politics, eternal vigilance must be our watchword. And to paraphrase he of blood, sweat and tears
End-to-End systems, or Stupid Networks if you like, are the worst form of networks except for all those others that have been tried.
The story is the same as it ever was in the Great Game of Networks and I argue here that the Low End Theory is King, or President, if like me you are a republican (with the lowercase r).

Postscript


I've decided that I like the freedom I've found living within the constraints of a series hence I'll cast this note as part 1 of The Great Game of Networks Series which itself is an offshoot of The Great Game of Technology Series which I hereby retroactively announce. The latter series started last year with some musings on The Great Game of Chips.

Soundtrack


The Low End Theory soundtrack once again comes courtesy of A Tribe Called Quest's 1991 album.

The Low End Theory by A Tribe Called Quest


This time we'll hum along to Jazz (We've Got) and nod our head's to Ron Carter's bass:
Stern firm and young with a laid-back tongue
The aim is to succeed and achieve at the age of 21...

[The internet hit the prime time around the age of 21 with the arrival of the web]

So push it, along, trails, we blaze
Don't deserve the gong, don't deserve the praise...

[innovation and manufactured serendipity continues]

A brand new twist with the homie-alistic
So low-key that ya probably missed it...

[low end should be low key infrastructure]

Competition, dem Phifer come sideway
But competition, dem must come straightway

[violators need not apply, we can see you coming]

I take off my hat to other crews that intend to rock
But the Low End Theory's here, it's time to wreck shop

We've got the Jazz (x4)


So peace to that crew, and peace to this crew
Bring on the tour, we'll see you at a theatre nearest you


Next: Disruptions in Networks. Ergo, what's there to leverage?

Print version

File under: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Friday, April 07, 2006

On Coordination Costs and Human Factors

I reproduce here what I thought would be a short email that I fired off this afternoon discussing the web style. I hope it might gain from wider scrutiny...

On Coordination Costs


In an atypically verbose exposition, Matchmaker Roy Fielding propounded thusly:
Don't get carried away. You won't find a constraint about "nouns" anywhere in my dissertation. It talks about resources, as in resources, because that is what we want from a distributed hypermedia system (the ability to reuse those information sources through the provision of links). Services that are merely end-points are allowed within that model, but they aren't very interesting because they only amount to one resource. The really interesting services provide many resources.

Note that this is just another way of restating Reed's law in relation to Metcalfe's law.
Similarly, Layer Stripper Bill de hÓra recently flirted in the same manner:
Some people when faced when a distributed programming problem, think 'I know, I'll expose a new service interface.'

Now they have n-squared problems.
View Sourcerer Joe Gregorio almost in passing shined a light on some cobwebs (on caching and authentication on the web):
"In the process of implementing httplib2 I also discovered some rough spots in HTTP implementations."
Putting these together and handwaving as usual...

It strikes me that the first two statements are all about changing the frame and making economic arguments for REST (Representational State Transfer), namely constraining system design to resources, identifiers and uniform interfaces in order to lower coordination costs... ergo the web style as an enabler of Reed's Law.

I hadn't seen such explicit harkening to Metcalfe and Reed in the past even though there has always been this notion of REST as incorporating end-to-end principles. I too have argued in this vein about a complexity and integration argument for REST.

In a similar thread Benjamin Carlyle put it thusly
Uniformity is key. Simplicity at the network level is key. Managing state transparently as resources is important for its own reasons
Intuitively, the argument about applying architectural constraints to get payoffs in terms of leverage has a lot of appeal to engineers. It seems however that we need some economists to weigh in here with some options pricing theory or other to give more heft to these arguments. Often, decisions about software systems are not made by engineers but rather by financiers and it helps to speak their language.

Instead of Reed's notion of group forming, it seems the argument by analogy for REST is about application integration and the barriers that obtain in that sphere.

Now I like the large numbers that we can throw out in these reformulations. The thing is that Andrew Odlyzko says (pdf) that both Metcalfe and Reed's law are bunk despite their evident appeal and ability to dazzle venture capitalists.

In that paper he sets out to get quantitative measurements and hard data and puts the value of communication networks at nlog(n) which is nothing to sneeze at, better than Sarnoff's linearity but far less than Metcalfe and Reed's estimates. Now Odlyzko was measuring the utility of the internet which encompasses more than the web and you can argue, following Sam Ruby, that the email and peer-to-peer styles, whether expressed as, Bittorrent, Skype or usenet, are the true winners in his numbers... Also you could argue with his methodology and I have my own quibbles, but it's a brave man who takes on Odlyzko... Thus I'll take his numbers in my handwaving, acknowledging after all that the web was the key enabler and popularizer of the internet.

The Human Factor


This gets me to the third quote from Joe Gregorio, namely the perennial rough spots and implementation quirks that are our daily bread as engineers trying to design and produce systems for the web.

We see daily abuse of HTTP and there are annoying glitches with the libraries and implementations that exist and what is deployed in the real world. Perhaps this is because REST is the web style rather than the programming model and consequently enforces very few prescriptions. We are only now seeing good frameworks geared toward REST; historically, HTTP client and server libraries have been minimalist.

Now it seems to me that this is about the place where theory meets practice and we get into the realm of pragmatism and leverage. In the wild we see
  • the difficulties of interoperation
  • differing interpretations of specifications if indeed specs are read
  • backward compatibility constraints e.g. for leverage and adoption, HTTP 1.1 had to accomodate some of the pitfalls in HTTP 1.0
  • difficulties in authoring structured data
  • configuration and deployment issues (mime types, content negotiation etc.)
  • competition with other styles, the web style exists in a marketplace of architectures
  • vested interests and economic models e.g. limits imposed by shared hosting providers, asymetry of some broadband networks etc

With this in mind, I wonder if I can come up with a stab towards Koranteng's postulates on coordination costs
  1. There is a natural dampening factor in the utility of distributed computing

    We can use Odlyzko's numbers as the lower bound in practice of network effects and Reed's law as the theoretical limit (with Metcalfe being a great popularizer).

    I happen to be reading Graham Greene's The Human Factor and, looking through some of the issues that hinder adoption, many of them could be summarized as comprehension or human variability hence I'll characterize the issue as the human factor. All that is left is to augment with some Black-Scholes options thinking and financial derivatives to package to CEOs
  2. the human factor in technology adoption is sizable and its effect can be measured. Moreover I would argue that it should be recognized as an explicit architectural constraint in the design on software systems.
  3. In the realm of distributed computing, this human factor is bounded by Odlyzko's limit and Reed's law.
    Mathematicians can derive the correct coefficient for me... 1/nlog(n) ?
The rest as they say is advocacy and implementation details...

We are operating with imperfect specifications, imperfect frameworks and imperfect implementations. REST as laissez faire distributed computing doesn't acknowledge these costs as architectural constraints but rather seems to go about it by encouraging best practices and hoping that, by existence proof, people will come to it... One can look at the high level requirements that have been articulated
  • Simple protocols for authoring and data transfer
  • textual formats for protocol and some exchanged hypermedia
  • Sensitive to user-perceived latency
  • Mark Baker's talk about "principled sloppiness" (i.e. "must-ignore style extensibility")
We don't tend to enforce many of these things in the deployed protocols. I wonder what other best practices can lower coordination costs and whether they can be encoded in protocol to remove the human factor...

Anyway food for thought...

the human factor

The Gospel of REST


If anything this enables me to add Reed's insight to my nascent taxonomy (or is it theology?) of the web style which some may have come across... namely:

There's a tag: REST

There's a slogan: the web style

There's a Holy Book: Architectural Styles and the Design of Network-based Software Architectures

There's a Reverend: HTTP

There's a choir: the HUHXtable quartet (HTTP, URI, HTML, XML)

There are Four Horsemen: GET, POST, PUT, DELETE

There are prophets: (you know who you are)

There are pillars: Resource Modeling, Idempotency etc.

There are priests and tax collectors: the caching and other intermediaries. Ergo "Render unto Caesar that which is Caesar's" recast as the notion of "giving visibility to intermediaries".

There are angels and demons: a band of Apaches and various HTTP libraries which are alternately sources of delight and exasperation.

There's a Messiah: the browser (which comes with various pretenders: Firefoxes, Great Explorers, Viking Operas and Fruity Safaris).

There are red herrings: url opacity etc.

There are false gods: WS-*, crusty old architectures of appropriation etc.

There's the wilderness and prodigal children: WebDAV?

There's Mary Magdalene and the disciples: HTML and Forms.

There's immaculate conception: the virtuous XML.

There are worldly travellers: the three mobile kings JavaScript, Java Applet and ActiveX (some discredited) and a Flashy pretender.

There are scrappy offspring: Atom, RSS and Atompub.

There are gruesome Philistines: implementation details such as Structured Data, Character Encoding and Security.

There are elevator pitches, Cliff Notes and ballads: Sir Tim's lullaby of Web Architecture 101 is quite reasonable as a Song of Solomon

There's myrrh and frankincense: the web as conversation engine

And now there's the Promised Land ©: Reed's Law as the proverbial milk and honey

The parts I'm missing are the Apocrypha and Gnostic gospels (with Judas in the news this week)... but those should be forthcoming... As will the eventual accommodation by Rome as the official religion but then Bill de Hóra has noted that we are almost there.

[Update] Ernie Prabakar suggests that "Lo-Rest" works as apocrypha and that "SOAP is really gnostic - it focuses on the divinity of XML, to the denial of its incarnation in HTML." One wonders who Rome is in the technology world, perhaps Microsoft like he suggests... I'd note in passing that I've heard in corridors that the IBM Software Group Architecture Board is "looking at REST" anew. That's got to qualify as progress... Pretty soon I'll be able to publish an official gospel from my muddy trenches. Looking further down the line, there will likely be a split between the Catholic and Orthodox churches as the empire suffers from navel gazing and an East/West axis of discontent and eventually there'll be Martin Luther and the Reformation... I wonder whether I'll live see to see the Protestants of REST and if I'll recognize them.

A Data Digression


I noticed last year that Roy Fielding produced a white paper about JSR 170 (Java Content Repository) for his day job (pun intended) applying principled constraints to the modeling of content repositories.

I've been curious about the surprising inertia behind that specification having played with IBM implementations in the past few years. Perhaps however, the immaturity of implementations in that space is a tribute to some of these arguments about coordination costs applied to the marketplace of data (relational, object relational, XML, SQL, XPath, XQuery, ActiveRecord, ODMA, Spring, Hibernate, SDO etc).

I wonder if the Atom store dream is the way to go, namely rather than apply the constraint of an API and a language, Java, in a world in which we have a Tower of Babel of languages and persistence frameworks, it makes more sense to focus on wire protocol (as in Atom Publishing protocol) and wire format say Atom. In other words the greater payoff would be not in establishing a programming model (the JCR) but rather in moving to Atompub which is agnostic on the underlying programming model and lowers the coordination costs by stripping a layer of comprehension from the mix. All this of course is modulo the quirks of compound documents, media collections etc...

The web worked because it was an overlay system that acknowledged existing systems and encoded much of its benefits in protocol rather than API. At the current stage of development in the software industry, it appears that the combination of protocol and data formats rather than API is the more effective approach to lowering coordination costs and dampening the human factor.

File under: , , , , , , , , , , , , , , , , , , , ,

Sunday, March 19, 2006

The REST Elevator Pitch

The Pitch


I somewhat share Ryan Tomayko's concern for a shorter hand language for describing REST (Representational State Transfer), but I believe that the REST elevator pitch is pretty succinct already. It packs a lot of insight into the web architectural style of which dissertations have been written. The language used in technical debates is always important and rather than devolving into the fuzziness of "highs and lows", I'll suggest here that, as a matter of advocacy, one should stick to the elevator pitch.

To recap, the REST elevator pitch is:
  • Identification Of Resources
  • Manipulation Of Resources Through Representations
  • Self-Descriptive Messages
  • Hypermedia As The Engine Of Application State
In its most common application, the pitch will lead you to the HUHXtable Quartet (HTTP / URI / HTML / XML) if we handwave away the additional content types that the web style enables you to negotiate. It is quite clear that applications of all kinds have been built on these fundamentals for both human and machine interaction.

The thing is that each plank of the pitch brings its own benefits, benefits that perhaps can accrue independently. Still you get the most bang for the buck at the internet scale by the principled combination of all of them.

In my advocacy I tend to start with resource identification as the most important plank. The reason for this is that everybody can understand the value of identification. My grandmother understands the value of a bookmark to my photos. Heck we are even seeing the social benefits of ostensibly selfish bookmarking. The importance of resource identification cannot be understated and it leads us to the primacy of the URI.

The second plank, manipulation of resources through representations, is the bread and butter of HTTP, where we have an evolving set of standard formats of hypermedia exchanged using a small set of verbs.

Unpacking the HTTP proposition leads us to the four horsemen of the web: GET / POST / PUT / DELETE

Of course you can do very well if you pick up only 2 of those verbs, GET and POST. The good Reverend HTTP is a pretty tolerant fellow and won't begrudge those that don't believe in the rule of four, although in admittedly imperfect analogies, there's CRUD (Create / Retrieve / Update / Delete) in the database world and, as far as this layered internet goes there's TCP / IP / Datalink / Physical Layer (with say Ethernet or "Wi-Fi" 802.11b/a/g)

On the other hand, if you want to be a good citizen in the town of Deadwood and indeed if you want to survive in the wild west of the web, you shouldn't abuse HTTP. HTTP abuse leads to user confusion, headaches for systems designers and a tragedy of the commons. I consider HTTP a deliberately minimalist compromise, laissez-faire distributed computing if you will.

In social settings making your intentions known can help smooth interactions. We may start with small talk but we eventually manage to discern where others stand - well most of the time at least. We all operate with imperfect information but being straightforward is often a great policy. I'm sure there's some game theory or behavioural economics that can point to the value of transparency. Perhaps it is trite in light of Machiavelli and Sun-Tzu to believe that disclosure is the best policy but at least in markets transparency tends to be the font of aggregated wisdom. On the internet scale, this translates into the notion of giving visibility to intermediaries. Arguing again by analogy, the internet is an agreement, a network of networks. You can do whatever you want on your network but to interoperate with others, a small set of primitives, the TCP/IP standards in this case, have been agreed upon. I would suggest that the web style is similarly such an overlay system. REST is an architectural style which by principled design, is optimized to lower coordination costs.

Acknowledging the benefits of idempotency, of doing things safely, will lead one to making sure the use of GET is safe. Idempotency is not just about safety however; in clearly signaling your intentions, it is also about replayability. Thus idempotency is not just about the GET method. That is the wider argument for also using that oft-neglected duo, PUT and DELETE. Tunneling everything through POST (and the completely aberrant case GET) may be convenient but it adds unnecessary opacity and unpredictability about one's application. Unpredictability in the world leads to invasions and worse I might add. The use of those four core HTTP verbs helps intermediaries understand and participate more fully in the ecosystem.

The last two planks of the REST elevator pitch, self-descriptive messages, and especially that last one, hypermedia as the engine of application state, are attempts at addressing the issues of state, caching and evolving systems amongst other things.

Now of course in the preceding paragraphs, I've handwaved away entire dissertations that have been written about architectural styles and systems design, tomes written with language more precise and concepts more subtle than I've outlined. Good samples and running code are often also a determining factor in which style or application is adopted thus the view source imperative is also one of the reasons that web has caught on so quickly.

The Hard Problems


I've recently been thinking about defining the hardest problems I've encountered in software engineering, my cursory top 10 list:
  • State
  • Caching
  • Latency
  • Concurrency
  • Search
  • Metadata
  • Persistence
  • The Holy Grail Of Extensibility
  • Structured data
  • Character encoding
Now I'm not a database person so I handwaved away all of those data peoples' worries in one word: persistence. Of course I should probably add a few more issues and indeed you probably have your own notions. Indeed I settled just two days ago on those last two, structured data and character encoding, when I characterized them as being the gruesome twosome of computer science. Perhaps also there's the issue of discovery and bootstrapping of a system but that could be considered implementation details. There are those who mention security and reliability as other hard problems and they certainly are. Still I'll also handwave those away not as technological issues but as transaction costs; the economic benefits of ubiquity and leverage are key here. It seems that humans are quite prepared to tolerate gremlins and parasites in their systems (social, biological and technological) in moderation of course.

What is interesting is that almost all of these issues are important even if you aren't dealing with distributed computing. On the internet, which is all about distributed computing however, these are crucial problems. Now addressing these problems is a pretty tall order I must admit, but it seems to me that the web style has concrete answers to almost all of these constraints. Furthermore REST also offers a couple of those very valuable system characteristics: resilience and adaptability, almost as externalities.

Search for example seems to be addressed by valuing the importance of resource identification, the URI, that leads to PageRank and other algorithms. If you start with a viewpoint that URIs are cheap, and if you model your resources appropriately, you can deal with concurrency quite reasonably. State, caching and latency are all to do with performance which is always a bear. To that I'd argue that the commerce that is taking place daily on the internet seems to be a good indication that things are acceptable even if they could be improved. Metadata is the eternal headache of course but HTTP will give you headers and soul to help a little.

Discovery is addressed by URI as identification, the notion of hypermedia (either link headers or references in the media) and perhaps the current best practices of introspection resources. Persistence and structured data, I'll argue, are being addressed, warts and all, by the relational database, the seemingly-unstoppable spread of XML and, I believe, the current ascendancy of feeds. On this last subject, the wiring of the web, I am cautiously optimistic that the Atom store dream could be an answer; i.e. the combination of feed format (say Atom/RSS) and a wire protocol - which perhaps the Atom Publishing Protocol or similar could be. On the question of extensibility, last year I started a response that I felt was needed due to Dion Hincliffe's unbelievable assertion that "extensibility was the Achilles heel of REST". It always takes me a year to respond to minor footnotes but if there's one thing I'll do in the next few months, I'll be sure to write about REST and the Holy Grail of Extensibility.

But anyway, that is getting ahead of myself. I've been told to save my musings for "the book" or to stick to writing the running code that will "show, rather than tell" yet I keep falling for this web as conversational engine. Still there are undoubted social benefits of these exchanges and perhaps conversations like these are another virtue and externality of the web style. In any case, consider this my long winded response, Ryan: in matters of technology adoption and systems design, let's stick to the elevator pitch.

Further reading:

The Sequel


[Update - March 27, 2006] It seems as if everyone is getting into shaping the pitch and the language has been quite interesting.
  • Danny Ayers remarked that we should go back to the source and points at Tim Berners-Lee's pitch from last year
    Web architecture 101
    • Things are denoted by URIs.
    • Use them to denote things.
    • Serve useful information at them.
    • Dereference them.
    That indeed is about as brief a pitch as some executives will be able to handle and it covers the essentials.
  • Tim Bray's pitch is fairly pithy too, and for the last plank he uses
    You expect to ship a lot of URIs around in the bodies of requests and responses, and use them in operations that feel like link following.
    Now that's quite a mouthful in a presentation but it works fine in an elevator. I think "dereference them" is more terse and captures much of the same insight.

    As an engineer who is interested in precision in language, I tend to prefer Roy Fielding's formulation of "hypermedia as engine of application state". It's short and alludes to both the implementation and the area of focus of the web style. But your mileage may vary and I think it depends on the audience. We should be interested in a pitch that works because the advocacy struggle isn't over even if some are already thinking about the future issues. In this light, it was good to see Joe Gregorio again emphasizing the Show me the code route he embarked on last year. That View Source Imperative is the secret ingredient as far as adoption goes.
Note that everyone seems to conform to the Rule of Four as far as bullet points in the pitch go. Interestingly enough, Roy Fielding used to go with a five point pitch until he merged what were his previously separate definitions of "resource" and "URI" into the phrase "Identification Of Resources". I've proposed my own four point plan as a model for ArRESTed Development or The Low End Theory.

I concur of course with the endorsement of the formulation of REST - the web style and not just because I seem to have juice (of the google flavour) on that front having internalized that phrase long ago in my interventions, but because it gives us a tag, REST, combined with a catchphrase. As we know, every movie needs a tag line. Especially in Deadwood: "6 million ways to die, choose one". That is the B-movie of distributed computing. We want to move beyond grindhouse pulp fiction and get some of those glamourous, golden Hollywood trophies. And if that fails there's always the Gospel of REST.

The Elevator Soundtrack

  • Outkast - Elevators (Me & You)
    The chorus of this laidback piece of Atlanta folklore could well be a stand-in for the inclusiveness of the web style and its architecture of participation.
    Me and You
    Your Momma and Your Cousin Too
    Rollin' Down The Strip On Vogues
    Comin' Up Slammin' Cadillac Doors
  • [Update] A hat tip to the good doctor, Ernie Prabhakar, who points to a real life Huxtable Quartet. When I first started using HUHXtable, I was thinking of the Cosby Show and of comfy sweaters, thus it's great to hear that the Slide Huxtable Quartet is itself a tribute to that show and to the "Play It Again, Russell" episode in which Cliff's father, trombonist Russell "Slide" Huxtable (Earl Hyman) hosts a jam session. REST has even got a house band.
  • Miles Davis - Ascenseur Pour L'Echafaud
    I've always loved Miles Davis's cool soundtrack to one of the great film noirs which saw a great print released last year. It's atmospheric and gets the job done - and with verve. I am always upset that ascenseur is translated as lift rather than elevator which is more heady to my ears. I'll conclude by suggesting that the web style will save you from heading up the Elevator to the Gallows.


File under: , , , , , , , , , , , , , , , , , , ,