Thursday, November 10, 2005

Resilience and Adaptability

I continue to mull the question of what drives technology adoption and how that should inform system design. One aspect I've covered in the past is about comprehension and ease of authoring and, on reflection, I will eventually flesh out the paper I outlined: "The importance of syntax in technology adoption".

This note though is about some of the other factors that come into play as expressed in concepts like leverage, robustness, adaptability, transparency and the like. When it comes to implementations of a given technology, things like Postel's law apply and in the marketplace, economists also have a lot to say on the matter.

The following passages seem separated at birth although they refer to different technologies. First, David Reed discussing network protocols.

Read the original TCP papers and so forth. TCP was never "efficient" nor was it intended to be. It was intended to be interoperable. It was an overlay network. It still achieves those goals far better than an "efficient" protocol (especially since efficiency seems to come at a cost - specialization, brittle response outside a narrow set of operating points, etc.).

Resilience and adaptability is far more important than "efficiency". Far too many in the research community are focused on a narrow set of metrics, invented by academics, for academics, merely because they are quantitative... We need more researchers focused on how the cars fit into the human ecology of communications, in particular some ought to be thinking about inventing better metrics for things like adaptability and resilience, which are far more relevant systems properties. Can anyone tell me a defensible measure of adaptability that has been used to rank network performance in the real world?
Adam Bosworth, discussing the lessons learned from the adoption of the web over the past 15 years covers much the same ground.
1. Simple, relaxed, sloppily extensible text formats and protocols often work better than complex and efficient binary ones. Because there are no barriers to entry, these are ideal...

8. KISS. Keep it (the design) simple and stupid. Complex systems tend to fail. They are hard to tune. They tend not to scale as well...

As I’ve argued before, spreadsheets and SQL and PHP all succeeded precisely because they are simple and stupid — and forgiving.
There's lots to digest here and this is a broad topic. The lesson seems to be about how to approach efficiency and the perils of premature optimization as opposed to interoperability (or at least the axis along which to optimize a system). This just shows the wide reach of the end-to-end principle. Still, on the matter of efficiency, the words used to describe these patterns are revelatory: "resilience" and "adaptability" on the one and a case of "sloppily extensible" and "forgiving" on the other.

Bosworth's use of the word sloppy often gets him into trouble in his advocacy because it is counter-intuitive. Mark Baker, who's keenly aware about marketing matters, augments it and makes the advocacy pitch by calling this Principled Sloppiness: "the principled application of must-ignore style extensibility".

This, it seems, is one of the underrated virtues of the web style. Biologists would label such system properties under the heady label of "evolvability" and bring Darwin into the mix and who can blame them. When you poke around the writings of those who helped design the web architecture and see the same word you know that there is something of value in this notion.

The question for a designer or architect is how to highlight these principles of system design when pitching bean counters (or even fellow technologists) who are often focused on a different narrative. How does one measure adaptability and resilience? And if one could, should the measure come into play in deciding when one should pick XML instead of ASN.1 to take an example trading off readability for binary efficiency (or for those concerned with DOM scripting, what are the tradeoffs between XML instead of JSON as formats for data interchange)?

I wonder how many nascent technologies get discarded before they can prove their worth simply because no one can articulate their worth on the resilience and adaptability axes. The paradox is that these properties of a system are often the most crucial when it comes to adoption. Oh well, software and network engineers haven't gone through their industrial revolution.

So there we have it, a brief stab at identifiying a few suspects in that murder mystery that is Rohit Khare's Who Killed Gopher?. We'll scrutinize the rest of the dinner guests in later notes.

Resilience and Adaptability, a playlist


A resilient soundrack for this joint

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

No comments: