Aramis or the Love of Technology, by Bruno Latour

Posted: May 13, 2004 at 12:12 am in management, nonfiction, philosophy

Amazon link

I really liked Science in Action, another book by Latour, so when I saw this on a friend’s shelf, I borrowed it. Unfortunately, it took me several months to actually get through it; I started it over Christmas vacation, but I kept on getting distracted by other things, until I finally powered through the last bit a few weeks ago. And now I’m finally writing it up.

Aramis was a proposed public transit system in France, one that would combine the best aspects of the train and the automobile. It was designed to be a point-to-point train system, with small cars that would pick you up at your home and take you directly to your destination with no stops in between. To do this involved many technology leaps, such as “nonmaterial coupling”, where two train cars would act as a train without any physical connection (so that a car that was speeding out of a stop could hook up to the train in front of it, and another car could drop out and stop without stopping the whole train). It sounds like a fantastically cool system. The project existed in various forms from 1970 to 1987, through several iterations of prototyping and proof of concept. The technology even worked – the book has some great photographs from the final testbed of cars actually travelling together without being connected physically. But Aramis never made it to the real world. And this book is the tale of a sociologist hired to find out “who killed Aramis?” – what was the fatal flaw in the project or in the management of the project that prevented Aramis from achieving reality?

Latour takes an interesting approach to the book, using a form that he calls scientifiction, a cross between narrative and history, of culture and technology. His protagonist is a young engineer working with the sociologist to figure out the history of Aramis and where things went wrong. Interspersed throughout the work are interview excerpts from people they talk to, as well as impersonal observations from the author himself. Plus there are bits where Aramis itself speaks and asks to be born. These different authorial voices are distinguished by typeface, but that only makes it slightly less confusing. And it made it a bit of a slog to try to keep everything straight, so every time I put it down for a couple weeks, it would take some effort to figure out where I had been and what was going on.

It’s pretty interesting, though. Latour is a philosopher of science, emphasizing the culture in which the science is embedded. In Science in Action, he talks about how the bureaucrat lobbying for a laboratory in his district is doing science, because it’s all part of the same process. Here he is taking the same approach to project management. The main idea of his that I took away from this book was that a project is not real until it’s built. Until there’s something physical that everybody can point to and say “That’s Aramis”, it exists in a realm of uncertainty, where all of its parameters can still be negotiated. Latour goes one step further in fact; like his idea of black boxes in Science in Action, where things are packaged up so we don’t think about them, Latour claims that the project doesn’t really exist until it no longer exists. That sounds contradictory when I say it that way, but his point is that if Aramis had been built, people would have started using it and it would have faded from their consciousness. They would not have said “I am taking Aramis to meet you at the theater”, they would have just said “I’ll meet you at the theater”. Only when something is taken for granted is it truly real.

The book is fascinating because the sociologist and his engineer intern interview all the various parties involved with the Aramis project, and trace it through its various ups and downs, and the number of different viewpoints is astounding. Everybody has a pet theory of why the project eventually failed, but none of them seem to match up with what happened. If it had really been a critical technical failure, it would have been caught much earlier in the process. If certain people had the antipathy towards Aramis that others suggest, it would never have been approved to go forward with the final full trial. If it was all just politics, that doesn’t quite sync up either. It’s a conundrum.

Latour brings out all of this and presents it to the reader. His authorial viewpoint sections also point out the negotiations that are taking place in the design of Aramis. As new people get involved, the vision of Aramis changes as do the requirements (“The only way to increase a project’s reality is to compromise, to accept sociotechnological compromises.”). He points out that in a successful project, these requirements eventually converge and a physical thing actually gets built which sets the technology into a concrete reality. In Aramis, that never happened; the requirements shifted on a yearly basis depending on which branch of the government was involved, and where they were trying to build it. Latour warns the reader:

If we say that a successful project existed from the beginning because it was well conceived and that a failed project went aground because it was badly conceived, we are saying nothing. We are only repeating the words “success” and “failure”, while placing the cause of both at the beginning of the project, at its conception… All projects are stillborn at the outset. Existence has to be added to them continuously, so they can take on body, can impose their growing coherence on those who argue about them or oppose them.

Those projects that succeed are those where the actors involved agree on a coherent vision of what they are building, or alternatively where one of the actors is strong enough to impose their vision on others. This did not happen in Aramis. There was actually a nice compare and contrast project that Latour uses, called VAL, which was an automated rail system built during the same timeframe by the same company. That was an instance where the desires of the company matched up with the desires of the city where it was to be built, and the project went smoothly and VAL came into existence. It’s interesting to see how things went differently in the two cases.

This whole thinking of the project as a continuous negotiation is of great interest to me. At work, I couldn’t see the point of spending weeks writing a Product Specification Document. But reading Latour made me realize that the point was that setting things down in such a document was a process of negotiation and compromise, and the reason that people took the document so seriously is that they were authoring their vision of the future. My cry that “It’s just a document – it’s not real!” is inappropriate, because the document will define reality for this instrument, and now is the time when all of the various actors need to address their issues and balance their needs. The project is a living thing, with the documents being merely the history of the compromises necessary to move the product along.

It’s an interesting viewpoint, and one that should have been obvious to me, but reading this book really made it evident. Latour’s emphasis that technology is always embedded in a social and cultural context, and that the technology does not bring itself to life, but requires real people (the sociologist in the book repeatedly emphasizes following the actors) to invest in it, both fiscally and emotionally. And following the trail of negotiations and compromises as Aramis moved from phase to phase, with new interests being brought aboard at each stage, was a fascinating mystery hunt for Latour to try to solve. I won’t give away the ending of who actually killed Aramis, though – it won’t make sense without reading the book…

Comments are closed.

RSS feed

LinkedIn profile

Twitter

Speaking of biking, I just finished the San Juan huts mountain bike tour from Durango to Moab: plus.google.com/u/1/+EricNehrl…

Recent Posts

  • Thinking Fast and Slow, by Daniel Kahneman
  • How is your memory indexed?
  • Expertise as exception handling
  • Maximizing collisionability
  • Hosting update
  • Random Posts

  • Team building
  • Talent in a free agent world
  • What makes a community?
  • Searching for continuity
  • Context, cognitive subroutines, and collectives


  • Archives

  • Categories