malvasia bianca

The last chapter of Galison’s Image & Logic is about the relationship between (breaks in) different strands of practice within physics. If you treat the notion of paradigms sufficiently seriously, you’re led to think that theoretical breaks and experimental breaks come hand in hand: the two sides of a paradigm shift are incommensurable, so the change in the theoretical viewpoint also means that experimentalists on either side of the break can’t really talk to each other, because they’re referring to different objects, different concepts, even if they use the same words.

Which Galison takes issue with, both for conceptual and historical reasons. As he says, “When a radically new theory is introduced, we would expect experimenters to use their best-established instruments, not their unproven ones.” (p. 799) And indeed, as he discusses on pp. 811–812, when theorists were fighting over the nature of space and time, they took great care to translate their theories into terms that could be tested by the experimentalists of the time; different paradigms fought, one of them (special relativity) won, but the results were agreed to by all parties, there was no incommensurability that the notion of a paradigm shift might suggest.

So, rather than breaking at the same time, the experimental practices and theoretical practices underwent changes at different times. In fact, Galison introduces a third strand here, namely instrumentalists, with its own pattern of breaks, and several other practices (electrical engineers, the military)make a showing at various points in the book as well.

And the fact that breaks occur at different times in different strands, Galison claims, is a source of strength. One analogy to think of here is a brick wall: when you line up bricks, you want them overlapping rather than sitting directly on top of each other. That way, the weak points of one row are supported by the strong points of adjacent rows.

So: what does this have to do with agile? The first strands with breaks that come to mind are the TDD cycle. You don’t simultaneously write new code and new tests: instead, you write the test first, giving a break in the testing strand (manifesting itself as a red bar), and subsequently advance in the implementation strand (manifesting itself as that red bar changing to green). And then, of course, you refactor; I’m not sure yet if this is a break in a third strand or if it’s a further advance in the implementation strand. (For that matter, the refactoring can be an advance in the testing strand, as well.)

One special aspect of this example: while the strands don’t have their breaks at the same time, they have their breaks in close sequence, in a specific order. Is this a general property of best practice in interwoven traditions? I tend to think not; having said that, it doesn’t seem all that unnatural to me for breaks in one tradition to be followed reasonably closely by breaks in closely related traditions. So perhaps if you measure this with a sufficiently coarse granularity, these breaks look simultaneous, giving rise to the paradigm shift idea; I’m not sure.

Another example from the agile realm: iterations. Here we have breaks in the implementation, in the testing, and in the customer requests. And they’re all supposed to happen at the same time! Which looks dubious from Galison’s point of view; does that mean that Galison is wrong, that iterations are a bad idea, that I’m misreading him or stretching his analogy, or that these breaks aren’t in fact simultaneous?

It certainly seems likely that I’m stretching Galison’s analogy; having said that, I think you can also make a case that these breaks aren’t simultaneous. It’s not the case that Customers approach the planning meeting that kicks off an iteration with a blank mind: they’ve been thinking about what’s most important to work on next, and while they’ll certainly use feedback during the planning meeting to inform the details of what the team should do in the next iteration, there’s not a split in the Customer practice right before the planning meeting. And there isn’t one right after the planning meeting, either: the Customer has to spend a fair amount of time at the start of the iteration helping the rest of the team understand what that iteration’s stories means. And breaks in the testing and implementation strands don’t happen simultaneously in this example any more than they do in the TDD example.

This last case, in fact, brings us to the second point of Galison’s chapter. The chapter is titled “The Trading Zone: Coordinating Action and Belief”, and he claims that these “adjacent” strands can’t naturally talk to each other without misunderstandings. Instead, members of different strands have to work quite hard to find a way to work together that allows the two strands to learn from each other, to find a common way forward that advances both of their interests. (C.f. Star and Griesemer’s notion of boundary objects, which Galison comments favorably on in a note on page 47.) To do this, the parties develop pidgins or creoles; these languages aren’t enough to allow complete understanding between the two sides, but they are enough to let both sides agree on some amount of focused exchange.

I particularly enjoyed the example that Galison gave on pp. 820–827 of a pidgin language developed during World War II to allow theoretical physicists and electrical engineers to discuss the construction of radar and microwave devices using circuit diagrams. Returning to our programming examples: while, in the TDD case, there’s relatively little scope for misunderstanding (since the same people are doing the testing and the implementing!), we can nonetheless see unit tests as a pidgin language (or perhaps more of a creole) in this case. In fact, maybe that’s exactly the strength of unit testing: forcing a creole language into the situation sets up an explicit trading zone where one would have only been latent without that language, and in doing so it makes you aware of the split betwen the latent testing and implementing strands, increasing the strength of your work. The example of Customers, testers, and implementers working together is more clear-cut: agile suggests that the three groups spend quite a bit of time talking together, and acceptance tests give an example of a pidgin language that they can use to coordinate their activities.

And, as with the second agile example, Galison suggests reinforcing these trading zones with a shared physical space, to increase the chances that active trading will happen. The physical layout of the MIT Radiation Lab was designed to increase the amount of chatter between different groups; he gives examples of areas in later buildings designed to support particle physics research that are intended to increase the chances that members from different specialties will spend time together.

Though one aspect of agile practice that Galison’s text, to me, doesn’t clearly support is an erasing of boundaries: Galison seems happy to have these specialties to remain largely distinct, whereas the agile ideal is the concept of generalizing specialist. Or at least that’s the agile idea in the context of implementation; agile draws a particularly bright boundary between the business and implementation sides. (Though the lean tradition prefers to create an explicit bridge there in the person of the Chief Engineer.) Galison’s book is full of examples of fertile cross-pollination between disciplines, and even of individuals moving between disciplines (from meteorology to particle physics!), but the disciplines nonetheless retain their own individual character.

What should agile learn from this latter difference? I can think of two arguments in favor of breaking down such boundaries in the agile tradition: one is that it increases knowledge sharing (and the fertilization that results), and the other is that it increases resource flexibility. Galison certainly agrees with the former, but, as we’ve seen above, provides other mechanisms by which it can occur. He doesn’t, as far as I’m aware, address the latter; certainly something for me to think about in the future.

It’s an excellent book. I’ve only discussed the last chapter here, but I really enjoyed the more historical sections that preceded it. Great stories, great pictures, I found something new and interesting in every section.