The pMD Blog

Welcome to the
pMD Blog...

where we cover interesting and relevant news, insights, events, and more related to the health care industry and pMD. Most importantly, this blog is a fun, engaging way to learn about developments in an ever-changing field that is heavily influenced by technology.

Weekly Byte: Increasing Team Productivity with Pair Programming

In the world of agile software development, when two developers work on a software task together at the same workstation, we refer to it as pair programming. On the surface, it might seem inefficient to have two people taking on the same thing at the same time. However, at pMD we’ve found, along with many other people, that not only is pair programming no less efficient than working solo, it is actually more productive and results in higher quality code.

While counterintuitive at first, consider the following: when working on a programming task, the majority of the developer’s time is often spent understanding the code that needs to be modified, and then thinking about a good way to implement a solution to the problem at hand. This implementation ideally should be easy to understand and it also has to be carefully analyzed to ensure it won’t break any of the existing functionality in the system. Working with another person on these items is often much more effective than working individually. This is especially true if one of the developers is more familiar with the codebase than the other, but just having a second person to bounce ideas off of is extremely helpful.

So, how does one do pair programming? First, identify the task that you want to pair up on and select a colleague on the development team to work with. Then, sit down with your pair partner at a workstation - ideally one with two large monitors! Plug in a second keyboard and mouse, and you’re good to go! Starting from the design and analysis phase, all the way through implementation and testing, pair programming is truly collaborative. When it comes time to actually write the code, each person should take turns implementing pieces of it, explaining what they’re doing as they type. The second developer should follow along, ask questions, and make suggestions.

I’ve mentioned before on this blog that when you’re working at a busy medical software company there’s never a shortage of software development work waiting to be tackled. However, we’re trying to be more diligent about resisting the urge to each go off on our own when we do our programming work. Instead, we want to embrace the mantra that when it comes to software development, two minds are better than one. We know that increasing the amount of pair programming we do will help us write higher quality code and produce even more features that our charge capture and secure messaging customers need.