Is pair development the new way to do development, is it the goose with the golden eggs, or is it just another way to write software…
Well I think, as always, that the truth lies somewhere in between. But first things first: pair development, for me at least, goes beyond only development. It is a technique that can be used for lots of things: for development, for designing, for infrastructure changes, even for activities way beyond the scope of an IT department. I’m thinking about activities like cooking or crafting, as long as there is a creativity aspect and is involved. In all those cases two minds working together will provide way better results than single minds working in separation.
What is pair development?
But what is pair development exactly?
Well, let’s take the example of the developer. In that case we need two developers (obviously), one computer and one clear defined piece of software to work on. The first developer takes place at the keyboard and does the actual coding (the driver) and the second developer observes, checks the code and keeps the bigger picture in mind (the observer).
Advantages of pair development.
The duality between the low level view of the driver and the high level view of the observer makes it easier to spot mistakes and correct them early, which makes code-reviews unnecessary and speeds up the production readiness of the product. The driver and observer switch roles on a regular base to keep them focussed and to prevent fatigueness.
Another advantage, besides the early spotting of bugs, is the fact that both developers immediately have the same level of knowledge of the piece of software, meaning there is no need for costly knowledge sharing sessions. This leads to a climate where the developers can challenge their pairs knowledge, and where they can challenge each other by writing tests to break their pairs code. In the next iteration, when the developers switch roles, the issue gets (hopefully!) fixed and a new, possible even harder test is written.
Pair development leads, for different reasons, to a higher velocity. Teams can deliver more value in the same amount of time. In other words, pair programming leads to faster benefits of the time invested by the developers! And that will lead on his hand to a shorter development time. The shorter development time, in combination with the lower amounts of bugs, will hopefully increase of the trust of the management. A higher trust that can lead to a more pair development proof company, or even an introducing of pair development principles in complete other departments like HR, housing or even the management itself.
How to facilitate pair development?
To be able to create a fertile atmosphere for pair development, not only the management has to trust the developers, but the developers should also trust their pairs. Pairs typically spend a lot of time in close alignment. They should know each others ins and outs, they should both be open to each other and respect their pairs privacy at the same time. Only that way pair developers can be vulnerable, can drop their egos and start working together in a close and trustfull combo.
In such a combo partners should respect each other, and the basics are, as always, most important. Pairs should use gentle language, and they should not interrupt each other. It is important to take the time to listen to each other and to explain things when they are not clear, even more than once. And perhaps the most important of all: nobody owns the code and (especially!) nobody created the bugs…
I also think it is very important that pair development stays a choice for the developer, it should never be mandatory. Some developers won’t be able to behave well in pair development and will work better in separation. That does not mean that we can not try to convince these developers of the benefits, but at the end the developer has to do it by himself or herself.
Conclusion
Is pair development the solution to everything?
I don’t think it will work in all cases, but it is a very satisfactory way of working that can lead us a big step in the right direction…
Gert Driljeux (38) studeerde in een vorig leven Wiskunde en gaf zelf even les aan een middelbare school. Bij toeval kwam hij terecht in de informaticawereld en ontdekte dat dit eigenlijk zijn roeping was. Momenteel werkt Gert bij De Lijn in Mechelen aan een project om het online verkopen van tickets te optimaliseren.
Gert Driljeux
Software Crafter
Gert Driljeux studeerde in een vorig leven Wiskunde en gaf zelf even les aan een middelbare school. Bij toeval kwam hij terecht in de informaticawereld en ontdekte dat dit eigenlijk zijn roeping was. Momenteel werkt Gert bij De Lijn in Mechelen aan een project om het online verkopen van tickets te optimaliseren.
