First Line Software is a premier provider of software engineering, software enablement, and digital transformation services. Headquartered in Cambridge, Massachusetts, the global staff of 400 technical experts serve clients across North America, Europe, Asia, and Australia.
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.