nirvana: pair programming and test-driven development

So, for the last week or so, I have finally managed to force myself into both pair programming and test-driven development (TDD). Oh my… how have I managed to be a developer for this long without those two things? “Pairing” in my office has often meant “we’ll work on similar stuff and check in with each other every half hour or so.” That isn’t pairing – that’s keeping your teammates informed. TDD in my office is usually “if I think of it, I’ll write a small test beforehand, then code the whole implementation up, then write more tests if I have time (never).” This is not TDD – this is lip service.

So, real pairing. Two developers watching one screen, both keeping an eye on the line-by-line coding as it happens, frequently swapping places (who drives and who watches). Although my coworker and I sit near each other physically, we used VNC for the actual screen watching – less invasion of personal space. This also made it an easy transition to our team’s telecommuting day – just add Skype into the mix and continue as we were. Our habit has been to commit to Subversion after each implementation class is done, and switch control at that time as well.

The con here is fairly obvious, and has been debated many times at my workplace. Pair programming simply takes longer to develop the same piece of functionality. Two developers working on a single task will not complete it in half the time. Unfortunately for pairing proponents, the benefits are less obvious to those you are trying to convince – the actual code produced has far fewer bugs due to receiving the close attention of two developers. The resulting design will be simpler, and two developers’ worth of knowledge and experience will be poured into the design and choice of libraries. There is also an automatic alleviation of the beer-truck factor – neither developer has a monopoly on knowledge of the implementation.

Tying in with this, at least temporally for me, is the concept of test-driven development, or TDD. In this past week, my pairing partner and I have defined TDD as “no implementation code is written unless there is a unit test to exercise it.” Our typical work flow was to write the interface for a class we needed and let Eclipse generate a skeleton class from the interface. Then, write a test for one of the methods in the interface, write just enough code to make the test pass, and repeat. This melds wonderfully with pair programming. It assures there are even fewer bugs in the final system, since you are largely assured of having extensive automated testing. Design is kept simple since code is only written to satisfy a test – reduction of code bloat.

Since this is (almost) my team’s first foray into pairing and TDD, we were generous in our estimates. When tasking out our stories (we’re a scrum shop), we took our one-person estimate for a task and doubled it. For this past week of work, my pairing partner and I have consistently beaten these estimates while not faltering on TDD – our end-of-sprint rush to integrate and fix bugs found during the manual test will hopefully be largely alleviated.

This is the coding-heaven that I have been striving for since I entered the software development “real world.” I’ve seen glimmers of it here and there, but now I see what the full version looks like, and I’m on cloud nine.

Further Reading:
A short case study of pairing, one of the references from the Wikipedia article [PDF]

[EDIT: It's been brought to my attention that I should explain the phrase "beer-truck factor." At least in my office, this is the risk that if only one person has deep knowledge of the system, the team could be in a bind if that person quits or is removed from participation in some other way - such as getting hit by a beer truck.]