Blaine Buxton: Positronic Vibrations

I work in an eXtreme Programming shop and we pair on ever single line of code. But, too much pairing can be bad. Some pairing partners, while excited initially to try something new, grow complacent after the honeymoon wears off. It's hard to keep them engaged. Pairing all the time stifles creativity because developers are simply uncomfortable taking risks in front of others (we are mostly introverted). It creates a strange group think atmosphere where pairs do what is comfortable and familiar. Few branch out and try new things. The ones that do, do it at home without the fear of failure in public. Sad but true.

Pairing on every single line of code is the path to broken windows. eXtreme programming enthusiasts scoff and grumble at this notion. Why? To ignore that developers are mainly introverts is fighting an uphill battle against human nature. The very thing that eXtreme enthusiasts claims that they embrace. Agility to me is about thinking to solve problems, not adding stifling processes or pithy mantras.

If pairing all the time is bad, is it alright to go back to our lonely cubes? NO! There is immense value in pair programming. In a good session, there's an unparalleled exchange of ideas and an unbeatable code review process. I find the good things happen if the pairing is not constant. Always pairing can be tiring mentally and physically. We all need time to recharge our batteries and reflect. Extended breaks can give us the spark of inspiration to solve that complex puzzle in our design that's been plaguing us.

The key is balance. Doing anything to the eXtreme risks team burn-out. Balance should really be the point of being agile. Take the advice of your mother. Everything in moderation is a good thing. Otherwise, you risk off going off the edge. Constant pairing erodes the benefits of it. Of course, the opposite is also true. The lonely coder can be a dangerous tumbleweed in your codebase.

My proposal is simple: Pair during design and creation of unit tests, not coding. This is where collaboration is a must and the most fun. A test-first approach helps a pair to design the domain language for business. It boils away all unnecessary abstractions and allows the pair to get to the heart of the problem. It becomes the design while providing the harness to verify its validity. Pairs challenge each other to write tests that express the business the most succintly.

Allow pairs to break apart to write the code that satisfies the tests that they write together. This allows personal time for reflection and to try out new ideas. It gives the much needed time to reflect and the exhilaration of collaboration. The pair should come back together after the code is complete and review what each other has done. A refactoring of each other's code is good at this point. Allowing the sharing of information without one pair becoming disenfranchised with a dominant other. Of course, if pairs feel the need to discuss issues as they come up in the code, they should. Remember, it's all about balance!

I have seen first hand the pitfalls of pairing too much. The code and design eventually suffer. Spaghetti ensues and no one wants to work on the brittle system. Quality slips and the team descends into finger pointing and negativity. Pairing only amplifies the problem because developers have no way to get away and heal their wounds. Everyone needs some time alone. But, we also need interaction to stay fully engaged. Everything to the eXtreme is bad. Balance is the order of the day. I will not offer any cute quotes or clever acronyms, just simple advice.

If you're thinking of trying out pairing or are just a burnt out XPer, try out my advice. It offers the best of both worlds. It's a meeting in the middle and is good to try out a new way of working together. You can have your cake and eat it too. Just don't eat only cake. You need your vegetables too.

posted by Blaine at 8:05 PM |  1 comments |  Post a Comment