For nine months now Corey Haines has been travelling around the Eastern US as a journeyman programmer. During that time he has run numerous code retreats, published numerous fantastic interviews with leading developers, and made dozens of blog posts and videos in which he reflects on the things he’s learned from the people he’s paired with. The body of Corey’s travails is already beginning to form an invaluable reference, and all of the insights he has pushed into the public domain add to our collective knowledge about how to develop software carefully (in both senses of the word).

Just as amazing as the project’s knowledge elicitation is the fact that Corey is self-funded. He pair programs for food and lodging, and just by doing that he has given back an enormous amount to the community. Well, now he’s skint. The journey will continue only if Corey can raise some funds.

So please visit Corey’s blog and pledge a few quid to keep the journeyman on the road. I did, and it didn’t hurt a bit.

And next year, Corey, how about we raise the cash to get you over to the UK for a tour?

Pair Programming is a technique where two developers work on the same piece of code at the same time. Popularized by Extreme Programming, it had been applied long before.

One team that applies it consistently can achieve several benefits, such as:

• Reducing the risk of Overengineering: one person is more likely to over engineer solutions when left alone, than when having a partner to keep you grounded on the problem at hand.
• Reducing bugs: a partner reading the code is more likely to catch bugs than a the person coding, who is usually focused on the current line of code, and not on the overall context.
• Improving Quality of Code: refactorings are easier to accomplish safely when one person is not focused on actually performing the refactoring and therefore can focus on ensuring the step is safe and checking for further refactoring opportunities. Also, the methods, modules, class names, functions and variables names are readable by at least two people’s standards.
• Knowledge Sharing: this is one of the biggest benefits of Pair Programming because when developers are pairing, they share several kinds of knowledge:
  • Business Knowledge: even if not doing DDD, the developers communicate about the problem on a business level, what concepts are important, the business rules, and so on.
  • Technical Knowledge: such as frameworks, object libraries, platforms, ORM frameworks, databases, programming languages and tools that are being used, or could be used, on the project.
  • Theory Knowledge: a software project is not just solving business rules. From time to time, more abstract concepts are needed to solve a problem, and developers can teach each other about concepts such as concurrent programming, aspect oriented programming, design patterns, architectural patterns, graph theory, boolean algebra, security and cryptography, regular expressions and formal languages, problem complexity, software design…
  • Project Knowledge: how the project works, how it is deployed, how to access the subversion (or any other SCM), how and which methodologies are applied, how bugs are tracked, and so on. It also includes the knowledge of the history of project decisions such as: why was this library used instead of that other one, why this algorithm was selected, why this architecture is being used, which other frameworks were evaluated…

  In order to allow the knowledge to be shared among all participants, it is vital that pairs are constantly changed within a team. How often if very dependent on the size of the team, the features being tackled, and the team’s willingness to change it more or less often. All these types of knowledge sharing brings some other nice advantages: it gives the project less risk, as no single part of the code can only be changed by only one person (specially useful when this one person would be vacation, sick in a hospital, or leaves the project). Also, gives more confidence for the team to employ Collective Code Ownership, it allows the team to be more productive over time, as less of the basics is needed to be explained and more pairs can tackle a issue where only a specialist would be able to otherwise, and finally the team as a whole can estimate better the size of features to be implemented (let it be story cards, tasks, or old-fashioned use cases), as everyone is more aware of the code base and the difficulty of problems to be tacked.

Other benefits of pair programming (an in-depth analysis can be found here paper) include: improved morale, fewer interruptions, more team focus and higher productivity. It is also important to note that a team cannot pair program all day, as people usually have other tasks to attend, such as meeting’s, training, reading and responding emails, drink coffee.

This technique can be hard to actually apply, as many developers are not used to pairing, managers are afraid of it costing more (two people working on the same machine can never be more productive) and not everyone work well with such constant peer review and collaboration. Agile Methodologies value individuals and interactions over processes and tools, and this is quite critical when employing Pair Programming, because these difficulties (which may exist in varying degrees) can only be surpassed as long as the team (including managers) is willing to overcome it. Implementing it incrementally (maybe only a few hours a day, and building it up and the team sees the benefits) can ease the resistance, and the team can get experience with it while incrementally discovering impediments of pairing more often. Also, applying Coding Standards first can diminish the occurrences of pairs fighting about minor issues such as whether to use underscore or camel case. Also, if a team struggles in the beginning, mostly managing who codes and who observes, the variant Ping Pong Pair Programming can be easier to begin with. However, it implies Test Driven Development, which can be tricky to begin if the team doesn’t do it already.

Pair programming is a great technique, one that is usually overlooked even by agile teams (as Rachel Davies was able to see on some projects she coached). But with so many potential benefits, it is always worth giving it a shot.

Me and a Simone, both at the Software Craftsmanship mailing list, tried out an experiment in doing remote pair programming today.

NUnit

Since both of us are comfortable with C# and NUnit committing this first infrastructure-experiment to using that combination felt the right way to go.

GMail

To do this experiment we started by having gmail chat as a base for all other communication channels. Next step was to get audio working via Skype. Both of these tools worked hassle-free.

Skype

Then we turned our attention to desktop sharing. Simone had looked up some alternatives yesterday, and we tried out Teamviewer first.

Teamviewer

Teamviewer was fast and easy to use. But sadly the free edition just ended after ten minutes.

Sharedview

So we tried the free SharedView from Microsoft. This turned out to be too slow, with mouse movements showing up after about 0.5 to 1 seconds.

We gave up on the desktop sharing idea, and focused on a second approach. In that approach we share only the source files via googlecode. Googlecode uses SVN for source code sharing, and both me and Simone used TortoiseSVN to synch the files.

Googlecode

TortoiseSVN

I added Simone to one of my already existing projects to get going fast.

Then we took turns writing unit tests and production code, committing changes as we went along.

TDD Problems

All along we kept communicating via Skype.

We choose one of the smaller problems from the TDD-problems* site, the Template Engine.

Online stopwatch

To measure time we used online-stopwatch.

One problem was that I used Visual C# Express edition, while Simone used Visual Studio professional, and there were conflicts between  .csproj/.sln file formats. We solved this issue by only doing edits in one file, so to avoid this hassle.

All in all we spent almost two hours trying these things out. It was not hassle-free, but that we didn’t expect either. It was an experiment. You can see some of the resulting code in two of the screenshots nearby.

View from my computer

Template engine class

We decided to try more another time. One idea is trying the gobby multi user editor, and maybe using python or ruby instead of C#.

* If you’d like to contribute to the TDD-problems site, please drop me or one of the other contributors a mail or leave a comment on this blog post.

Tags: programming, tdd, pairprogramming, software craftsmanship

John De, President of N-Brain, has to say this about pairing:

… I discovered that two heads really are better than one. Developers have different ways of interpreting code, and different ways of solving problems. Combining this rich diversity creates a strength unequaled by any single developer. Put me in a room with a junior programmer, and turn us loose on some task, and I guarantee you that I will gain new insight into the problem from this developer, and that our resulting solution will be stronger than anything I could have come up with alone.

Read full interview here: http://java.dzone.com/news/interview-john-de-goes-free-un.

I’ve recently been TDD-ing on a project in which I had to very quickly come to understand a lot of new technology (libraries, development tools, target environment, patterns, techniques). Pair programming with a local expert was the natural approach, but it wasn’t working particularly well until I started doing the driving. I did learn a little while my partner (the expert) had the keyboard, but it’s not easy staying alert and focussed when you understand very little of what is happening. On the other hand, as the driver I was much more engaged; and my partner was perforce more engaged in helping me understand. I’m sure it must have been frustrating for him having to tell me even the simplest stuff, but after only a short time I found I was able to contribute more and more to the task. I’m still a long way behind my partner’s expertise, and yet I feel we can now work reasonably effectively as a pair.

I’ll try to remember this next time I’m the one with the knowledge: let the novice learn by driving.

I’ve just been working with a team which has a pairing policy: every item of code must have been seen by two pairs of eyes before it can be checked in. It doesn’t work.

The effect of the policy is to replace pair programming – instead developers do a “pair check-in” at the end of each development episode. So a developer will beaver away working on a feature for a day or so, getting it right, making it work, passing all the tests. And then he’ll call over to another team member to request a “pair check-in”. The other team member comes to the developer’s station and is walked through the changes in the version control tool. And then the code is checked in and the two team members part company again.

The problem here is that the process sets the two people up to be in opposition: the developer is effectively asking for approval, instead of asking for help. It’s natural for the developer to feel a sense of ownership, because he’s worked hard to get that code complete and correct. Not many people can graciously accept negative feedback after all that hard work.

It can also be hard for the reviewer – the “second pair of eyes” – to come up to speed quickly enough. The developer knows these changes intimately, but the reviewer is being asked to understand them cold. He has little chance of being effective in that situation.

So this process has all of the demerits of Inspections, with none of the advantages. The team would be more effective adopting true pair programming, I feel.