Technical Arteriosclerosis

Engineers are funny people. I write this not because many are socially maladjusted but in recognition of the peculiar language that we tend to use. As in any community, our patois is borne of the interchange of often clever in-jokes. For example, this is why we say that things are fubar or that we talk about bugs (see a discussion of The "First" Computer bug).

The language of disease permeates our discourse whether it's talk about viruses, worms, inoculation, heartbeats and other sundry terms. The spectre of war also raises its dismal head. Security folks talk about black hats, white hats and use euphemisms like attack vectors. The most lucrative sector in the industry is now security as if in response to the 'global wars' that are supposedly being fought. I find it a little distasteful since there's an imputed morality in our choice of terms.

Of late, the linguistic trends in technology have been about decline and fall. Perhaps this was because of the apocalyptic fin-de-siecle hype and millennial angst about Y2K or maybe there's a wider sociological trend at work. Whenever monopolies have risen (and we have a few in the business) and over-reached, the Last days of Pompeii have loomed in the popular imagination.

Take "When good interfaces go crufty". The title alone make me want to start wiping the sleep from my eyes. I've been coming across both crufty and crusty increasingly in my work.

And what about "Software decay, Software rot"? The things we deal with must be increasingly gangrenous. The reality check of the bursting of the tech bubble is likely the motive force in these coinages.

My latest term of choice is Technical Arteriosclerosis.

I encountered this term while reading a very good paper about new paradigms in the design of network systems, Developing a Next-Generation Internet Architecture (PDF) (html via the Google cache) - it's also mentioned in a shorter presentation (PPT).

Bob Braden, David Clark, Noel Chiappa and others, who were there at the inception of the end-to-end internet that we have, almost give the impression of having thrown their hands in the air. Some have given up on the idea of IPv6 ever being widely adopted or of finding evolutionary solutions to the leaks in the abstractions of existing networks (the rise of middleboxes, NATs and the consequent loss of Internet transparency as well as the coupling in DNS names of location with endpoint identifiers etc). They coin the term as follows.

In general, an increasing collection of point solutions leads over time leads to a design that is complex, tangled, and inflexible.

The Internet is exhibiting this technical arteriosclerosis today.

In their context, I fear that their alarm is a touch oversold. I see some light at the end of the tunnel - what are STUN, Midcom or Behave if not evolutionary and pragmatic remedies to the internet ills? Not to mention that people are building on useful things on this here existing internet. I hate NATs as much as any thinking person yet a Linksys box sits in front of my cable modem, like most everyone I know.

I like the term, technical arteriosclerosis, because it's a very accurate description of a piece of code I'm currently dealing with. Although this it has just gone through its first release, I am afraid to touch it for fear of killing the patient. Clogged arteries have been the mainstay of my day job for the past few months.

In this context I came across a useful discussion of these issues. As ever, everything goes back to the Linux Kernel where all issues of technology manifest themselves in microcosm as architectural parables

(Alan) Cox explained that he and Torvalds sometimes have different approaches to fixing a problem, due in part to their different responsibilities. As the maintainer of the development kernel Torvalds needs make sure the kernel code is easy to maintain, while Cox is more interested in kernel stability and is not so worried about "hacking" the code to get it to work.

"One of the hard problems to fix are design errors," said Cox. "These are a pain because they need a lot of refactoring. Linus' approach is to re-write it to a better design. But to get a stable kernel you tend to do small horrible fixes. Linus is very keen to have maintainable code, while to have a stable kernel I'm keen to have code that works."

I laud the impulse of Braden et al, but there's a hint in their response of an inclination towards the "rewrite from scratch" point of view (the Linus point of view). In software design, Joel Spolsky has persuasively made the case that this is tragically flawed. Cox would side with Joel I think. The Linux kernel oscillates between these different forces. More generally, these competing dynamics shape the architecture of the systems that we engineers build.

Allow me to go for hyperbole if you will:

The signal challenge of this technological age is the response that system designers choose in response to technical arteriosclerosis.

And this decision will gain increasing importance since the systems we build verge almost immediately towards overwhelming complexity. The jury is still out about which is the right approach and perhaps both tendencies are needed at different times as market needs evolve.

One bright light I have found in this respect is in the reaction to RSS that has its expression in the development of the Atom publishing format and protocol. The elements are as follows: early diagnosis of the clogged arteries, development of a clean and tight specification, running code, a lightweight touch in anticipation of system evolution and, most of all, architectural leverage like I keep harping on.

[Update: April 6 2005]

Also very relevant is this further discussion in the Kernel Mailing List. A thread ostensibly about version numbers for the Linux Kernel, it very quickly boils down to this sociological and design issue I've outlined, namely the tension in software development between 'stability' and 'api cleanliness'. The Alan Cox and Linus Torvalds debate continues apace.

File under: technology, language, linguistics, systems, design, engineering, architecture, network, web, software, best practices, humour, toli