The Cons of Pair Programming
1. Higher costs
Having two people working on a single initiative may seem like a waste of valuable resources. Indeed, it’s true that pair programming won’t be able to complete a project in half the time.
Still, the greater overhead that pair programming incurs is typically balanced by the higher-quality code and a more efficient, effective final result. You pay more in costs upfront, but you can recover your investment over the lifetime of the project, since you’ll spend less time maintaining the codebase.
Pair programming isn’t usually sustainable enough to be practiced all of the time. The ideal amount of time to spend pair programming seems to be around 2 to 2.5 hours—and don’t forget to take breaks!
The good news is that you can take measures to break up the intensity of pair programming. Try switching to a new project or a new partner throughout the day to help keep your mind fresh.
Pair programming isn’t new; it’s been around the software development industry for decades. As a practice, pair programming originates from the extreme programming (XP) methodology, which prioritizes high software quality and frequent tests and releases.
For some organizations, pair programming simply isn’t the right fit for their situation. However, a growing number of companies are finding that pair programming has a variety of benefits, including saved development time, higher-quality code, and better training and onboarding. As a result, everyone on the team is working together to build the most successful, best version of the product possible. To learn more about how we work here at Very, contact us.