Brainstorming and Pair-Programming

While Vladimir Drndarski and I were pair-programming today, the following conversation ensued:

Vlad: "That's a bad design."
Craig: "Only because we are testing it."

I'll leave the circumstances to your imagination, although I assure you that I was serious at first, before I realized the absurdity of what I had said. Well, we both cracked up. Then, needless to say, we changed our tack. Chalk up another victory for pair-programming.

On a related note, Jim Powell, a colleague of mine, gave a presentation yesterday about brainstorming techniques. For example, he talked about how an initial pool of ideas can be built up in the generation phase by pushing the boundaries, piggy-backing on the previous ideas, and inverting or negating the previous ideas. (More on that in a moment.) Afterwards, it occurred to me that one of the reasons pair-programming works so well is that it basically amounts to an endless stream of mini-brainstorms between the two partners. I don’t have any objective proof, but I swear that whenever I pair with someone, we’ll write code that is easily 3-4 times tighter and cleaner that if I had written it alone. I'm sure the brainstorming aspect has a lot to do with why.

Regarding idea generation via negation, I will never forget the first time I tried it. I was using a technique called “20 Answers” which is essentially a way to do a brainstorm single-handedly. I started with a blank piece of paper and wrote my question at the top, “How can I get this bleepin’ report-printing framework to fill in the calculated totals I need on the cover sheet at the beginning of the report, even though the figures to be totaled haven’t been processed yet?” (That was back in my C/PM days, and the tool I was using didn’t know how to make a preview pass when generating a report.) Some of the possible answers that immediately came to mind were:

1. Somehow pre-calculate the totals
2. Write a post-processor to fix up the cover page
3. Bypass the framework and write the whole report in Print statements

But they were obviously too complicated. So, I loosened the constraints and brainstormed some more...

8. Find another framework and rewrite the whole app
9. Write my own framework from scratch

Of course, those were even more complicated. Eventually, I started getting really silly and downright contrarian. I thought to myself, what if I don’t try to answer the question at all? Or that I only answer part of the question? That generated a few more possibilities...

15. Perhaps I could convince the customer that they don’t really need the totals on the cover sheet?
16. Perhaps they’d settle for a summary page at the end instead of a cover sheet in front?

And then it finally hit me. Who says the cover sheet has to actually come out of the printer first? Thus:

19. Print a summary sheet at the end that looks like a cover page and have the clerk move that page to the front before mailing the report.

Walla! I had struggled with that problem for a few days before I brought out the "big guns" and went through the 20-Answers exercise. It’s true what they say about the power of getting things down on paper to stop the mental "looping." But disciplined brainstorming like that isn’t something that comes naturally to a single individual, at least not to me. When I’m pairing, however, it does happen naturally -- and constantly. It's just part of the conversation.

I’ve been pair-programming on and off for a few years now, and the more I practice it, the better my work gets. What’s your experience? Write me.