Pair programming antipattern: discussing design
There’s a place to discuss design, but a pair programming session is not it. Pair programming is about programming. Sometimes I see developers stop typing and debating endlessly on how to do things. Sometimes, when I do pair programming (yes, I still get to do some coding sometimes) I hear my pair stopping me with objections, usually about design. “You’re going to introduce an IF!”. Yes. Definitely. I know that. But I’m not going to discuss that with you right now!
When I have a good idea of how to progress, I just do it. There’s no need to stop me to discuss my style; that will only take away energy from me. Let the code speak: if my idea is right, the pieces will fall together nicely and then we’ll decide if it’s worth introducing more design to get rid of the IF. If my idea is not so good, then the code will speak by itself. Suppose the pomodoro rings, and we realize I’m going nowhere; when we start the next pomodoro we toss my code, start afresh, and try some other way.
Maybe my pair thinks I’m going nowhere. If she’s quick enough to grab the keyboard from me, she can try another way. Let the code speak!
This does not, I repeat does not mean you should treat your pair disrespectfully. It is a completely different matter when my pair does not understand what I’m doing. It’s my responsibility to explain, with clarity and patience, what I’m trying to do. But! If my pair thinks he understand but wishes I tried some other way, then there’s two possibilities: either he will be patient and wait to see if I’m getting somewhere; or he’ll grab the keyboard from me and try another way.
There’s a place for design discussions; the best place in my opinion is in front of the whiteboard (and maybe with a cup of tea in hand.) Design discussions are good to clarify longer term goals and issues; or to explain and reason about domain difficulties. But when I’m at the keyboard, then the code is my whiteboard. Let the code speak!
The idea of “grabbing the keyboard” I learned from Francesco Cirillo (good luck trying to grab the keyboard from him!) See also his post Mamma Programming.
November 19th, 2008 at 18:31
Sacred words, thanks for giving voice to my thoughts.
As an aside, I’d like to add that, in my opinion, the process you describe requires some factors: trust in the driver, willingness to learn, humility (which clearly contrasts the typical programmer’s hubris).
I often see a mix of the two: your partner does not understand AND wishes you tried some other way. This can almost always be related to a lack of OOD skills, thus your partner is just trying to take you back to a design she knows better. This is where the teacher hidden inside you emerges (being yourself a teacher you know what I’m talking about), but only time and practice will really do the difference, and here we go back to the aforementioned factors.
Unluckily, to (partially) quote what Uberto once said in the JUG Milano Mailing list, “blockheads will never produce good gode” (I’m afraid the translation lead to an euphemistic rendering).
November 19th, 2008 at 18:34
Yes Andrea, except that I’m never going to think my pair is a blockhead. If I thought that, I would not want to work with him at all. However, I think most people can get good at programming, if they really want to and we are patient enough to share our thoughts with them.
November 20th, 2008 at 00:24
it happened me too, spending to much time arguing with the competent and passionate pair I was working with
just because we both wanted to do a good job, not even trying to demonstrate to know the better solution
what finally worked for us was to take the time to implement my idea (5-10min at the keyboard) and look together at the final result, then rollback and implement the other pair idea (another 5-10min at the keyboard) – at the end it was easy to pick up a common agreed viable solution
this not only solved the dispute, but after that we learned to wait, to look at the final result and then to comment or suggest possible improvement. and also after that the disputes decremented :)
November 20th, 2008 at 00:46
nice hint matteo.
i just want to add this: pair programming is about developing, so that there’s place for design, coding, refactoring, all done in pair.
i really like spending one pomodoro with paper and a pen, discussing designs – ways of doing. but (and this is what you’re saying), as soon as the pair decide to give a design a try, there should be no more discussions: let the code speak!
so, i’ll briefly restate as “please, do design and coding while pairing, but one at a time!”
November 20th, 2008 at 11:21
Matteo, neither am I, and I’m sure we both (my partner and I) want to have fun programming, as I guess you do. I know sometimes I do sound harsh, but basically I’m with you.
That said, I wouldn’t say I’m a genius, but sometimes I really had to work with blockheads. Luckily this happened just a few times, so I can say these were the exceptions :-) and as such the last sentence in my previous post should be read.
November 20th, 2008 at 14:36
I definitely prefer Luca approach.
If you work in pair and do not talk and confront with your pair about what you are doing, I think you are missing something. To me working in pair also means working together for a common goal through a common solution; to discuss for 5 minutes to agree for a common design/solution is great to me (even if I’m not in front of a whiteboard), to discuss for one full pomodoro (25m) is silly. But this is a discussion length problem, not an “every discussion” problem.
My suggestion? Time box design discussions (5 minutes for a Pomodoro that should be spent on code could be fair)… If the discussion is not over, work alone for spike solutions or adopt Luca approach or understand why there are so many pointless discussions.
“I’m going to do it my way… than you’ll see” does not seem to me a good pair programming approach.
November 23rd, 2008 at 11:35
Hi Vieri,
at first reading I thought I agreed with you. But thinking it through, in the end, I don’t. I mean, Agile development is *not* development by committee. You *don’t* have to have every design choice approved by your team, and not even by your pair. The code will be your committee: if your solution works, in that it provides the functionality you need to complete the story, then it’s ok. If I don’t like your design, maybe I will take the time later to refactor it to something I think it’s better. But I must be careful never to undo any of the functionality that you added. Which is not too difficult to do, because you work with TDD and all the functionality you wrote is tested.
So, if I think I have a good idea that solves our problem, I must have the *courage* to implement it, without asking permission first. If my pair thinks she has a good idea, I must have the *humility* to wait and let her do it, without slowing her down by questioning her design. Perhaps it will not be done the way I would do it. Perhaps I even think I could do better; but in most cases his way will turn out to be good enough. It would be arrogant of me to undo his work just to do it again the way I like it, unless there is a very significant advantage in doing it my way. In most cases I will improve on her design by refactoring a bit, but I will not redo the thing in my image.
My pair may, and should interrupt me if:
It’s OK to discuss things when we both have no idea how to proceed.
November 24th, 2008 at 11:16
Subjects like these are delicate. Both sides in the argument can speak endlessly in their favor. Subjects like these are best left to commonsense. Based on time availability, criticality, modifiability, etc. a decision can be made whether to continue coding, or exploring other possibilities.
{quote}
There’s a place for design discussions.
{/quote}
In my humble opinion, there is no particular place for design discussion. Any place, even when programming with your pair, you might come across a design enlightenment. Start brainstorming then and there. This is the fastest way to innovate, I think.
June 22nd, 2009 at 23:32
some more contribution to the discussion
http://blog.nayima.be/2009/06/19/nemawashi-decisions-by-consensus-without-compromise/