The conference will cover not only agile processes but also techniques that can be applied to projects to help make them more successful.
We’ve invited Dr Laurie Williams of Utah University to speak about her research on the subject of pair programming. Williams is one of the few academics researching agile methods and her data is helping drive the adoption of these practices across the world.
Williams’ research suggests that even students new to the technique can expect boosts in productivity of around 45% and a significant decrease in defects. Further, she has shown that pair programming is considerably more likely to lead to a finished product – given that all of the pairs in her study completed their work while a large number of singles didn’t. She has also run industry studies of the practice and found that it produces stunning results in the real world too.
While Williams’ research is very good, and necessary, it stops way short of examining all the benefits of pair programming. Of course, it doesn’t have to – increased productivity and quality should be enough for anyone – but other aspects like risk reduction, knowledge sharing, mentoring, team-building, knowledge synergy and others are bypassed. These are important aspects, but are more difficult to research.
Examine, if you will, the position most companies are in: of having a single “architect” who is the only person who understands the way all your software works and fits together. This is a very high-risk situation. Imagine what will happen if this individual is attacked by the psychotic bus driver who we all know is cruising the streets of Wellington and Auckland looking for poor, unsuspecting, senior architects to flatten like a pancake with his bus of death.
Tears, flowers, wake – for both the architect and the project he took to the grave with him (a very long, shallow grave, of course).
Pair programming saves us from this nightmare scenario, and thus considerably reduces risk. The knowledge that would otherwise be locked up in the head of the architect will have been disseminated among the team by the practice of frequently shifting pairs. Everybody knows something about everything. If you lose an individual you still have tears, flowers and a wake, but then you get back on with the project, having lost some knowledge but not a lot.
A client of mine recently used pair programming to reduce a project’s risk. She had a task assigned to a developer who had been on a Java training course around six months earlier and had no experience of it since then. Fortunately a developer became available from another team who had just taught himself Java. Neither of them had enough knowledge to complete the task. Put together, magic occurred – we also had them do test-first-development, and refactoring using IntelliJ Idea.
Close to the end of the task the project’s architect told them that there was a particularly subtle side-effect to the code they were writing that they’d have to clean up. They’d in fact noticed it days earlier and had already resolved the issue. The architect was blown away.
They finished their task in the allotted time, with no bugs. In my opinion, which was shared by the project manager and the project architect, neither of them would have been able to complete the task alone.
The client has now agreed to try pair programming on a larger scale and is looking for a whole project to try it on. Because of the nature of the client’s business structure, extreme programming can’t be implemented; however, XP is more than a process, it’s also a group of best-practice process patterns. We’re taking some of those patterns – pair programming, test-first-development, refactoring, continuous integration, frequent builds and 100% automated acceptance testing – and using them as enhancements to Rational's unified process to produce a custom agile process.
Another conference invitee is Steve Hayes from Melbourne, former head of global credit at Goldman Sachs on Wall Street. Hayes ran an XP team there for a number of years, with great success. He’s a great speaker and an experienced software developer with a lot to teach about running software projects in mission-critical environments.
I’d also like to invite papers from readers: if any of you have experience of an agile process and have something to say about it, let us know.
Dollery is a Wellington IT consultant. To have a paper considered for this event, email Dollery or the conference manager, firstname.lastname@example.org. Send letters for publication in Computerworld to Computerworld Letters.