Mon, 13 Dec 2004
As I've mentioned before, I sometimes hang out with Andrew Pickering, head of the Sociology department at Illinois. We've talked about Agile methods, which match well his analytical framework for explaining scientific progress (as put forth in his fairly dense The Mangle of Practice). As a result, he invited me to write a chapter on Agile for a forthcoming book on "the mangle." I produced a draft in February. It was mostly a detailed retelling of a refactoring episode in manglish terms. Lots of Java.
As so often happens to me, the current draft is much different. Instead of being about the micro, it's about the macro: explaining Agile development to sociologists.
So far, so boring. But I decided to end with a topic that intrigues me. Agile software development is not "businesslike". You've got a room full of programmers yammering to each other. And let's be frank: that room is messy. There's food all over the place. Maybe toys. Tables with 3x5 cards lying on them, programmers pushing them around like game pieces. Crude, childlike graphs on the wall.
Since at least the '60's, business has been successfully domesticating programmers, and all that progress seems to have been lost. There's even a company where the dress code calls for ties, and the programmers on the Agile team have been given a waiver. That's the first step to the harder stuff. What now will prevent all that California-style New Age babbling about 'emergent design' from leading to web sites describing which crystals are best for writing PHP code? And office water coolers filled with "energy water"?
I exaggerate. A bit. But the style and many of the beliefs of Agile development do not mesh well with what's traditionally thought of as the proper business workplace and practices. So why is it that I run into business people who love their Agile teams? What is it that those teams are doing right?
Is it just that Agile projects deliver better ROI? I certainly hope they do, but that claim isn't proven. And I don't think it accounts for the distinct emotional response I've seen. And, in any case, those concerned with ROI are no more dispassionate utility maximizers than the average hairless ape, so there must be more to the success of Agile.
Not that it's always successful. We so often hear the sad tale of a new VP coming into an Agile shop and destroying the Agile teams, typically for reasons that seem (to us) raw prejudice. Perhaps the reasons why some teams sell themselves well can help those teams that don't.
Pages 8-10 of my paper give those reasons, so far as I understand them. But I could be wrong. And I've probably overlooked or incorrectly discounted some. So I'd truly appreciate reviews, which you can send to email@example.com. I have both a PDF of the chapter and a Word version in case you want to put comments in the text. (Sorry, RTF users: Word mangles the document when it exports it to RTF.)
I'd also appreciate comments on my description of Agility. I do use manglish jargon in that description, but in a way that I hope will still be meaningful for people who haven't read Pickering. (And I've also previously posted a description of the key terms.)
(And I have a guilty feeling that I'm being unfair to Parnas and Clements in my description of their "A rational design process: how and why to fake it." If you think I am, let me know.)
Fri, 05 Mar 2004
Faithful readers of this blog category will remember that I'm writing a paper applying Andrew Pickering's The Mangle of Practice to agile methods.
I had hoped that I might use the paper both for a seminar Pickering's running and as a submission to Agile Development Conference. I gave up on the latter idea a couple of weeks ago - I couldn't think of a slant that seemed at all likely to get accepted.
I have finished a draft. It kind of got out of control, partly because I'm rushing to fill in a last-minute gap in the seminar schedule. Partly it's that I'm trying to do way too much in the paper.
Here's the abstract:
The paper is in three parts. The first is a rather long story of a refactoring. It's not momentously different than every other story of refactoring you've read: I notice code smells, I change the code, I'm sometimes surprised by where I end up. The only two novelties are that the refactoring happens after I make a FIT test pass, and that I'm coding in the FIT-first style where you write the test-passing code in the fixture and pull out domain objects a bit at a time.
After that I look at the differences between my story and Pickering's story of Hamilton's discovery of quaternions. Where Pickering talks about the world resisting human effort, I talk about the world alternately pushing me around and attracting me.
Finally, I suggest that all this talk about "what the world is doing" isn't purely idle. The Agile worldview ("ontology") is built up through experience and it affects practice. If you believe software can be soft if only you approach it right, you're more likely to figure out how to approach it right. If you believe that software is inevitably ruled by entropy, then you concentrate your effort on damping entropy. That is, I don't believe that methodologies are inherently either right or wrong; I believe they're made right by people who believe in them.
That section closes with a wild speculation: we wouldn't be where we are today if Smalltalk hadn't failed. Its failure led a bunch of bright people to a new place, the one place Smalltalk had a significant toehold: IT. That very different context forced them to invent. (Because of my deadline, I didn't have time to have the people who were actually there explain to me how completely bogus this idea is... but I'm going to be talking to them soon. After all, it's only a draft, so why not go wild, then backtrack?)
I have no real idea who my intended audience could be (other than a bunch of sociology and history majors just dying to learn about Factory Method and Composed Method). But if you're one of them, I would indeed like to hear your comments.
Here's the draft. Since the only readers I know I'll have are nonprogrammers who've read Pickering's book, I define programming jargon and not Pickeringish jargon. You can find enough explanation (I hope) in earlier postings here and here.
Wed, 25 Feb 2004
While I'm on an anti-definition kick, let me quote William James's story of the squirrel:
That's from his second lecture on Pragmatism (and I'm so glad James died before Mickey Mouse was born, so that I can link to the whole thing).
When I get involved in definitional debates, I often think of James's pragmatic method, which is to ask:
What difference would it practically make to any one if this notion rather than that notion were true? If no practical difference whatever can be traced, then the alternatives mean practically the same thing, and all dispute is idle. Whenever a dispute is serious, we ought to be able to show some practical difference that must follow from one side or the other's being right.
Quite often, there is a practical difference. Then, if I'm lucky, I can focus on which practical difference people want, thus sneaking away from arguing about the definition.
Tue, 24 Feb 2004
I've long been fascinated by the notion of incommensurability. It's a term in science studies made popular (sic) by Kuhn's Structure of Scientific Revolutions and Feyerabend's Against Method. Two theories are incommensurable if neither can be fully stated in the vocabulary of the other. Feyerabend argued that incommensurability means that we have no rational (context-independent) way of judging between rival theories.
Terminology can also be incommensurable, since theories are built from terminology (and vice versa). A good example is "velocity". When Galileo was arguing with the Aristotelians about his new world view, both sides used the word "velocity". But Galileo meant something like what we today call "instantaneous velocity", and the Aristotelians meant something like what we call "average velocity". So if they both watched the same experiment they would likely get different answers to the question "What's the ball's velocity?" We can, with hindsight, say they ought to define their terms better. But that's part of the problem. They could define velocity in terms of motion, but "motion" also meant something different to an Aristotelian. A theory of motion must necessarily say something about growth, since the growth of a tree is the same phenomenon as the falling of a ball. And what exactly is the point of a theory of falling balls that can't even begin to explain why fire rises? - the Aristotelian theory could.
You can see a conversation going nowhere.
Kuhn writes (at least tentatively) as if such conversations must go nowhere. People with incommensurable theories live in different worlds. It's as if they have different perceptions. Incommensurability is a gulf that can't be bridged by talk or definitions, only by experience (what Kuhn likens to a gestalt shift).
Because of incommensurability, I accept frustration when communicating between the agile and non-agile worlds. Words like "test" and "design" come freighted with different world views. That's one of the reasons I've tried to talk about tests as "checked examples". Maybe if we use different words, talk will be easier.
But wait - it gets worse.
Last night, I read the first two chapters of Esther-Mirjam Sent's The Evolving Rationality of Rational Expectations: An Assessment of Thomas Sargent's Achievements for a seminar I'm sitting in on. Given that I have nowhere near the economics background the book assumes, I can only give a thumbnail sketch. There was this economist, Sargent. He worked on something called "rational expectations" for many years. Rational expectations holds that people's predictions don't err systematically. They err randomly. That assumption has all sorts of consequences, none of which I understand.
What struck me on page 19 was this sentence: "Sargent's different interpretations of rational expectations were temporally specific." Although that's vaguely worded enough that I'm not sure what Sent was thinking, it made me think this: It's likely that Sargent would say all along that he was working on a single thing named "rational expectations," but what he meant by that term changed over time.
So imagine: not only do Galileo and the Aristotelians face an incommensurability barrier, the Aristotelians have to track the changing connotations and denotations of "velocity". We, today, can say Galileo was always talking about instantaneous velocity, just getting ever better at figuring out what that meant. But that's probably not at all what the story looks like from the inside as it happens, even if it looks like that to Galileo after the fact (since Galileo is doubtless as good at telling stories to himself as we are at telling stories about him).
It's a wonder we can communicate at all about important things. That we do, I humbly submit, has a lot to do with talking about examples, not about definitions. And, perhaps more important, with doing things together. And with imagining what it would be like to do things like someone else does them.
Fri, 13 Feb 2004
In this essay, I'll describe Pickering's notion of "disciplinary agency". I'll use the same mathematical example Pickering uses. In the next essay, I'll use a coding example I stumbled over while happily hacking on the plane to San Francisco. My hope is that Pickering's notion gives some insight into the semi-common idea that "the code is telling us where it wants to go".
Let's define agency as "the capacity to do things". People have agency. I use my agency to write this essay. You have the ability - the agency - to read it or to turn aside.
Generally, we think of agency as being something that humans have. In his book, Pickering proposes that it's useful to think of nonhumans as having agency. For example, in an experiment a scientist creates a machine, turns it on, and watches it. While creating it, the scientist is exhibiting agency. But when watching the machine, the scientist is passive while the machine does whatever it is that it does. We can say the machine exhibits material agency. It's no longer manipulated by the human; instead, it's in control while the human sits back.
Another type of agency is disciplinary agency, in which a human gives up control to a routine way of reacting to patterns in the world. We can say that that routine has agency. It has the ability to do things in the world that the human doesn't expect, that the human can only observe and then react to.
This pattern of humans exercising agency, then sitting back and watching while something else exercises agency, Pickering rather fancifully calls the dance of agency. He claims it's a common pattern in intellectual practice.
as a case study. In the 1800's, mathematicians
had established a correspondence between algebraic equations involving
imaginary numbers, like
That's fine for two dimensions. What a mathematician named Hamilton
wanted to do was figure out how to link algebra and geometry in three
dimensions. How can we talk about a point
Hamilton first modeled 3D after 2D. If a point
That's fine, but does it work? One way to tell is to repeat what you already know how to do in the new context. That is, you apply - rotely - a discipline you already know. Hamilton knew the rules for algebra, so he started manipulating equations and seeing if the results corresponded to any sensible extrapolation (from 2-space to 3-space) of multiplying two vectors.
A first thing he did was consider the square of a point in
3-space. According to the normal rules of algebra, the square of
This is an example of disciplinary agency. Having decided on his
representation, Hamilton had no choice about how to proceed: the
rules of algebra controlled, and they produced the result that they
produced. Everything is straightforward, except there is a bit of a
question: what does
Now Hamilton turned to geometry. He needed to extrapolate the rules for 2D into 3D, keeping fixed the idea that multiplication means multiplying lengths and adding angles. A problem arises in adding angles. When you square, there are multiple points that satisfy the addition constraint. Which to choose? Hamilton chose the one that lay on the plane connecting the original point and the x-axis.
Hamilton has here taken back agency from the discipline of algebra. But once, he makes his decision, he surrenders again to the discipline of geometry. You can now square a point and, moreover, translate the result back into algebraic notation:
Since this formula and the previous one represent the same point (just gotten at by two different disciplines of multiplication), we know that:
Having given discipline free reign to get this result, Hamilton entertained two possibilities. The first was
I'll cut the story short here. The abbreviated version is that he
assumed either possibility held and kept multiplying. This time he multiplied
two different points rather than squaring the same point. He ran
problem that required him to accept that
So we see a pattern:
That's a dance of agency.
Sat, 07 Feb 2004
The book is about how practice - doing things - causes change to happen in science and technology.
When you do things, you do things to things. You tweak, twiddle, or frob them. Pickering is concerned with a wide range of "the made things of science", a category that includes machines and instruments, scientific facts and theories, skills, social relations, rules of evidence, and so on. Part of his point is that scientists who do things put every thing in science up for grabs, up for revision. For example, one response to a line of enquiry that isn't fitting the rules is to change the rules. (Echoes of Feyerabend here.)
Pickering claims that you can see a regular pattern in the change of science. People start with some goal - to create another "made thing", be it a mathematical theory or a bubble chamber. They model their goal after some existing made thing. A theory of the three-dimensional correspondence between algebra and geometry is modeled on the existing two-dimensional correspondence. The bubble chamber is modeled on the cloud chamber.
In the course of moving toward the goal, people encounter resistance. It's not just people pushing at the world (broadly construed); it's the world pushing back. That sounds pretty trivial, but Pickering is asking us to take Kent Beck seriously when he says (as he does in Smalltalk Best Practice Patterns), "Since the code seems to be telling us to do this, let's try it." (p. 3)
Resistance is accommodated by adjusting any of the made things available. Sometimes the accommodations work; sometimes they don't. You have to keep on trying. Here's a picture I drew of how change happens. The big blob is the made things you start from. The little blobs are tentative extensions. They keep hitting resistance, in the form of the T shapes. The blobs change color to show that the extensions are flexible - they are not where you were planning on going when you started. The final location is a funny shape to suggest that you should expect to get somewhere unexpected.
Pickering emphasizes the role of chance, the degree to which your choices are dictated by the specific resistances you encounter. Those resistances are not predictable in advance. This undercuts the feeling of the inevitable progress of science; it gives more of a role for the accidents of history. For example, Pickering allows for a chemistry as competent as ours - as capable of doing things in the world - that never happened to come up with the periodic table of the elements.
That's a pretty scary notion when it comes to science. Can it be the periodic table isn't real? It's interesting that I read an article in Science News about some specialist (geophysicist, I think) who'd created a completely different periodic table. Elements appear in more than one place, for example, because that makes sense for his field. One could get into long arguments about which of the two tables is more true to nature, but I'm not gonna. One could speculate that a world in which geophysics was more important than chemistry would have invented his table first and maybe never bothered with Mendeleev's - but I'm not gonna do that either.
I'm not going to because I'm a crass pragmatist, mostly interested in building software and in the evolution of agile methods. For software projects, chance and history so clearly play a role that you won't get embroiled in the equivalent of the science wars for saying "the feature set of Microsoft Word was not inevitable". I even hope that, in my paper, I'll be able to say that the composition of Extreme Programming isn't inevitable - that its state today depends on chance happenings at Xerox PARC, Tektronix, University of Oregon, Chrysler, and Ward Cunningham's office (where one day he decided to make a wiki).
So when does this process of change stop? When do you say you have a bubble chamber, quaternions, the periodic table of the elements, the methodology called Extreme Programming? It changes when good enough associations are made between distinct made things in the culture. "Good enough" means those things serve to stabilize each other. For example, in Morpurgo's search for free quarks, he worked until he had a machine that produced consistent effects, and he could explain those effects with a theory of how the machine worked, and the effects supported one of two theories about free quarks. His changing machine, his changing theory of apparatus, and a preexisting theory of quarks hung together.
(For a related take on how change stops, see actor network theory.)
Tue, 27 Jan 2004
I'm sitting in on a sociology of science seminar at the University of Illinois. It's about Andrew Pickering's The Mangle of Practice: Time, Agency, and Science. The idea is that participants will write a paper that may be included in an edited volume of follow-ons to Pickering's book.
I'll be using this blog category to summarize Pickering's ideas as a way of getting them clear in my mind. The basic idea is one of emergence, that novelty and change arise from collisions. A scientific fact might arise from the collision of a theory of the world, a theory of instrumentation, and the brute fact of what the instrument does when you use it. A mathematical fact might arise from bashing together algebra and geometry in an attempt to achieve certain goals.
What attracts me to Pickering's work is what attracts me to the agile methods: an emphasis on practice, on doing things in the world; the idea that the end result is unpredictable and emergent; the idea that everything is up for grabs, up for revision, including the goals you started with; and a preference for the boundaries of fields over their purest forms.
The paper I'm thinking of writing is "The Mangling of Programming Practice from Smalltalk-80 to Extreme Programming". I think it's fairly well-known that the agile methodologists were disproportionately involved in Smalltalk and patterns way back when. What was the trajectory from Kent Beck's and Ward Cunningham's early days at Tektronix to the development of XP as it is today? It's a historical oddity that Smalltalk found a niche in the IT/insurance/business world. What was the effect of bashing the untidiness and illogicality of that world against the elegance of "all objects, all the time"? We see CRC cards being described in 1989. Today, the 3x5 card is practically a totem of XP. So is colocation, big visible charts, and so forth. Here we see an ever-increasing recognition of how the material world interacts with what is so easy to think of as a purely conceptual world. What's going on? Etc.
Does Pickering's account of change shed any light on how we got from Xerox PARC to where we are today? And, more important to my mind, does it give us any ideas about where we really are and how we might proceed?