When pair programmers go home for the night, they leave behind software and documentation—these are persistent artifacts. Persistent, meaning it lasts longer than the process that created it; an artifact being something with inherent value or purpose.
Persistent artifacts can be found everywhere in business. Products, for example. Shoes. Watches. Chopsticks. I’m not going to claim that pair processes work best for building all products … but they do work pretty darned well for written products.
What kinds of written products do you produce in your day to day life? Notes jotted down and kept in your pocket, casual e-mails sent to friends and coworkers, presentation outlines, meeting minutes, proposals, memos … even software.
We do a lot of writing. Of course, not all of it is well suited for pairing—things like your thank you note to Aunt Mildred, or personal notes from the morning standup meeting.
On the other hand, things like marketing copy, sales proposals, and software—these are substantive things that represent your team (business, division, etc.). They require attention to quality, and their content frequently crosses boundaries.
Lets take the example of a project bid—something I actually have to deliver this afternoon.
Now, theoretically I could just write something up, e-mail it to Jeremy for technical approval, wait for his feedback, incorporate his estimates and adjustments, then send it out.
But, dangit, theory just doesn’t match up with reality. Jeremy will see some flaws or opportunities and ask a few questions. I’ll respond in kind, but he’ll be heads-down on a project. He’ll eventually come back with his response, but I’ll be knee deep in other correspondance. The cycle repeats. You get the idea. We’ll get the job done, but these are the kinds of patterns that contribute to continuous partial attention and missed opportunities.
What’s the pairing approach?
Jeremy and I reserve time in the conference room1. I bring my laptop, he shows up empty handed. We spend a couple of minutes reviewing the client notes on Basecamp and then we hash out an outline for the bid. I type; he looks over my shoulder and helps navigate. Technical and client questions can be instantly answered (or at least identified as open), mistakes are caught (technical or otherwise), and in the end we have a bid that we’re confident in and are willing to take responsibility for.
So, where do you think paired writing could be valuable in your business?
Where do you think it’s superfluous?
Let me know!
1 We have an “open pit” development environment. I should write something about that later.