QualityDev.net

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.

Reading Joseph Ottinger’s blog; “Scary thought: maybe those who say they can’t do TDD are right” I would think that any development manager or newbie looking to implement TDD would be pretty concerned about some of the comments made, particularly this one:

“Most developers do *no* TDD at all. It’s about time we started listening to these people instead of trying to lecture them.”

Obviously this is a controversial issue. It can quickly degenerate into a tirade of arguments about why TDD would or would not work in certain organizations and types of projects.

The obvious thing I see here is an education issue. TDD is a big topic with plenty of reference material available on the web, and people interpret different parts of it in different ways. Sure, some people may have had bad experiences with TDD depending on the culture of the organization, especially if they are not fully committed to a TDD approach, which can quickly result in them slipping back into more traditional development methodologies. Or, from a technical standpoint, some organizations find it difficult to implement a TDD approach in, say, an embedded environment.

However, the organizations I have seen that have successfully implemented a TDD methodology are the ones willing not only to invest the budget to train people in TDD and its culture, but to have the patience to work through the first months of hurdles and issues due to the different way of thinking that TDD requires.

The whole ‘agile revolution’ is not a silver bullet, but there are an increasing number of reports and case studies (for example: Success Rate of Agile Software Development in Agile Magazine - Spring ed. or http://www.objectmentor.com/omSolutions/agile_customers.html ) on many projects that show an increase in the number of projects being delivered on time and at a higher quality level. TDD is a big part of this revolution.

There are various ways to implement TDD, and a number of different keys to success. A simple favorite of mine is this: if a bug is reported, write a unit test to prove the bug exists. Once the unit test passes, the bug will be eliminated and should never re-occur [assuming you run all unit tests as part of your integration build].

A reference work I see on the desks of nearly all customers I visit is Michael C. Feathers’ “Working With Legacy Code”, which has many examples of applying TDD to legacy projects, rather than only new projects, something that was missing from a lot of last year’s conference topics when discussing TDD, in my opinion.