Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,488

filter by tags archive

Pair design sessions

time to read 1 min | 113 words

It isn’t just pair programming that is really useful. I had a problem that I found horrendously complicate to resolve, and I got on the phone with the rest of the team, trying to explain to them what I wanted and how I wanted to achieve that.

Luckily for me, they were too polite to tell me that I am being stop and that I should stop whining. But they were able to guide me toward an elegant solution in about fifteen minutes. Until at some point I had to say: “I really don’t understand why I thought this was hard.”

Getting feedback is important, be it on code or design.


Tuna Toksoz

And in any part of the life, be it on work life or personal life.

Steve Py

In one of my first XP-esque roles where the team transitioned from traditional waterfall project management & looking to adopt some agility we looked to adopt XP by the book. (Beck)

Pair programming was one of the hardest things to get consistent & unilateral approval on. It was absolutely fantastic when the team grew from 4 developers to 12 as we would pair new arrivals with experienced developers. However when everyone is up to speed the project velocity felt "slow" & quality was/is tough to measure. So we tried an adjustment. Pair programming would be optional, and continue to be used when new developers were brought in. Instead we focused on pair design. Developers would discuss and design their stories as pairs. Then each would go and do the development and unit tests separately, swapping stories to peer review. The justification was that "writing" code was only about 20% of the time spent on stories. The real value of pairing is bouncing ideas and ensuring more than one person knows the details of features. Code quality is maintained via peer reviews.

Whenever I'm asked about Agile & pair programming, pair design is what I pitch.

Ben Taylor

I often find that verbal communication results in me "seeing" the design while part way through explaining the problem. Or at least having a new insight into the possible design. The actual act of converting my problem into words, triggers new thoughts.

Chris Kemp

Honestly, I frequently find that just verbalising a problem helps me find the solution. My company refuses to buy me a rubber duck, so instead I have to make do with colleagues. ;-)

Mark Embling

I cannot agree with this post enough. I often find that if I run into a problem or whatever, the best way to solve it is to talk it through. Often the solution is produced as a result of the discussion. Like others here have mentioned, this is even more important and the benefits more prominent when it concerns design or architecture of a solution rather than just the implementation.

In my opinion, working with another developer makes you a better developer yourself and the benefits cannot be overstated. Nice post.


All of our biggest decisions are made as a team. There is no single team member who has a more complete view of the entire system and everything involved than all of us together.

It might take a little bit longer to flush out a design between all the talk back and forth, but in the end we have a better design than any one of us could have come up with AND we're all standing behind it as well.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Physically segregating collections - 14 hours from now
  2. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - about one day from now
  3. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 5 days from now
  4. The design of RavenDB 4.0: Voron has a one track mind - 6 days from now
  5. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 7 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    03 May 2016 - Making Lucene reliable
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats