design_by_committee.md

Design By Committee

I clearly remember my first day at EdgeCase, over four years ago. I was new to Ruby, Rails, Vim, Agile, and -- more than anything -- pair programming. It was one of the most painful working days of my career. I was convinced I'd made a terrible decision. I was completely overwhelmed, my confidence was shot, and I dreaded coming in on day two. Of course it got much better. Over time I gained experience and confidence with Ruby, Rails, and Vim. I got comfortable with the continually evolving agile project flow at EdgeCase. Obviously, I fell in love with EdgeCase and the team I was a part of. But I never got used to pairing.

It's been a constant fight, really. For a while it seemed sacrilege to talk negatively about pair programming. Pairing was the Right Way, and if I felt differently, I must be doing it wrong. In some circles I still think that's the popular mindset, but thankfully at EdgeCase we're much less dogmatic. I'm able to speak my mind, and ultimately it's up to my immediate project team to decide for ourselves when and how often we want to pair.

Still, I've had trouble articulating why pair programming doesn't resonate with me. I often wonder if it's because I'm an OCD control freak who can't stand making compromises and concessions in my code. I can acknowledge that it certainly plays a role, but the thing is, I love getting feedback on my code, even if it gets torn apart. I love learning from that feedback, and I love a sense of shared code ownership. I really do want a peer reviewing every line of code that I write, I just want to write it without him watching me type.

So today's reason why I dislike pair programming -- as you've guessed by the title of this post -- is that pair programming is Design By Committee at the smallest scale. Software written by a committee (a.k.a pair) rather than an individual will be less innovative and less interesting. The result of every decision being a joint decision is that every decision is bland and predictable. For me that's very demotivating.

One thing I can say about pairing is that it's more consistent. A pair of developers will churn out code at a more constant rate than an individual. Not necessarily faster, but more consistent. An individual such as myself is going to swing wildly back and forth, such that at times I can do in two hours what at other times might take me two days. If I'm working with a pair my drive and productivity will be throttled. More consistent, but less capable of getting in the zone and doing something extraordinary.

The irony of this post is that today I worked solo and hardly got anything done. I was journaling tonight and wondered if I should've grabbed a pair. Certainly if I'd paired up with another developer I would have gotten more accomplished today -- at least on the surface. But how much would I really have contributed to it, and how much would I have held another developer back? I was distracted today. I had other things on my mind. It was just a flat out bad day. Shit happens. Pairing wouldn't have helped, it would've just masked the problem and dragged someone else down.

I don't want Design By Committee. I don't want someone else making me appear more productive than I actually am. Part of being human is having days when I just can't deliver. But when I'm ready to bring my A game, I want zero friction. I want no committee in my way. Maybe tomorrow will be one of those days.

Adam, this post completely mirrors my thoughts on pairing. I feel that most days I can write better, faster, cleaner code alone; especially if I've grokked the problem domain fully. Pairing is wonderful for onboarding; otherwise I'd rather whiteboard then divide and conquer. I never did "get" pairing. It doubles the cost to the client. While it does (usually) provide more consistent results, they are slower results.

Quite thought-provoking. I haven't paired as much as "shadowed" you when I had the pleasure of seeing you in action. Whether or not you'd call your work during that time extraordinary, it undoubtedly was for me. That said, do you think the code quality could depend as much on your pair? I'm sure there are moments of inspiration when you're pairing that you do do something outlandish and your pair can see its worth, and there's immediate feedback as opposed to just silently feeling good about it till something breaks?

Nice post Adam -- ultimately pairing is probably a practice that benefits the team and the client to a greater extent than it benefits each individual developer -- I like Zach Dennis's Practical Pairing philosophy quite a bit.

And very innovative use of gist as blog platform :)

@tennety The problem for me is that most "outlandish" code always looks bad initially and can quickly get shot down. But if you follow that crazy thought process a little further, you might be onto something brilliant. I suppose I just don't have the confidence to do that with a pair.

'Design by committee' implies that there are compromises being made to the design because of competing interests. I don't think this term applies to pair programming. You should have an agreed outcome that you are aiming for when you pair. Discussion about different approaches and different ideas should make the process more robust than a single developer heading out into the unknown by themselves. Maybe you need to do more up front discussion of the design and approach. Pairing is all about communication.

When I like to pair:

• my pair has a skill that compliments my weaknesses (such as the skill of having every Railsism memorized)
• domain knowledge transfers
• we're both new to a framework/language - this mitigates spinning wheels for hours
• coaching/mentoring
• fire drills where a time constraint could lead do deploying clumsy errors
• I hit a bad productivity streak alone

@stuart, whether pairing or working alone, the primary goal of the design is to make the feature work. However, the secondary goals which drive experimentation, like wanting to use a particular language feature, wanting to avoid a particular feature, wanting to emulate a certain style, wanting to try a particular library, etc, are what get compromised while pairing.

My biggest problem with pair programming is how worn out I get. When I pair (which I admit, I haven't done in a while), I feel like I have to be "always on."

While I'm in agreement that their are times where pairing may not be the best option, I disagree with almost everything else. I don't find pair programming to be design by committee or lessen the quality of what I produce in any way. Certainly there are times when pairing may make it uncomfortable, or difficult to speak your mind but not doing so is only deferring the issue until a later time.

If as a pair you become so set on a design decision that is at odds with what your pair wants to do, that is a problem that needs to be addressed sooner rather than later. Writing that code solo and then having the discussion in code review after the fact is going to lead to one of two things happening:

1. the reviewer will end up "settling" for the code even if they don't agree because it works and timeline constraints prevent further time spent on changes

2. the author's feelings will be hurt because going solo that whole time lead to a pride in ownership that is now bruised by having to make changes.

Both of these scenarios lead to resentment on someone's part, which is death to team cohesiveness and success. In addition, for organizations that believe in the core agile principle of early feedback it seems very counterproductive to delay getting feedback on a large swath of code until after it is completed. The earliest feedback you can get when writing code is from your pair.

Consistency and collective code ownership are of utmost importance to a healthy team, and out of the many times I've tried it, I've never been able to achieve the same level of ownership from code review as from participating in the creation of the code through pairing. For review of code with any substance it is far too easy for people to fuzz out. I also think it's harder for most people to communicate grand design ideas in an engaging and understandable fashion. The more people who have a shared understanding of the design developed through implementation the better chance you have of communicating those ideas to others.

In regards to innovation and creativity, I for one feel more confident in suggesting and attempting new things with a pair. I regularly throw out ideas when pairing that may seem silly in my head, but if I can get my pair to buy into it then I have more confidence that I'm not about to go down a rathole. Also when working on something that I am less familiar with a pair helps me to get to a solution faster than me digging around on google by myself.

Also in regards to innovation is that in reality, most business apps of the world don't need a lot of innovation to be successful. On the contrary, the tendency of developers to "innovate" out of boredom of repeating the same solutions time and again could be considered detrimental to the state of many projects. Innovative code, particularly done without a pair is code that someone tomorrow tends to look at and wonder " why the hell was this done like that?". Innovative code is the type best done with a pair so that there is shared understanding of the "why". Without that shared understanding it is all too easy for future decisions to reverse or conflict with original intent of the innovative ideas.

If I'm having a really off day I'd agree that I'm probably bringing down the productivity of the pair. If I'm only having a slightly off day however I view pairing as still being good because it helps me feel like I was a part of accomplishing something. Personally I get anxious if I go for very long without producing which only decreases my productivity further.

In summary, I don't think pairing in and of itself results in any of the problems that you describe. On the contrary it has many benefits for those for whom it works. The trouble is that pairing may not fit everyone's personality types and to attempt to be dogmatic about it (as with anything) causes more harm than good. In the end, that is the great thing about Edgecase. We can have these sorts of discussions and disagreements and realize that not everyone works most effectively in the same way. We're adaptable enough to work within everyone's strength areas to achieve the best outcomes for our clients.