Why would you have 2 ‘resources’ pair up to write code for the same task?
Why would you have a developer spend half their time writing and updating unit tests?
Why would you spend hours using test-driven development to fix a single bug by having to build the necessary testing code with mocks, stubs, fakes, etc. instead of jumping straight into the code and ‘fixing’ the bug within minutes?
Writing code is an intense creative process. The limiting factor is not how fast developers type! Otherwise we should be hiring and filtering for developers who are the fastest typist! But, if you have observed how developers spend their time in terms of how much time is spent typing final production-ready code – it is typically a small percentage of their time. What goes into writing the code is the reading of existing code, the design thinking, getting into the zone of understanding the abstractions and the problem domain etc.
If you want to go faster as a development team, then you should pair program and practices TDD, refactoring and the XP engineering practices.
Coming across the Wall Street Journal article titled: “Computer Programmers Learn Tough Lesson in Sharing” reminded me of my days pair programming routinely every day in an eXtreme Programming (XP) shop for a number of years. The learning curve, creativity, quality, and overall team bonding was amazing as we were constantly, in the words of Kent Beck, founder of XP, embracing change especially as we went through the roller-coaster of our start-up environment.
As I’m coaching various Scrum software development teams, the XP engineering practices don’t seem to get as much attention as needed. However, mature agile high performing teams recognize that the backbone to being Agile is technical excellence. Robert Martin (Uncle Bob) points that out in more detail in his posting: The Land that Scrum Forgot and a video talk by the same name.
The most in-depth analysis on pair programming that I’ve seen is in a great book by Laurie Williams and Robert Kessler (Amazon | Indigo). It ignited my appreciation for the the different styles of pairing and the creativity that comes out of that. I got my hands on it about a decade ago as I got more deeply involved at the time with pair programming.
It dives into some of the mechanical issues of how to pair and rotation of developers and also zooms into the behavioral aspect of pairing with differrent experince levels: expert-expert pairing, expert-average pairing, expert-novice pairing, or novice-novice pairing.
I have paired with hundreds of developers over the years in various settings. It’s not surprising that for many developers who have been conditioned over the years to write code in solo, a pair programming environment feels intimidating and awkward. It can be a shock for someone not used to it. I remember in one of the development shops that I had worked on as Technical Team Lead we had a deep appreciation for pairing and lived it every day that in our interviewing of candidates we would include a pair programming coding exercise.
It’s worth reflecting on Laurie Williams’ and Robert Kessler’s observation of the “Seven Habits of Effective Pair Programmers” includes: communicate, listen, and practicing humility.
There’s a movement around remote pair programming which you can check out at: http://www.pairprogramwith.me/. If you are interested to learn more about why you should pair program, then consider the following:
Too many work environments are still stuck in cubicle farms and have a culture that treats people as resources with pair programming being discouraged. At least we can hope that the next generation will not have that baggage!