Have a Cookie

First Line Software may use cookies and my IP address to collect individual statistics and to provide me with personalized offers and ads subject to the Privacy Policy. First Line Software may use third-party services for this purpose.

Many Agile folks love pair programming, and a lot has been written on how great this technique is for Agile teams. However, if misused or allowed to get out of control, pair programming can do serious harm.

 Pair programming involves two developers working as a pair at the same keyboard, one “driving”, i.e. writing code and explaining why certain statements were used, etc., and the other “observing” – paying close attention to what is happening on the screen and providing early feedback. This approach enables early discovery of obvious design issues, before the code is even first compiled. By asking the right questions (the ones a sole developer would probably never ask himself), the “observer” can identify early functional problems as well. This saves time on QA/debugging down the road, and the overall feature delivery time can be reduced.

However, simply pairing people up and letting them loose isn’t enough. In certain cases, using (misusing?) this technique can have unwanted consequences.

The first case is two junior developers working as a pair. Neither one has the knowledge of the solution structure and patterns applicable to the system. When they start implementing a feature, they are likely to try to reinvent the wheel multiple times and embed their code into the overall application in ways that will make it very difficult to maintain. Even if the feature conforms to the test cases, it will consume more time in future through debugging and refactoring.

The second case is a pair consisting of an experienced developer and a junior developer. This is actually done quite frequently for training purposes. The mistake would be to have the junior developer observe only, without doing any driving. While writing the code, the senior developer would explain why certain methods were used, how this or that class interacts with other components, where the right place in the application is to implement required changes, etc. However, if the junior guy doesn’t get to drive, to try all those things himself, it is unlikely that all those useful coding techniques and tricks will actually be learned and used properly in the future. As a result, the time spent pair programming will not benefit the junior developer, instead making things even more complicated and confusing for him, leading to growing frustration.

The last case is a situation when the project is dramatically late, and the management demands aggressive ramp-up and maximum velocity. The scrum master decides to make developers work in pairs in order to increase code ownership, strengthen product quality and mitigate the risk of loss of key people. Very soon, team velocity goes down (which is normal, as it may require several months for the benefits of pair programming to materialize). Presented with the burndown chart at the next steering meeting, the management puts pressure on the scrum master to “un-pair” developers so they can work independently and close more hours. The scrum master caves under pressure and releases the pairs. Ultimately, he or she may decide that the pair programming is simply useless.

Pair programming not as just a fashionable agile technique to be adopted unthinkingly. In order to produce the desired impact, it requires proper environment, the right skills, and finally, continuous monitoring and support from a knowledgeable scrum master or a technical lead.

Download Case Study

Need more details?

Fill in the form and we’ll contact you as soon as possible.

David Tedford

Vice President

David Tedford has over 20 years of sales experience within the IT/software industry. He excels at being immersed in a customer's environment, understanding his customers requirements, crafting solutions to meet those requirements, and ultimately providing solutions to his customers.

Vladimir Litoshenko

Senior Vice President

As the head of business development for First Line Software, Vladimir heads up business development in Western Europe and Russia.

Vladimir began his career in IT in 2002, when, as a student of Faculty of Automation of Computer Science of the First Electrotechnical University (ETU “LETI”), he began his work at The Morfizpribor Central Research Institute (CRI). Vladimir joined the StarSoft team (predecessor of First Line Software) in 2004 as a Junior Software Developer. As he gained experience with more and more projects, he was promoted to leadership roles.

Richard Leslie

UK Business Development

Richard has over 15 years of sales and account management expertise in the IT and Tech sector. He has worked on many outsourcing engagements with global companies.

David Fien


David is a business development professional with more than 20 years’ experience as a specialist in the acquisition of partnerships and IT/software services for associations, not-for profits and corporations in Australia, New Zealand and USA. He has specific expertise in the healthcare, legal and hospitality industries.