Arkadin Montpellier has been using pair programming in its R&D department for several years now. According to Moïse Zapater, the site’s Development Director, the formula for pair programming is simple: “When two experts work together, 1 + 1 = 3. By working in pairs, two programmers challenge each other and that results in better coding in real time”.
Pair programming is an agile software development technique which involves placing two programmers at a single workstation with just one screen, keyboard, and mouse between them. The programmer at the keyboard writes code and is usually called the “driver”, while the other is called the “observer” or “navigator” and reviews and perfects each line of code as it is typed in. The two programmers switch roles frequently.
Getting to know you
When pair programming works, it can create higher quality code and help solve problems faster. But for pairing to work, the pairs themselves have to work. And that isn’t always evident.
Moïse explains that pairing is particularly useful when implemented with new recruits. “It shortens their introduction period into the company by giving them a new problem to solve right away. They’re paired with a more experienced programmer whom they’re allowed to challenge from the start.” The more experienced programmer will probably know more and work faster. But the new recruit might well have acquired skills and insights the other programmer hasn’t, or simply be able to bring a fresh eye to a problem.
Most of the programming at Arkadin Montpellier is done by programmers working alone; pairing is only used about 20% of the time, particularly on small fixes where the solution is easy to find, or when speed becomes essential. But pairing is also effective in resolving difficult issues, as working alone usually proves to be too time-consuming.
What happens if there’s a clash between any two programmers? “We find that egos tend to eventually balance themselves out”, says Moïse with a laugh.
A new “Definition of Done”
In agile companies, the tasks of programmers and developers have specific end results, or targets. At a certain point, each team member must be able to say “I’m done.” But what does “done” actually mean in our context?
A Definition of Done (called a “DoD” for short) establishes what must be true of each item for that item to be considered as done. Classic developers usually limit their DoD to the purely technical aspects of a job. But today, Arkadin Montpellier is changing all this!
“My role as an ‘agile manager’ is to provide global perspective and vision to each team member with a final target of end user satisfaction”, says Moïse. “Given this objective, my ideal DoD would simply ask: ‘Because my goal is to make my customers happy, what must I check to ensure this result?
“The response should be a mix of technical verifications, as well as verifications of the satisfaction of our internal clients (i.e. sales force, marketing…), thereby enabling validations of their own objectives.
“By not limiting the Definition of Done to a purely technical item list, we try to enhance the context understanding of software engineers and release them from repetitive technical checks”, concludes Moïse.