It’s vital to overall productivity that code is written correctly first time, said Cyndi Mitchell at ThoughtWorks. Bad script holds up applications because of the knock-on impact a line of badly written code has on other parts of the application. Subsequent rework is effectively ‘dead time’ because it could be better spent on developing new parts of the project and moving it forward quicker.
Pair programming involves one programmer, the driver, entering the code in the computer with the other programmer, the passenger, shadowing alongside. The role of the person shadowing is to suggest ideas beforehand and then check the code for improvements or innovations while it is being entered.
Developers when working on their own and encountering a persistent problem often tend to think they’ll give it ‘just one more try’ and follow a path that will lead nowhere, said Mitchell. In pair programming, the passenger usually spots this and can stop them wasting further time. Another example is where a developer will add extra parts to a program that are not necessary but look nice. In this situation the passenger can question the driver as to why they are doing what they are doing and save time.
We estimate that a pair of developers working together will produce about 75% of the total code output of two people working separately. However, whilst it may appear less productive, it’s actually more so because the code is of much better quality with fewer defects, so less rework needs to be carried out at a later stage.
But Mitchell said pair programming is not widespread and it is a challenge to convince organizations of its value. Many companies and IT consultancies struggle to understand the concept and believe they’re paying two people to perform one person’s job function, she said. This just isn’t true and in the end, time and money is actually saved because the project can go live much faster.
