Exploration Through Example

A transcript of an OOPSLA talk: Table of contents

Why does Actor-Network Theory (ANT) care so much about things? Latour explains in terms of baboons. Baboons usually have a pretty good life. They don’t have to spend a whole lot of time looking for food, but they do need protection from predators. That means they need to live in packs to survive. How do they keep the packs functioning well? In the words of the Agile Manifesto, they spend a lot of time attending to individuals and interactions. In fact, they spend all their free time attending to individuals and interactions. As a result, they have no time to write software.

We humans have a trick: we substitute things for social forces. Latour uses the example of policemen. Let’s say that society has decided that people should drive slowly down a particular stretch of road. People being what they are, sometimes some of them will want to drive fast instead. One way to prevent that is to station a policeman by the side of the road. That person exerts a social force that will cause people to slow down.

But then we’d be like the baboon: devoting a lot of time to maintaining group norms. Unlike the baboons, though, we have an alternative:

In the US, we call these “speed bumps.” In other parts of the world, they’re called “sleeping policemen.” (The model pictured is a Rediweld Sitecop sleeping policeman.)

Through a different mechanism, the sleeping policeman has the same social effect as a human policeman: slower cars and an environment matching collective preferences.

We can take this a step further. Consider neighborhoods. Many sociologists might explain the existence of neighborhoods by appealing to powerful abstract forces like power, class, or racism. An ANT explanation, by contrast, might start with speed bumps.

Consider a car as an “actor” that can affect—push on, act as a force upon—other actors, specifically children. Speeding cars are a danger to children, and they affect their behavior. Children aren’t allowed to play near streets where cars travel fast.

Now suppose speed bumps are put up across those streets. The speed bumps mediate or “translate” the effect of cars on children. The cars become less dangerous. Parents (another set of actors) are more likely to allow children to play outside. As many parents know, children who are playing together outside soon invade houses in packs. Parents come to know the nearby children. And, inevitably, they come to know those childrens’ parents. They begin trading favors like driving children around. They become neighborly.

Now, speed bumps by themselves don’t create a neighborhood, but there are lots of other physical objects that have similar effects, and they keep having these effects, day in and day out. The continual recurrence (”circulation”) of all these forces, all these actors affecting other actors, is (according to ANT) a sufficient explanation for the “assembly” of a neighborhood. We don’t need to bring abstractions like power into the equation.

Does that make neighborhoods somehow less real than cars? (Is ANT purely materialist?) To Latour, neighborhoods are as real as cars if the people in the story talk about them that way. For example, the city council in my town would, if you asked them, say my neighborhood is real. Some time ago, the city wanted to replace our antique street lamps with ugly modern street lamps. The neighborhood pushed back and got more expensive street lamps that fit better with our lovely old brick streets and old trees. To the city council and the people reading about the brouhaha in the newspaper, the neighborhood was an actor that changed things. To Latour, it would be arrogant for an analyst on the outside to tell us that our neighborhood isn’t really real. ANT comes with a respect for the ontology of the people doing the work; that is, it assumes they’re pretty savvy about what things exist in their world.

Complete table of contents

At OOPSLA in Montreal, I gave an invited talk on Actor-Network Theory (ANT), a style of observation and description that’s most associated with the French philosopher/sociologist Bruno Latour. I told some stories about how I use ANT in my work. I also said some hotheaded things about its relevance for some problems I see with Agile. Because blog posts should be short, I’m going to blog this talk in pieces. Here’s the first.

(This first bit is something of a retread for those who’ve been reading my blog since 2003.)

I’m a consultant. I drop into projects for about a week. I work with the people on the project—pairing, testing, whatever. Along the way, I’m supposed to notice things they don’t see and make suggestions they haven’t already tried, all with the aim of helping them get better at building software.

A tough job: projects are complicated, with lots of moving parts. It’s terribly easy as a consultant to see only the things you’re used to seeing. Worse: it’s easy to see things that aren’t there, just because they’re the things you’re best at seeing.

So a consultant needs mental tricks to kick himself out of ruts and habits. I use ANT as such a trick.

An example: the role of testing in Agile projects

One thing ANT people do is pay attention to things and how they move around.

In the mid-to-late 70’s, Bruno Latour—a philosopher who knew little English and less biochemistry—arrived at the Salk Institute in San Diego, California. Not only did he know little about the content of the work they did there, he deliberately tried to forget what he did know. He wanted to be like an anthropologist visiting some completely foreign tribe with a completely different culture.

As you might expect, some of his observations were odd. For example, he saw that there was one place in the laboratory where, at periodic intervals, bound sheaves of paper called “journals” were delivered.

At other places, people called “technicians” tended expensive and balky machines whose purpose seemed to be to make marks on paper (line drawings, blotchy pictures, lists of numbers, and the like). These two sets of paper were delivered to a third place, the “offices” of the “scientists”. The scientists put the two types of paper—journals and “experimental results”—next to each other and compared them. As (and after) doing so, they would write things on new pieces of paper, which they would deliver to a place inhabited by “typists”, who would “type them up” (put them in a tidier form), then send them out the door to “publishers” who would, in due course, bind them up together with other “papers” and deliver the resulting journals to… still more laboratories.

To Latour, it seemed the laboratory was a factory for turning paper into more paper.

Now, Karl Popper, likely the most influential philosopher of science, would describe all of what Latour saw as an epiphenomenon, not what science is really about. What science is really about is this:

1. A theoretician comes up with a theory. Oddly, the examples always seem to use really great theoreticians, the ones you’ve all heard of.

2. Someone—maybe the great theoretician, maybe someone else—makes predictions from that theory: in situation X, the world should do thing Y.

3. An experimenter—who you quite often won’t have heard of—will create situation X and observe whether the world does thing Y.

4. If the world does not, the great theoretician has to discard the theory and try again.

5. If the world does do Y, that does not confirm the theory. No number of confirmed predictions logically proves that a theory is true. If, however, the theory passes a sufficient number of challenging tests, scientists are justified in accepting it and using it in their own work.

Popper’s opinion matters to me because some software testers make explicit analogies between Popper’s view of science and testing:

1. The programmer is like a theoretician, proposing a theory like “for any input X typed into this text box, the program will calculate f(X).”

2. The tester turns that into a prediction. “So the program should calculate f(X) if the input is one of those things we call a SQL injection attack.”

3. The tester sets up the experiment, tries a SQL injection attack.

4. If the program doesn’t work as predicted, the programmer has to go back and try again. The tester gets a little thrill, because it really is fun to break programs.

5. If the program passes the test, it may still not be correct—no number of passed tests suffices to prove the program is bug-free. But if it passes a sufficient number of challenging tests, managers are justified in releasing it into the world.

The problem is the effect on an Agile team. At the time I was thinking about this (around 2002), there was lots of tension between testers and Agile proponents. Unwise things were said on both sides. Against that backdrop, the testers’ normal drive-by defacements of the programmers’ programs—and the programmers’ egos—wasn’t contributing to the unity of effort I believe is so important on Agile teams. One could say the programmers should be more egoless, but I’m more inclined to work with the grain of human nature than against it.

Popperian science seemed to be the wrong metaphor. (Besides, having read people like Feyerabend and Lakatos, I was pretty skeptical that Popperian science had anything much to do with how real scientists came to accept theories.)

At some point, a detail of Latour’s book describing his Salk experience (Laboratory Life, with Steven Woolgar) came to me. During the process of turning paper into more paper, scientists would hand out “drafts” to other scientists. They’d then get together to discuss the drafts. The conversation would have this tone:

There’s a good chance that Morin is going to be one of the reviewers of this, and you know how she is about antibiotic treatment. If you want this to get past her, you’ll need to strengthen this justification here.

or

I can help you with SAS, make the statistical analysis more solid.

or

If you included the results of assay X, more people would be interested. I can lend you my technician.

The effect is one of people anticipating what dangers the paper will face when it ventures into the world, and making suggestions about how it might be muscled up to survive them. Although I don’t think I realized it at the time, this is the style of paper reviewing that Richard P. Gabriel had imported from the creative writing community into the design patterns community. (See his Writers’ Workshops and the Work of Making Things.)

This, I realized, was a way of having testers’ skills contribute both to the product and also to the team’s feeling of unity of effort. So I began using this new metaphor in my consulting. The particular suggestions I make depend on the team. I might nudge the testers into the role of supporting the (typically overworked) product owner. They could help her talk more more precisely and comprehensively about what she wants. They could then turn that clearer description into tests that programmers could use in the familiar test-first way. Or I might nudge them into the role of teaching the programmers about the domain, one test at a time. (This affects the kinds of tests you write and the order in which you use them.) And so on.

I think this style of thinking about testing is now pretty common in the Agile world. It probably would have happened without me—I’m by no means the only person to think along those lines. That’s not the point: the point is that I probably would not have thought of it had I not absorbed a bit of Latour’s way of looking at things.

When the hell are personal computer software makers going to let us recover from crashes as well as Emacs has done for well over twenty years? Most of a day’s work lost, and it is not my fault, because it’s not my job to develop the right reflexes for your stupid program!

At the functional testing tools workshop, Ward Cunningham devised a scheme. John Dunham, Adam Geras, Naresh Jain, and I elaborated on it. Before I explain the scheme, I have to reveal the context, which is different kinds of tests with different audiences and affordances:

As when I first encountered wikis, I missed the point of Ward’s newest thing. I didn’t think swimlane tests had anything to do with what I’m interested in: the use of tests and examples as tools for thinking about a piece of what the product owner wants with results that help the programmers. With swimlane tests, the product owner is going to be mostly reactive, saying “these test results are not what I had in mind”.

What I missed is that Ward’s focus wasn’t on driving programming but on making the system more visible to its users. They were written for the Eclipse Foundation. It wants to be maximally transparent, and the swimlane tests are documentation to help the users understand how the Foundation’s process works along with assurance that it really does work as documented.

What Ward noticed is that his output might fit together nicely with my input. Like this:

Here, the product owner begins with an executable graphical example of what she wants. The programmers produce code from it. As a user runs that code, she can at any moment get a bundle of pictures that she can point at during a conversation with the producer and other users. That might lead to some new driving examples .

The point of all of this? It’s a socio-technical trick that might entice users to collaborate in application development the way wikis entice readers to collaborate in the creation of, say, an encyclopedia. It’s a way to make it easier for markets to really be conversations. John Dunham dubbed this “crowdware”.

It won’t be quite as smooth as editing a wiki. First, as Naresh pointed out, the users will be pointing at pictures of a tool in use, and they will likely talk about the product at that level of detail. To produce useful driving examples (and software!), talk will have to be shifted to a discussion of activities to be performed and even goals to be accomplished. The history of software design has shown that we humans aren’t fantastically good at that. Adding more unskilled people to the mix just seems like a recipe for disasterware.

Wikis seemed crazy too, though, so what the heck.

Laurent Bossavit and I are working on a site. Once it reaches the minimal features release, I’ll add some crowdware features.

I realized at the functional test workshop that, to some extent, the six years of Agile have replaced development teams whining about incomplete requirements with development teams whining about the lack of a product owner’s time.

Really: is that progress?

Well, yes. At least we’re not still whining about changing requirements.

Nevertheless, this flash made me think about that old XP metaphor of the Customer driving the project like a person driving a car. When you drive, you don’t think about the steering wheel, you simply think about turning the car, and it turns. The steering wheel, the philosopher Heidegger said, is ready-to-hand. But when the power steering goes out, suddenly the steering wheel is in your face. What was once a simple reflex is now a conscious act. The steering is present-to-hand.

A tool being present-to-hand can be good or bad, but it’s always disconcerting.

Think of it: to the product owner, the team is always present-to-hand. She must attend to them. It’s not like driving at all.

Directing a product team must be something like my telling my 12-year-old to clean his room. When I do that, he goes off, comes back, and reports that he’s done. When I look at his room, I see 18 different things that are still lying on the floor. I have to painstakingly tell him 18 different things to pick up. Were it not for my steely determination to raise presentable human beings, I’d just do it myself.

That feeling is what it must be like to be a product owner.

I got a nice note today complimenting me on my never-finished A Little Ruby, a Lot of Objects. I get those every once in a while. It’s a Ruby book modeled after The Little Lisper.

I’ve been considering what to do with this, my second midlife crisis. (The first was at 28.) Having bought the Porsche, gotten fit, and gotten divorced in the first one, the customary responses are out. Been there, done that. So, instead, I’ve been thinking that finishing A Little Ruby might be a good use of pent-up frustration and legacy idealism.

Besides being fodder for language geeks, it would also have a practical purpose: I think of it as becoming the best book for those wanting a gentle introduction to extreme metaclass hackery.

Also: having just gotten a royalty check for Everyday Scripting, the idea of publishing the results appeals.

Would you buy such a book? Do you think other people would?

Here’s a kind of code I find myself habitually writing until I realize I can’t implement it:


    watch {
      # some calculation
    }.and_whenever(:something_happened) {
      # do something
    }.and_whenever(:something_else_happened) {
      # do something else
    }


What I want this to do is:

• Stash away the block with “some calculation”

• Run the second block. This does something that will affect the calculation.

• Run the third block. This does something else that will affect the calculation.

• Run the first block, then undo the effects of the following blocks.

The problem is that I don’t see a way to know when you’ve reached the end of the chain of 2nd, 3rd, … blocks, and it’s now time to execute the first block.

Now, there are alternatives. You can put the blocks in the right order. You can make a single and_whenever that takes a hash from names to lambdas as its single argument (presuming the order of evaluation doesn’t matter). You can put a “sentinel” method at the end of the chain, like .ok_do_it_now.

What I’m wondering if there’s some clever way of making the original form work.

I’ve created both “announce” and “discuss” mailing lists for my different gems:

• user-choices lists (home)
• gossip lists (home)
• graffle lists (home)

I just committed a change to a project Laurent Bossavit and I are working on. As a result of that, the following happened:

1. This came via Jabber:
   
2. This was posted to Twitter:
   
3. This came in email:
   
4. This was sent to Campfire:
   

Had I deployed a new version, I would have gotten deployment messages to each of the above, plus in our Trac timeline:

(Trac does a perfectly fine job of handling commits on its own.)

That’s all due to a library of mine called Gossip, which provides a unified interface to all those destinations. It comes with three utility scripts:

• svntell, which you’ve seen.

• watchdog, which reports on the output and duration of a command. (It’s derived from the script in Part 4 of Everyday Scripting with Ruby.)

• fanout, a command that relays a message to the distant destinations. (Our Vlad task uses it to report on deployments.)

The commands and library use the User-Choices library, so they’re configurable up the wazoo.

All this: done in service of ease at work.

I hope you use it.

Here are two more examples of what might become my style for writing tests that use mocks. They add a “because” clause that separates what comes into the mock from what comes out of it.

  def test_checker_checks_again_after_grace_period_in_case_of_error 
    checker = testable_checker(:grace_period => 32.minutes) 
      
    during { 
      checker.check(”url”) 
    }.behold! { 
      @network.will_receive(:ok?).with(”url”) 
      and_then @timesink.will_receive(:sleep_for).with(32.minutes) 
      and_then @network.will_receive(:ok?).with(”url”) 
      but @listener.will_not_receive(:inform) 
    }.because { 
      @network.returned(false).from(:ok?) 
      but_then @network.returned(true).from(:ok?) 
    } 
  end

As before, the test first describes the activity of interest in a “during” clause. The point of the test is how the object poked in the “during” clause pokes the rest of the system. That’s in the “behold!” clause. The next question is the connection between the two: why did the object do what it did? There’s a good chance you know why from the name of the test and from reading previous tests (which I tend to arrange in a tutorial sequence). If not, you can dive into the “because” clause, which details how the rest of the system responded to the poking.

  def test_checker_finally_tells_the_listener 
    checker = testable_checker 
  
    during { 
      checker.check(”url”) 
    }.behold! { 
      @listener.will_receive(:inform).with(/url is down/) 
    }.because { 
      @network.returned(false).from(:ok?) 
      and_then @network.returned(false).from(:ok?) 
    } 
  end