Why Growing Startups Should Consider Pair Programming

In today’s digital world a top development team is hard to make. And even in the best teams, things can go wrong. Fortunately, there’s an agile software development technique that can improve performance: Pair Programming.

Yes, it means you’ll need a bigger team. But it doesn’t mean that you will regret the investment. How come? Here’s what makes Pair Programming teams a cost-effective solution for a startups.

One Plus One Equals More Than Two

Two developers working as a pair produce better results than the sum of their work created individually. Why? Because Pair Programming brings out the best out of them.

At times you can’t come up with an answer to a task. You’re completely stuck and annoyed by your limits. Then you talk to someone and get to a solution you didn’t think of before. Pair Programmers has that advantage. The driver (the person which writes the code) can work his way through the issue with the navigator (the person which reviews each line of code as it is typed in). The navigator will often be ahead of the problems that might have occurred within the next lines of code. Additionally the pair can brainstorm their ideas on-demand at any time.

The above might not be convincing enough for you since it’s just a soft skill. Laurie Williams and Robert Kessler needed to check the truth of the claims for their book Pair Programming Illuminated. They ran an experiment on 41 students at the University of Utah over the period of 16 weeks. The student’s task was to write 4 apps. Solo developers and pairs competed with each other. Developers that have worked in pairs finished their projects in about half the time compared to solo devs. And their code had much fewer bugs.

Pros of pair programming

Summing up the above — two developers working as a pair give better results than two individual devs because:

1. The problems that occur during development are solved much quicker.
2. Their work is finished faster.
3. Their work has less defects, which means there will be much less time spent on debugging the code!

Less Distractions

According to a study a task that is interrupted usually take twice as much time to be finished and contains twice as many errors. Developers hate to be distracted but nowadays they also often distract themselves. Checking social media, choosing the right music on Spotify, watching just one short and funny video on YouTube. We’ve all done that. We all lose our focus and waste time because of that. And we probably would be doing much less of that if there’s someone else sitting next to us.

When working in pairs, people are much better at deferring interruptions. They won’t take breaks to surf the internet. They won’t answer calls on their phone and check Facebook notifications. Additionally, other co-workers are much less likely to talk to someone working in a pair.

Thanks to pair programming many mental blocks that obstruct the work flow of developers can be easily avoided. That’s the effect of peer pressure, which in this case is a very good thing. Individuals in pair will not want to annoy or let down the developer they work with.

There’s Always A Backup

Having developers work individually has some risks. Even if it’s a Scrum team that has daily standups, good communication and knowledge is shared. But what happens if one of the key team members is sick or leaves the company?

With pair programming knowledge is shared in the best way possible. Developers not only learn new things from each other. They also share the deep knowing of the code and your product. In other words pair programming is a safety option for startups. In case anything happens, there are other team members that know the code and can continue working on projects. Product updates will continue even if some of the developers are missing. And that might help you stay one step ahead of competition.

Is a Pair Programming team more expensive?

At the start — probably Yes. In the long run — No. There is a reason why people spend more on products that are of a better quality. For the same reason teams that use Pair Programming should be chosen over those using other techniques. As mentioned above, Pair Programming teams work faster, create less buggy code, are less distracted and ensure the safety in case the people leave. For me this is pure quality. And that’s why I believe it’s a cost-effective choice for growing startups.

Have other pros or cons about Pair Programming? Let me know in the comments below.