http://blog.nayima.be/2009/06/19/nemawashi-decisions-by-consensus-without-compromise/

{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.

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:

• I’m racing through without explaining; I should have the *humility* to explain what I’m going to do, so that he can work with me. I should not treat my pair as a spectator.
• It’s clear I’m getting nowhere: if ten minutes pass and I can’t get to green, then *the code* is telling me I’m wrong. I should ask my pair for help. My pair should remind me to be disciplined.
• I’m breaking the rules. I’m working with more than one broken test, or I’m not writing the tests, or I’m not respecting the pomodoro. Discipline again.

It’s OK to discuss things when we both have no idea how to proceed.

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.

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!”

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 :)