Pair Programming Once a MonthBy Harvey Kandola, 24 Apr 2013
We routinely attack complex or key feature development with pair programming.
In fact we do it once a month.
- pair programming session lasts for just a day, totally uninterrupted
- the paired programmers are on the same technical level
- coincides with our regular NO EMAIL & NO SUPPORT day
We simply select a key piece of the app that requires more brain power – it doesn’t matter if it’s refactoring, enhancements or feature development.
We only pair up people that share the same level of technical competence.
Pairing up a seasoned developer with a mid-level guy will cause problems.
Inferiority complex leads to the less knowledgeable guy not contributing as much. On the flip side, the senior guy thinks he is doing all the work and running the show single-handedly.
This stuff really does negate some of the benefits of pair programming.
Pairing two equally smart folks can also help to bring a slight edge to proceedings - we all want to impress don’t we?
Rotate The Strike
It’s not about sharing the keyboard or mouse – that’s what we envisage when someone says “we do pair programming”.
One person codes whilst the other thinks about what they are doing. Simply rotate the strike until the job is done.
The person watching is responsible for finding flaws and show-stoppers - looking for problems, thinking ahead about architectural and design issues.
Code quality should not be of primary focus as we found that good code gets cut as soon as you have an audience. Besides, nobody comes to work to do a bad job.
Safety In Numbers
Two people working on a single problem does increase the chances of delivering the right thing, first-time.
Validation takes place at every step. Are we building the right thing, in the right way? Both are charged to continually test the vision behind the code being developed.
I cannot remember if we ever had to go back and re-work code that was originally pair-programmed. Hence when we compared normal development with pair-programmed output, the latter produced better code in the long term.
Are we more ambitious with our thinking when in the company of like-minded individuals?
Does this lead to better code and product in the end? I think so.
In a small company, having more than one person who can do stuff for you is a godsend.
So pairing up gives you the benefit of having two folks who can look at any key part of the app.
Kills resourcing bottlenecks dead - the kinds you see in sizable enterprises.
Smack Out Faster
Running pair programming for a day means nobody goes home until the job is done.
We tried longer periods of time but keeping the session to a single day worked best. It’s the right amount of time for an up-close-and-personal encounter with a co-worker, and besides pair-energy seems to drain rapidly after day two.
Share your pair-programming insights.