Pair Programming: When Should You "Shoulder Ship It"

Pair programming isn't a new concept but it is one that can still be a hard sell. This post goes into some more details on why it can be so important.

· Agile Zone · Opinion

Pair programming is no new topic and has been widely used in the industry. At first, it might seem like it’s waste of time because two coders work in the same station. However, it provides values like team building and less defective code.

Although code reviews provide a degree of control with written code, a second person makes sure nothing goes off the rails. The practice is to have one half of the pair review the code while the other writes it. Thus, code doesn’t need further code review. So, that’s what I and others call "shoulder ship it."

I believe having a second eye is important in some cases. Nevertheless, I don’t see much value in pairing constantly because some (min. half) part of the software would be trivial.  I’ll list cases where I think "shoulder ship it" can take place.

  • Somebody New. S/he can learn existing stuff and bring a completely new perspective.
  • Critical Production Bug. It might be necessary to do a quick fix. In this case, a second eye is very important. Although acting rapidly on these cases is important, you become more vulnerable because of stress. So having a pair would decrease possible mistakes.
  • Vital Components. Some components are more important than other. Whenever you feel like you are dealing with heart of your application, support from your colleagues might be indispensable. By pair programming, you offload some heavy lifting to your pair so that you don’t get drowned.

There might be other examples but these are the most common scenarios I’ve encountered. Happy shoulder ship its!

Published at DZone with permission of Yusuf Aytaş, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.