While many people feel that pair programming is a great way to share knowledge, others may feel that it can be a waste of time or that it can be difficult to adjust to. So how do we overcome the resistance to pairing and make it a more of a routine in the development process? This article looks at four strategies that can help.
For many companies, the popular motto is often "If it ain't broke, don't fix it". And who can blame them? After all, why change something that's already working? It's hard enough to get business owners and employees on board with basic agile concepts—why would you try and push them further than they're willing to go? A good starting point for pairing skeptics might be to ask their thoughts on pair programming. Ask them if they'd be willing to take part in some pair-programming sessions (if they've never done it before) or share with them an experience where someone benefited from pairing up. Alternatively, ask them what challenges they think could arise from pairing up. Consider these reflexions as an opportunity to raise awareness of what pair programming actually means.
Take Things Slow: once management is on board with the idea of creating more efficient work environments through pair programming sessions, make sure there are clear guidelines about how things will work moving forward. For example, if managers are expected to take part in regular paired sessions with team members—this should be communicated both internally and by executives at press events outside of meetings (For example, our senior management takes part in weekly pair code reviews). Encourage Self-Selection: The people within your company likely have different skill sets and varying degrees of experience writing code.
You can’t expect your team to pair program every day —it’s something that needs to be nurtured. One way is by giving your team regular pair programming timeslots. This could be once a week or once a month, but it's important that you set aside dedicated time for pair programming. Ideally, an engineer should have some practice before they're paired with someone. Explain why they're doing it: Frame pair programming as a skill everyone needs to learn and use regularly—like refactoring or testing. Everyone is allowed to say no at first if pairing isn't for them, but over time you'll want people who are willing and capable of pairing at any point in time. If possible, try to help make sure there aren't any holes in coverage when a pair isn't available. For example, give another engineer a list of things they can do while waiting for their next opportunity to pair. If you don't have enough engineers on staff, consider finding ways of pairing engineers up via video conference instead of sitting together in person. Take It In Small Bites: If you've never tried pair programming before then don't jump into it right away without taking small steps first.
It’s a common mistake to force teams who aren’t used to pair programming into it. To help people get used to it, make it optional. Let them know they can switch back if they find themselves too uncomfortable or something comes up at home that makes uninterrupted work difficult. It could even be as simple as letting them know they can come talk to you if there’s an issue—but let them choose whether or not pair programming is worth their time (and yours). As long as your team knows that pairing is optional, you should be able to overcome some of your initial resistance. Once in a while, let people in pairs do non-pair tasks when necessary. If you have two design leads working on one project together, but only need input from one person on an idea, allow them to run away from each other and work independently for a while.
There are two important pieces of advice in regards to pair programming: start small and go slow. When you’re just starting out, try teaming up with someone on a quick, one-off task or project. Don’t dive into it for an eight-hour coding session—start with something that only requires an hour or two together. This way, you can make sure everyone is on board before really diving in. And going slow makes more sense than going fast when there’s so much resistance from all sides. Go slowly enough so people have time to get comfortable with whatever method you decide upon, whether it be pairing on a single problem or doing full-on two-person assignments for each person on your team every day of work. And even then, expect some pushback from “why change?” type of employees who just want their own space and quiet time at work!
It can be difficult to overcome resistance to pair programming. But, as we’ve learned in this blog post, there are some simple steps that can help you make it easier. Try pairing up with somebody who’s new to it and see how it goes, or try pairing up with somebody who’s willing to help you learn. And remember: even if you’re facing some resistance, it doesn’t mean that your team won’t eventually love it. As you learn more about why people resist pair programming and how you can overcome it, you can help your team fall in love with it as well!
Create your free account and start collaborating right away with your team on all your apps. Should you have any questions about our offers, be sure to contact us.
