Nigel Cheshire

Subscribe to Nigel Cheshire: eMailAlertsEmail Alerts
Get Nigel Cheshire: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Thinking About Pair Programming?

None of the e-business technical staff went on-site; all work was performed within IBM's offices

Nigel Cheshire's Blog

Pair programming is a concept that has been around for a while and something I have heard good things about, although we have never actually come across any customers using it. This is probably because, in many organizations, pair programming would be too easily interpreted as “two people doing one job”.

When I worked for IBM, back at the start of the e-business phenomenon, the management of our group made a very uncharacteristic decision for the time (and as it turned out, a very wise decision). None of the e-business technical staff went on-site; all work was performed within IBM’s offices. The decision was based solely on the fact that this was a new area of the business where there was very little resource available, and practical experience was particularly scarce. Keeping everyone in the office allowed us to share resources and put them where they were most needed at any time. Of course pair programming, as we know it today, didn’t exist back then, but my understanding is that one of the key benefits of using pair programming and rotating the pairs is “fuller knowledge of the code base by all developers”.

That concept was particularly important back in the heady days of the mid to late nineties. At the time, many people would gain a year’s experience in a technology (at the time it was WebSphere, Java, JSP) and then leave to go freelance (or to another company) and make a lot more money.

Turnover was high, and handover was pretty minimal (usually just a list of outstanding items). However, due to the fact that almost everyone in the group had worked with everyone else on many of the projects, it was not necessary to go into a deep explanation of how classes mapped, or even what the architecture was – people knew. If we had all been around the country at different client sites, I know a lot of these projects would have missed deadlines.

So, even though our projects were rather informally structured, all of the projects I worked on for this group were delivered on time. Had we adopted Agile/XP/RUP or some other methodology to formalize the aspects of what we were doing, I am sure that would have led to even better quality applications being released.

Although what we were doing back at IBM wasn’t pair programming in the strict sense, it certainly gave me a first hand view of the benefits of having more than one person work on the same code. Before dismissing pair programming as a concept, you might want to think about how much stored knowledge about the projects you are working on walks out the door every night.

Email thisSave to del.icio.usDigg This!Stumble It!

More Stories By Nigel Cheshire

Nigel Cheshire is CEO of Enerjy Software, a division of Teamstudio Inc. He oversees product strategy and has been driving the company's growth since he founded it in 1996. Prior to founding Teamstudio, Inc., Nigel was co-founder and principal of Ives & Company, a CRM solutions consultancy. He holds a Bachelor of Science degree in computer science from the University of Teesside, England.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.