Wednesday, November 16th, 2016
Nowadays, there is in the software development community a common understanding that agile methodologies are the best approach to build applications. One of the most extended methodologies is Scrum and very frequently is implemented together with some eXtreme Programming practices.
One of these practices is pair programming, a lot of times considered as a very exotic and expensive practice.
It might seem that two people working together in the same task causes the doubling of the cost, but however, regarding the medium and long term, nothing could be further from the truth.
First of all, pair programming is not an easy practice. It requires a lot of energy, motivation and a huge attention span. But the benefits are endless:
- Economics: controlled experiments found only a small development cost for adding the second person. However, the resulting code also had fewer defects. The defect removal savings should more than offsets the development cost increase.
- Satisfaction: people working in pairs found the experience more enjoyable than working alone.
- Design quality: the pairs produce shorter programs than their solo peers, indicating superior designs.
- Continuous Reviews: pair programming’s shoulder-to-shoulder technique serves as a continual design and code review, leading to most efficient defect removal rates.
- Problem solving: pair members constantly refer to the team’s ability to solve “impossible” problems faster.
- Learning: pair programmers repeatedly cite how much they learn from each other.
- Team Building and Communication: people learn to discuss and work together. This improves team communication and effectiveness.
- Staff and Project Management: since multiple people have familiarity with each piece of code, pair programming reduces staff-loss risk.
The applications developed using pair programming have significantly better quality code and can grow faster.
Summary: despite the reluctance and preconceptions, pair programming is well worth the investment and it should be part of a software engineer’s normal daily practice.