+972 52-548-6969
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.
Comments
And in any part of the life, be it on work life or personal life.
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.
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.
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. ;-)
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