The Key To Starting Pair Programming
The Key To Starting Pair Programming
Pair programming may not be what you think it is and it's easy to get it wrong. Never fear! Sam Atkinson takes a look at what pair programming isn't, what it is, and why it's important to get right.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Pair programming is a technique which, despite growing popularity, has had it’s fair share of detractors. There are the normal complaints from stakeholders that you’ve got two programmers doing the job of one, and for most developers, their first experiences of pair programming involve sitting next to another developer watching them code and pointing out their spelling mistakes whilst slowly falling asleep.
This is boring. And this isn’t pair programming.
Much like Agile development, pair programming is a wonderful thing that is easy to do badly. Agile development was created to allow systems to be built in a fast and flexible manner, putting people over processes. In reality, shameless cash-ins such as the Scrum Master course has resulted in rigorous processes being grafted on top of waterfall which has brought zero benefits. The same goes for pairing; it’s not just a matter of sitting two people down at a computer and having one of them start coding.
For both agile and pair programming, unless you have someone on board who has experience and has seen it working well in another organization, it’s very very hard to get right.
Where to Start
I also happen to be a big fan of Test Driven Development, and it just so happens that TDD and pair programming make a wonderful partnership that results in both developers being engaged and productive, along with the production of better code.
The process is simple.
- Programmer A writes a test
- Programmer B writes the simplest thing to make the test pass
- Programmer B writes a test
- Programmer A writes the simplest thing to make the test pass
If you follow this pattern then you will both enjoy yourselves and the code produced will be certainly better than anything that either of the developers would produce independently. Coding becomes a game between the pair about who can write the test that produces the best code.
The first test written requires a good deal of discussion between the developers. What is the task they’re dealing with? What’s the simplest piece of functionality that can be tested about it? This discussion and back and forth will inevitably bring out more questions and discussion than would have ever occurred with a programmer by themselves. Even if you don’t think you can try pairing in your work, then try spending 5 minutes to chat over each task with a team mate. It will alter your solution drastically.
Programmer A then writes the simplest test. No production code allowed, except to create the entities required to make the test compile. Programmer B is then challenged to make this pass doing the stupidest thing possible. This isn’t pedantry — if a test can be made to pass with a simple hardcoded return it proves that the test is not good enough. By having a different programmer challenge your test it will increase the quality of the code base. This is also part of the fun; if I can make your something pass doing dumb stuff and then write a better test it means more time as the off-keyboard member of the pair. Don’t worry, though, keyboard time usually ends up 50/50.
Programmer B can then either help to improve the test, or if it’s deemed ok, iterate it, or create a new one. And the process repeats.
Along with drastically improving the quality of the tests and code, it also ensures both developers in a pair get a similar amount of keyboard time so that no one is left falling asleep at the side which is the usual failing of people attempting pair programming. This is particularly poignant when the pairing is between a junior and a senior developer. This is a great way to help a new team mate or less experienced programmer learn, but if pairing is done badly the senior developer will just stay on the keyboard and lecture. The junior developer will quickly become bored and there will be no value gained. We all learn best when we’re doing.
It is the responsibility of the senior developer to try and get the junior on the keyboard as much as possible. This should be relatively easy to do once you’re experienced in pairing as you’ll know how to write the tricky tests. You can then help and guide the junior with the structuring of the code and building the solution. Everyone wins!
There are of course many other ways of doing pair programming. If you have two competent and eager developers and an interesting challenge it’s often simple enough to just grab the keyboard off each other when inspiration arrives. But I do think that if you’re starting off, TDD Pair Programming as a great, structured way to learn the craft whilst producing great code.
Opinions expressed by DZone contributors are their own.