Over on the XP list, Bob Hath­away points to a recent col­umn on pair pro­gram­ming by Matt Stephens, self-​​styled “agile icon­o­clast”.

I posted a draft of this on the list, but think it might go a bit far­ther in the con­text of some other work I’m doing.…

First, the inno­cent reader should real­ize that what’s being dis­cussed here is “pair pro­gram­ming”, a core prac­tice in the Extreme Pro­gram­ming soft­ware devel­op­ment method­ol­ogy, and in many other agile devel­op­ment approaches. But clearly Stephens has an issue not merely with the sin­gle prac­tice, but with the under­ly­ing man­age­ment philosophy.

The con­tent and tone of the arti­cle reminds me of a lot of the teen-​​blogging I’ve encoun­tered on Xanga or MySpace. It pro­vides a lot more psy­cho­log­i­cal and soci­o­log­i­cal insight about the author — and his affected audi­ence — than I think he intended. Dig down through the BO-​​radiating garlic-​​eating pro­gram­mer prej­u­dices. If you grit your teeth and think about it, it could be seen a very inter­est­ing cul­tural artifact.

My first reac­tion? “Never, ever hire this guy or his bud­dies.” Ever.

But it does make you think.

I won­der if I’m hear­ing a deep assump­tion in this piece: that soft­ware projects are only for mak­ing prod­ucts. The cus­tomer only ben­e­fits from being given what they ask for; a team is hired only on the basis of the speed and accu­racy with which they pro­gram; the devel­op­ers are expected to develop them­selves only on their own time. In other words: learn­ing is not busi­ness value. The cus­tomer shouldn’t be both­ered to learn or adapt or par­tic­i­pate in the devel­op­ment process, as they must in all XP projects. And the “pro­gram­mers” shouldn’t slow down their typ­ing to learn and chat and dis­cuss anything.

Stephens is clearly not some­body you want to chat or dis­cuss any­thing with. But that’s OK. I don’t have to. What I do have to do, as a project man­ager, is obtain value. He’s demon­strated, among other things, that the only value he can pro­vide is from being used as an example.

So Stephens assumes value only comes from “smart peo­ple” typ­ing, and that any amount of talk­ing slows down those good typ­ists. Unless you’re tran­scrib­ing books, this proves to be really stu­pid fal­lacy… but a philo­soph­i­cally inter­est­ing one. In a way, it implies that learn­ing behav­ior shouldn’t hap­pen because it’s not adding value to the project, but shunt­ing value to the team. They’re talk­ing, they’re learn­ing, they’re slow­ing down their “productivity”.

Call it “steal­ing” value from the customer.

Now by apply­ing such an assump­tion to the XP process, Stephens and his ilk demon­strate a fun­da­men­tal lack of under­stand­ing. Not just of XP (which he’s clearly never done), but also of com­plex project-​​based soft­ware devel­op­ment work, project man­age­ment… and frankly even programming.

One of the fun­da­men­tal notions in XP projects is the prac­tice of break­ing the customer’s goals into lin­early decom­pos­able chunks, small enough so that every­body (cus­tomer and team) can under­stand and eval­u­ate them inde­pen­dently, but large enough so that each one pro­vides busi­ness value when delivered.

In a way, this is also a myth of sorts. In divid­ing com­plex and inevitably non­lin­ear projects into small sto­ries we treat as lin­early decom­pos­able bits of busi­ness value, we simul­ta­ne­ously shunt all the link­ing non­lin­ear­ity and com­plex­ity into the social struc­ture and dynam­ics of the team. Work­ing with the cus­tomer, we clar­ify what’s wanted and needed, but in doing so we man­age the depen­den­cies and com­plex­ity on the social side.

You talk about it.

That’s why XP’s prac­tices and val­ues of pair pro­gram­ming, shared code own­er­ship, uni­ver­sal test cov­er­age, and all the rest are so cru­cial. They forge the col­lec­tive learn­ing sys­tem in the team, which sup­ports the mirac­u­lous decom­po­si­tion of the customer’s dif­fi­cult project into a pile of appar­ently uncon­nected sto­ries. The process allows the cus­tomer to make imme­di­ate progress — and to max­i­mize the impact of the first small step — exactly by mask­ing all the dif­fi­cult wiring inside the devel­op­ment team’s heads, the code they write, and test base. And most of all, in the ongo­ing conversations.

I’m will­ing to agree with the author that, “Not every­one is nat­u­rally extro­verted or a social but­ter­fly that will wither away if he doesn’t get to chat­ter to his col­leagues 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 col­leagues in a pub­lic forum than chat with them directly).

But see… if he man­aged to actu­ally start work­ing on an XP team, and stopped talk­ing and pair­ing and nat­ter­ing away they day, and instead picked out work he thought was use­ful to the cus­tomer with­out con­sult­ing them, and went off alone and typed shit in, and in the end every­body had to deal with the mess he’s made… in that case he is the per­son steal­ing value. He has rein­tro­duced all that com­plex­ity; he’s under­mined its stor­age in the team; he’s mak­ing it harder for the client to choose incre­men­tal value; he’s keep­ing secrets and mak­ing him­self an obsta­cle, with his own self-​​centered uncom­mu­nica­tive block­ish head.

And thus he threat­ens that project’s success.

He’s off the team. Implic­itly, when he fails to col­lab­o­rate and obstructs col­lec­tive work. Explic­itly, when it becomes apparent.

Ten ideas about Ideas, from Doc Searls. Absolutely cru­cial advice for life in Mod­ern Times, in domains quite dis­tant from mere soft­ware development.

Sad I haven’t seen them before today. But now we all have.

Dorothea at Caveat Lec­tor trans­lates from the AAP’s response to the Nature exposé:

And hey, we may be stum­ble­bum slimepup­pies, but we’ve been stum­ble­bum slimepup­pies for decades! Nay, cen­turies! You can’t want to get rid of us now! After all, nobody pro­tected the pen­ny­far­thing bicy­cle, and just look what hap­pened! You don’t want that on your con­science, do you?