You’ve got to stuff all that nonlinearity somewhere…

Over on the Yahoo! Extreme Programming mailing list, Bob Hathaway points to a recent column on pair programming by Matt Stephens, self-styled “agile iconoclast”.

I posted a draft of this on the list, but think it might go a bit farther in the context of some other work I’m doing….

First, the innocent reader should realize that what’s being discussed here is “pair programming”, a core practice in the Extreme Programming software development methodology, and in many other agile development approaches. But clearly Stephens has an issue not merely with the single practice, but with the underlying management philosophy.

The content and tone of the article reminds me of a lot of the teen-blogging I’ve encountered on Xanga or MySpace. It provides a lot more psychological and sociological insight about the author—and his affected audience—than I think he intended. Dig down through the BO-radiating garlic-eating programmer prejudices. If you grit your teeth and think about it, it could be seen a very interesting cultural artifact.

My first reaction? “Never, ever hire this guy or his buddies.” Ever.

But it does make you think.

I wonder if I’m hearing a deep assumption in this piece: that software projects are only for making products. The customer only benefits from being given what they ask for; a team is hired only on the basis of the speed and accuracy with which they program; the developers are expected to develop themselves only on their own time. In other words: learning is not business value. The customer shouldn’t be bothered to learn or adapt or participate in the development process, as they must in all XP projects. And the “programmers” shouldn’t slow down their typing to learn and chat and discuss anything.

Stephens is clearly not somebody you want to chat or discuss anything with. But that’s OK. I don’t have to. What I do have to do, as a project manager, is obtain value. He’s demonstrated, among other things, that the only value he can provide is from being used as an example.

So Stephens assumes value only comes from “smart people” typing, and that any amount of talking slows down those good typists. Unless you’re transcribing books, this proves to be really stupid fallacy… but a philosophically interesting one. In a way, it implies that learning behavior shouldn’t happen because it’s not adding value to the project, but shunting value to the team. They’re talking, they’re learning, they’re slowing down their “productivity”.

Call it “stealing” value from the customer.

Now by applying such an assumption to the XP process, Stephens and his ilk demonstrate a fundamental lack of understanding. Not just of XP (which he’s clearly never done), but also of complex project-based software development work, project management… and frankly even programming.

One of the fundamental notions in XP projects is the practice of breaking the customer’s goals into linearly decomposable chunks, small enough so that everybody (customer and team) can understand and evaluate them independently, but large enough so that each one provides business value when delivered.

In a way, this is also a myth of sorts. In dividing complex and inevitably nonlinear projects into small stories we treat as linearly decomposable bits of business value, we simultaneously shunt all the linking nonlinearity and complexity into the social structure and dynamics of the team. Working with the customer, we clarify what’s wanted and needed, but in doing so we manage the dependencies and complexity on the social side.

You talk about it.

That’s why XP’s practices and values of pair programming, shared code ownership, universal test coverage, and all the rest are so crucial. They forge the collective learning system in the team, which supports the miraculous decomposition of the customer’s difficult project into a pile of apparently unconnected stories. The process allows the customer to make immediate progress—and to maximize the impact of the first small step—exactly by masking all the difficult wiring inside the development team’s heads, the code they write, and test base. And most of all, in the ongoing conversations.

I’m willing to agree with the author that, “Not everyone is naturally extroverted or a social butterfly that will wither away if he doesn’t get to chatter to his colleagues for eight hours a day.” He’s clearly one of those non-butterfly folks (not least because he’d rather write about his BO-stinking colleagues in a public forum than chat with them directly).

But see… if he managed to actually start working on an XP team, and stopped talking and pairing and nattering away they day, and instead picked out work he thought was useful to the customer without consulting them, and went off alone and typed shit in, and in the end everybody had to deal with the mess he’s made… in that case he is the person stealing value. He has reintroduced all that complexity; he’s undermined its storage in the team; he’s making it harder for the client to choose incremental value; he’s keeping secrets and making himself an obstacle, with his own self-centered uncommunicative blockish head.

And thus he threatens that project’s success.

He’s off the team. Implicitly, when he fails to collaborate and obstructs collective work. Explicitly, when it becomes apparent.