Many articles have been written on the benefits of pair programming. Often, (including the wikipedia article) the focus is on the typing aspect of programming – the speed at which code is created as well as the real time review of what is typed. I believe this is one of the least important aspects of pair programming.
Programming is more about Design than Typing
Over the years I’ve noticed a difference between great programmers and average ones.
Average programmers are often seen typing.
Great programmers are often seen staring at code.
The reason, it seems, is because great programmers are thinking bigger. They’re thinking about dryness, code consolidation, reuse, simplicity, using the existing framework, and a lot of other things than the specific tracker task they’ve been assigned. Average programmers focus more on simply creating the code and tests for that task. As a percentage of their work, average programmers type more.
Thus, focusing on the typing aspect of programming is biased toward the mediocre. It is the “small lever” within software development. The big lever, the one that effects the long term cost of software development and maintenance is design. And design comes from thinking.
Design (and thinking) is improved by dialogue
The real power of pair programming comes about due to the dialogue between the developers. In order to present a design idea, the developer needs to put his/her idea into words and that process alone is often very valuable. It is very easy to have an idea about how to solve something, yet gloss over some of the details or complex issues. By taking a vague design thought and putting it into words, the person with the idea is actually learning about his/her idea. Obviously, this process of verbalizing a design is usually missing when working solo and often a developer will simply head out in a “direction” confident they will figure out the details as they proceed. With pair programming, a pair usually doesn’t allow this.
This verbalizing is inherently a good thought process. The gaps in your thinking are exposed.
Along with discussing the solution design, the developer also likely will state their assumptions about why they think something should be done. The assumptions could be about risks, costs, testability, etc. And again, that dialogue between developers leads to further knowledge transfer and understanding.
Here’s a quote from The Costs and Benefits of Pair Programming
We often came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design.
One last note about design. I have found that pair programming tends to keep developers near the minimum of the cost curve (written about in Line Count and Maintenance Cost) instead of the arcane and wordy areas of the graph.
To sum it up, forget about all the nitpicky stuff in pair programming, that is not the long lever. It’s about quality and maintainability of software, but that will only happen if the developers are truly pair programming and not simply sitting together at the same keyboard. But that’s a different post.
Recent Comments