Choose your language:

Australia

Germany

Hong Kong

India

Ireland

Netherlands

New Zealand

Singapore

Sweden

Switzerland

United Kingdom

United States

Why are tech innovators adopting pair programming?

March 19, 2018 | By Jordan Schwartz

male and female review code on a computer

It’s no secret there’s an organizational trend to adopt an efficient, product-centric approach to software engineering; after all, the importance of getting products to market is adding pressure for organizations to act—and act quickly. Any strategic change brings new challenges, organizational needs and roles to fill. Combine the shortage of talented developers with the pressure to bring products to market faster, and you’ll find companies that are compelled to take risks—like hiring people with little to no experience. This can be costly.

“Organizations are looking to enable innovation in a time of challenging market conditions,” says Dave Spires, executive director of Application Services at TEKsystems. “A sustainable solution that’s finally making its way into the limelight is pair programming.”

Like most technological trends, pair programming was born on a date that far precedes its adoption. The concept is unique and fairly simple—essentially, it’s when two programmers code together at one work station. One navigates while the other drives; they work through problems together and review each other’s code. If done correctly and with the right mindset, pair programming offers undeniable organizational benefits. But is it a good fit for your organization?

The benefits to implementing pair programming

“One of the biggest and most underrated benefits of pair programming is mitigating the risk of having a single point of knowledge on your team,” says Adrian Gonzalez, a developer who works as a TEKsystems consultant. Often times, one developer knows the system better than anyone else on the engineering team. “If said person leaves the company or goes on vacation for two weeks, development could potentially halt,” says Gonzalez. Programming in pairs mitigates this risk by spreading the wealth of knowledge: having pairs rotate through different pairing combinations helps each one learn from the other’s strengths and expertise. This can also help in DevOps environments, in which developers are expected to have knowledge of InfoSec, testing, operations or other competencies. 

Pair programming also helps solve the problem of hiring entry-level developers. The most cost-effective way to bring an entry-level employee up to speed is letting them do real work. Meanwhile, you mitigate the risk that their code will cause problems by pairing them with a seasoned software engineer. By doing so, the less experienced engineer can enhance their hard and soft skills in a very short period of time. On the flip side, the more experienced engineer may get some fresh perspective. Contrary to popular belief, you can teach experienced developers new tricks.

Pair programming doesn’t eliminate the need for training altogether. It eradicates lost time and lack of productivity associated with offsite trainings, which often shut down programming tasks. It also teaches valuable soft skills. “Developers learn to communicate better and give constructive criticism, which can be just as valuable as writing better unit tests and quality software,” says Gonzalez. 

Getting products to market faster and enhancing productivity is always top of mind for IT leaders, and pair programming helps eliminate blockages that may push back timelines. Is there a bug in the code that just won’t die? Or perhaps one your programmers missed an error that doesn’t get caught until testing? Programming in pairs provides extra perspective when reviewing code, which can help the team meet its go-live timeline more predictably. What one programmer doesn’t see the other one most likely does.

As always, there are a few challenges

Pair programming may be extremely effective, but it isn’t magic. Organizations always face challenges that come along with rolling out a new strategy, and pair programming might not work for every project. 

Enterprises should prepare to incur an upfront investment if they adopt pair programming. “Initial work effort and cost can’t be overlooked,” says Spires. “If you want to commit to pair programming in your organization, you should expect a large investment with little return at first; it requires patience and discipline to reap the rewards. Most organizations with a successful pair programming practice see the outcomes they desire with low costs after 6–12 months of implementation.”

Evaluate your organizational structure and flexibility before taking the leap toward embracing pair programming. “Truly understand the benefits and challenges that come with pair programming and evaluate them against your existing commitments, product roadmap/timeline and team structure,” says Gonzalez. “What is the current situation of your engineering team delivering on features? Do you have co-located or remote teams? Will you have enough flexibility to roll out a pilot program?” All these factors need to be considered before jumping in head first.

And as always, remember humans are unique; it’s possible two developers won’t work well together at first, and you may encounter experienced developers who simply refuse to work with others. “If you have a flexible timeline, consider rolling out pairing in phases to collect data early about the team’s experiences, and to keep your team engaged and supportive of the change,” says Gonzalez. Evaluate your data to see how stories are completed in pairs versus unpaired. With numbers to back you up, you’ll feel more comfortable standardizing the program knowing it’s suitable for your organization.