≡ Menu
Pawel Brodzinski on Software Project Management

Pair Document Writing

Pair Document Writing post image

Recently I took part in panel discussion on DVCS where my introduction ended up with “my last check-in happened in 2003.” So yes, now I’m “programming” in Outlook and Word. In Excel if I’m lucky. It doesn’t make me some sort of expert in terms of discussing pair programming, does it?

When we are at pair programming I confess I was never a fan of this practice. It somehow feels unintuitive. I actually do believe wise folks like Ron Jeffries, Corey Haines and Yoda who tell us it does work, but it’s kind of thinking “Well, for Yoda even a lightsaber works pretty damn well and I could only hurt myself with the thing.”

Anyway, I remained skeptical for a longer time, especially that none of my teams have ever seriously introduced pair programming. Recently Corey Haines made me thinking about it from a bit different angle when he told on ACE Conference that pair programming is like an instant code review. I must admit it kind of speaks to me.

The next thing which added some doubts was my recent experience which isn’t really programming-related. After all, you already know my last check-in was when people I now hire were still in kindergarten. Recently I’m often working on different documents pairing with different people. It doesn’t really matter what these documents are all about but if you tell “appraisal system” in my neighborhood I’ll make you suffer.

We’re usually trying to write something creative and, while working in pair, it works surprisingly well. Technically it’s like pair programming – one keyboard, one monitor and a couple of people switching roles occasionally: one is writing and another one is reading, commenting and asking “What the hell have you meant by that?”

One interesting thing which happens is the flow. As long as both people are focused on a document writing goes pretty smoothly – either I have an idea what’s next or you’re just telling me what’s on your mind. Also there are quite a lot of discussions about what exactly we want to describe at a specific point so we kind of cut feedback loop down to the least possible size. But here’s the best part: whenever, for any reason, someone goes out of the room, productivity falls flat on its face like instantly. Whenever I was the one who stayed it was as if someone has just turned struggle mode on. And then, when we were back in the pair, after a while we were reaching the flow again pretty quickly.

Another thing is even more interesting. After a couple of such sessions when I thanked the person who I paired with telling how much they helped me I heard as a response: “Well, it was you who did the work, I was just sitting there and commenting from time to time.” I was all like “Are you insane? What on Earth are you talking about? If not you I wouldn’t get even one fifth of this stuff in that time and it would be sort of crappy anyway.” In short, both of us thought it was the other one who did most of the work, which was quite funny.

Now a question: does it differ that much from writing code?

If asked, I wouldn’t say that pair document writing would yield such good results. Unless we tried it, that is. Now, I can hardly imagine we could have done it differently.

Of course it isn’t the best solution in every single case but the longer I think about it the more situations fit pair writing approach. I’m definitely going to do pair document writing more often.

And maybe it’s time to try pair programming in some teams as chances are it would show similarly unintuitive and similarly good results.

in: communication, software development

9 comments… add one

  • Mike Cohn April 22, 2011, 6:19 pm

    Interesting post (as always), Pawel.

    But if you’re going to do pair document writing, be sure to use WordUnit for testing: http://www.waterfall2006.com/beck.html

  • Pawel Brodzinski April 23, 2011, 12:32 am

    Damn it! I didn’t know Kent Beck jumped on waterfall bandwagon ;) It looks it’s time to change my views as well ;)

  • Peter Z April 23, 2011, 2:37 am

    Pair document writing works great for me. I use it usually when writing business proposals or important sensitive email.

    I’d say working in pairs on documents (or code) depends a lot on personality. There are people that need to bounce often their ideas with someone. And there are people who prefer to think and work alone. As you mentioned, Pawel, in post about human resources, people should be dealed with individually, if possible.

  • Pawel Brodzinski April 23, 2011, 2:45 am

    @Peter, Yes, of course people should be treated individually but I was doing pair document writing with quite a different folks recently and is somehow always worked great.

    I’d say that in such practices it is more important what you’re working on and not who you’re working with. Actually I can think of pretty few people who I wouldn’t like to pair write with. And it is actually almost the same group I wouldn’t like to work with at all.

  • Bartosz Rakowski April 26, 2011, 5:02 am

    Pair programming is (not suprisingly) very similiar. Do not let the myths about it fool you. There are legends about decreasing productivity and tales of things you can not pair-do.
    Yeah, not all the legends and tales are made up, but what suprised me the most is:
    “… that none of my teams have ever seriously introduced pair programming …”
    because I thought you tried all the tricks already.

  • Pawel Brodzinski April 26, 2011, 12:51 pm

    @Bartosz, First, of I haven’t tried everything. Second, even if I did the specific choice of tools would depend on a situation heavily.

    Anyway, with pair programming personally I was never a strong proponent of the practice and I never worked with team which was determined enough to try it on their own, even though my teams generally have much freedom in terms of choosing their tools.

    Btw: you’d be surprised how many things I haven’t yet tried.

  • Anonymous Coward April 26, 2011, 2:54 pm

    A related idea is the Cardboard Programmer, which I slightly prefer. I think the real gain from pair programming has the same source; you step out of thinking into code and into normal language, to explain the problem to someone else. This slight change in thinking style often reveals the solution.

  • Håkan Rudelius April 28, 2011, 7:10 am

    A friend of mine has gone one step further and invented Team documenting, he claims it’s more effective and much more fun than normal documenting!

  • craig May 3, 2011, 11:53 pm

    Pawell,

    With you 100% on this. I aspire (and often fail) to do this on anything important. It’s almost as troublesome as too much concurrent WIP.

Leave a Comment