Sunday, January 14, 2007 

The tacit dimension of Infrastructure

In a previous post, I argued that real infrastructures should rapidly disappear from conscious processes. To a large extent, we should be able to write code without any concern about what is going on under the infrastructural layer. I also argued that we often call infrastructure something that lacks this highly desirable property. However, as a smart reader noticed, I didn't explain why information hiding is so important at the infrastructural level. Readers beware, reasons tend to lean quite a bit on the philosophical side :-).

Let's start with a definition of infrastructure. I won't use a dictionary or the wikipedia here; instead, I'll quote a simple but effective definition from Donald Norman (in "The Invisible Computer"): the term infrastructure refers to the basic services and foundations required for a system to function. Norman then refers to the everyday life infrastructure we all take for granted in modern times, like sewers, power lines, paved roads, and so on.

I should say we usually take them for granted. Nobody is usually concerned about the process of producing and distributing power. We just plug something in, and we expect it to work, hassle-free. The infrastructure largely disappears from our thought processes. As Mark Weiser said (in "The Computer for the 21st Century", Scientific American, September 1991 [draft here], The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.

There are times, however, when we do notice. It's when the infrastructure does not work. A little diversion may clarify this further.
In an interview with John Bennett (Reflective Conversation with Materials [which largely inspired me to learn more about Schon's work and ultimately lead to my paper "Listen to Your Tools and Materials"], Donald Schon talks about Michael Polanyi and his concept of tacitness. He speaks of the way we use tools, and how they go largely unnoticed: I'm writing on this pad now with a pen. As I guide the pen along the paper, I am not paying attention to the pressure of my fingertips on the pen. [...] I'm paying attention to the content of what I am writing, rather than to the process of writing. [...] When my pen begins to run out of ink and I have to press it, then I become aware of the interaction between me and the pen.
The technology disappears, until it stops working.

What's wrong with computers? Here is Norman again, from the same book above: In many of our technologies, the infrastructure is in the way, it is always present, and it seems to always go wrong. I would say that it's because it's not an infrastructure, but a visible superstructure. This is true for the end user (consider a program that fails to install, can't be properly uninstalled, prevents the previous version from working or being reinstalled, etc.) and is true for programmers as well, whenever they use the wrong "infrastructure".

Consider a library like MFC. It does a very poor job of abstracting details of the underlying platform, so the programmer is usually concerned with a) the OO-design (sort of :-) of MFC, like "which methods should be overridden in a derived class", and b) what is going on under the surface, like "is what I'm trying to do really acceptable for the underlying Windows API". Indeed, MFC can't be really qualified as an infrastructure for GUI development. It is just a thin veneer over the API. It's mostly a superstructure.

Consider virtual memory. Most programmers are not really concerned about the details of paging, or how the CPU supports virtual memory, and how the operating system plays along with that. They just expect it to work. They notice in some cases (trashing), but even in those cases, the solution is usually found elsewhere, not by messing with the inner workings of virtual memory. There are exceptions, as usual, but virtual memory can be considered a real infrastructure.

It is important to understand that there is nothing wrong in creating a superstructure. It is just plain wrong to call it an infrastructure (Weinberg would call this a lack of congruence between what is said and what is done). We must expect an infrastructure to disappear, or we'll be overloaded by a myriad of details, most of which are out of our control anyway (that's a well-known recipe for high stress and low productivity). By constantly exposing the underlying details of a so-called infrastructure, we basically set up the same scenario of a faulty infrastructure: our users have to notice. That's very much like a self-fulfilling expectation, and not a particularly good one :-).
Comments:
This post remind me of a Joel on Software post about
The Law of Leaky Abstractions

Questo post me ne ricorda uno di
Joel on Software

Qui si parla di infrastructure e superstructure, là di abstractions ma mi sembra che ci siano delle somiglianze.

Sbaglio?

Un lettore di tutti e due i blog
 
Alessandro Gentilini:

Un lettore di tutti e due i blog

? Che significa ?
 
Chiedo scusa.

Ci sono arrivato.
 
Post a Comment

<< Home