How To Support Pair Programmers

Pair Programming

Pair programming was another fantastic but contentious idea that emerged from the agile movement of the 1990s. Pair programming is when two developers physically sit and work together on the same code. There's typically a driver orpilot at the keyboard and a navigator sitting right next to him or her sharing ideas, giving advice, and taking notes. You see it more in web development than database development; however, it’s not uncommon these days to see data professionals succeed with this approach. I have personal experience in this area and I can attest to its effectiveness. I can also attest to the intense scrutiny that’s inextricably bundled these techniques. As a business analyst working with pair programming developers, it’s important to appreciate both. Here’s how you can help.

Provide a Buffer

One of your most important jobs is to help your coach or project manager provide a buffer between your developers and your users and other stakeholders. Pair programming is extremely polarizing. The people who get it are all in. The people who don't typically have a real problem with how it looks. If your team decides to use pair programming, your coach/project manager will be doing overtime to calm end users, leadership, management, stakeholders, and anyone else who sees what's going on. Since you spend a lot of time with your end users, it's your responsibility to help out. Insulate your developers from any sort of end user skepticism or criticism. They already have enough to deal with.

Colocate With the Team

Colocation (i.e., physical proximity) is an integral part of pair programming that should be extended to the business analyst. You should be physically located with the development team and spend as much time as possible with them. Of course, you can't spend all your time with developers because a good part of your job involves interfacing with end users. Fair enough, but in a pair programming situation, you must be more sensitive to the needs of your developers. Make them a priority. Be available as much as possible to clarify requirements and answer questions. This high degree of communication is what makes pair programming successful, especially when end users are difficult to access.

Join the Party

If you can be a third party in a programming cluster, by all means do it. I've often advocated that business analysts should be as technically competent as developers. If you fall into this camp, you can provide a great contribution to the development effort. The research shows that trio programming is not as incrementally beneficial as pair programming; however, it's not as bad as most would intuit. Trios will develop faster than pairs but the real bonus with having a business analyst in the mix is realized in functional quality. A programming cell that includes a business analyst has a much higher chance of meeting end user expectations the first time around.

Conclusion

In spite of its controversial nature, development teams are continually experimenting and succeeding with pair programming. Although it looks inefficient to the uninitiated, believers who understand and embrace this odd-looking practice enjoy the benefits of hitting the mark faster with good, clean code. As a business analyst, your role is vital. Heading off naysayers on the approach, colocating with the development team, and joining a pair to make a trio are all things that you can do to ensure the success of the team. Start today by working with your coach/project manager on your elevator speech to fend off critics. Then get ready for a fun ride–it's an experience you'll never forget.