Pair Programming and Quad Programming
|
|
This article is written by Dave
Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers
on agile .NET projects and has extensive experience in agile development techniques, particularly
Test-Driven Development. Dave can be emailed at
davechaplin@byte-vision.com.
Date:
Wednesday, June 04, 2003
Abstract
Pair Programming is one of the key practices of Extreme Programming. Pair
Programming is when two people sit side by side next to a single computer to
code an engineering task. Quad Programming is with 4 people in one room with a
projector. This articles discusses experiences of both Pair Programming and
Quad Programming.
Overview of Pair Programming and Quad Programming
Pair Programming is when 2 developers sit at one computer to complete an
engineering task. One person is the ‘driver’ who types, and the other is the
‘navigator’ who monitors the broader picture of what they are building (design
aspects) and manages the development road map. The roadmap is a list of tasks
that need completing to finish the task. You can think of it as being similar
to rally driving. The driver is very focused on the immediate task in hand,
like driving around a corner, whereas the navigator is checking out the road
ahead, planning tasks, and ensuring the driver is going in the right direction.
Quad programming is when you have one driver and 3 navigators and everyone sits
around a computer which is projected onto a screen. Quad programming is good
for team training, particularly around new architectural areas when they are
introduced.
Benefits of Pair Programming
Design problems are caught earlier by the navigator, rather than letting a
single developer go seriously off track and build all sorts of wonderful stuff
that no one wants! Bugs are caught earlier simply because you have two people
looking at the same screen. On the whole the quality is significantly higher
because investment is made in quality assurance (before things are built),
rather than quality control (after things are built). In the short term studies
have shown that it takes 2 developers 2 thirds of the time to build something
that would normally take one developer to build. In theory, although no large
studies have been done, due to the quality gains early on, the overall cost of
development using Pair Programming is less than that if the tasks were single
programmed.
Who To Pair Together
There may well be certain types of individuals in your team, ranging from
students to experts. I would describe a student as someone who is knows syntax
well, but not design too well. An expert knows the syntax and is a good
technical architect and designer.
Expert Navigator, Expert Developer
A good pairing. Whilst the one expert is busy typing in the current thoughts
for development, the other expert cant sit back and think about the overall
picture. They can also give the code a once over to see if any obvious bugs
have been injected. The perfect pairing with good productivity gains.
Novice Navigator, Expert Developer
Bit of a waste of time this one. The navigator spends all their time trying to
grab the wheel, and get involved with the driving, whilst struggling to come up
with anything useful in terms of design. They can send the driver all over the
place and they often fail to even draw a road map of where they should be
going. It results in the driver having to do all the navigation and
development, whilst at the same time teaching the navigator why they have done
it. Swap the roles around. Or, do detailed design on a whiteboard beforehand so
you have a clear road map written out.
Expert Navigator, Novice Developer
This is the best way to train new developers on the team. The expert navigator
needs to be careful though not to simply pull the novice developers strings and
literally tell them what to type. If all the navigator does is focus on syntax
then they aren’t navigating and the pair programming is not as productive as it
could be. The expert needs to be a good communicator and teaches in this
patient role.
Novice Developer, Novice Expert
Strongly advise against this. A complete waste of time. It is the blind leading
the blind. Both will be focused on syntax rather than design issues and
refuctor the existing code base. [Refuctoring = ruining the internal code base
of the system when adding additional functionality. Also known as introducing
code smells.] The developers may well get the development done but are unlikely
to implement the functions of the tasks in the correct areas of the
architecture. They will also not spot opportunities to refactor. The moral of
this story is don’t have more than half your XP team as novices. If you do,
then forget XP and do big model up front.
Experiences Of Quad Programming
This section explains my experience of using Quad programming as a means to
train the team and also build a solid foundation on which to base further
development.
We employed an architect to develop an architectural spike (prototype) for the
presentation architecture of the system. We did three iterations before
agreeing on a strategy. The spike proved that certain designs were feasible but
the prototype code was by no means production quality code and wasn’t built
using Test Driven Development [Please take note project managers in a hurry!]. It wasn’t intended
to be. At that point I decided to try Quad Programming to code the first user
story with the entire team.
The motivations were:
-
Everyone in the team could learn the proposed presentation architecture.
-
Everyone in the team could learn how to write tests for proposed layers of the
architecture.
-
The architecture was single person programmed, and three extra pairs of eyes
would add additional quality to the design.
-
We wanted to get very good quality first time, as a good foundation to build
on.
-
It needed to be written 100% test driven to ensure it was fully testable.
We built the system one test case at a time until we had built the first user
story, albeit stubbed out with mock objects at the mapping/persistence layer.
The code was written 100% using Test
Driven Development , without a single line of code being written
without a failing test driven.
It took 4 people 2.5 weeks to build it whilst locked in one room with no
distractions, one PC, and a projector. There were around 1000 lines of
production code and 900 lines of test code with 104 automated tests which ran
in just under 2 seconds.
This was approximately 3 months ago. Unfortunately the team reduced to 3, but
since that time the application now has 8,500 lines of production code, and
7,500 lines of test code. The tests now number 304 and take 14 seconds to run a
full regression test of the web application.
What did we learn from Quad Programming?
The quality of the code was second to none. Not a single design got through
without serious debate. On occasions we spent an entire day on the code base
and produced less than 100 lines of code. Other days we would make a decision
and just hammer the solution out. The code was the highest quality any of us
had ever seen. Although we had to make enhancements as the application
progressed, the investment in getting the separation of concerns right in the
first place made the enhancements that much more easier.
The whole team knew why we had built what we had built. As often in design
sessions there is enormous value in the discussions had in getting to the
result, rather than the final result itself. The ‘why’ has tremendous value in
addition to the ‘what’. These benefits are not realised with the ‘big model up
front, throw it over the wall approach’. Thus, in further discussions about
design, everyone knew what the responsibilities of each layer were. It
simplified the decisions later on about where to place responsibilities in the
code. I suppose this is where the XP metaphor is supposed to help.
Due to the intent of the design, the speed with which we could fully regression
test our web application was much higher than in previous projects. Previously
we had automated the testing of the application by automating the IE browser
via a plug in we wrote for NUnit. This proved slow in the past taking up to 25
minutes to run. Now, because of our new architecture, we could plug tests in at
any point and simulate http requests using our mock httpContext. Granted, this
wasn’t a direct result of Quad Programming per se, but more as a result of
having myself, ‘Mr Test Infected’, with a great architect to realise my
testability ambitions.
In terms of the pace of Quad Programming versus Pair Programming, Pair
Programming is faster, but you quality is lower. In the short term I would
suggest the payback is from the quality of the code base and also from the
education it gives to the team. Long term as an activity I don’t feel it would
be justified unless a major piece of architecture was added to the system. I’d
advise staying with Pair Programming once the team understands the
architecture.
Debugging during the sessions was sometimes tough, since you would get 4 people
shouting out ideas at the same time. This was similar when we approached a
problem where it was obvious the design was wrong. Again, all 4 people would
try and get their point across at the same time. It required some mediation
between those in the team who were more assertive than the others. It was very
easy for 3 people to switch off and think about their solutions to the problem
whilst the other person spoke into space thinking they were being heard. Again,
this required some self mediation.
Another aspect to watch was ensuring that everyone in the team understood why
certain decisions were being made. Since, that was one of the main reasons for
exercise. This meant careful watch of the less design aware team members to
make sure they understood. Often the experts got carried away and wanted to
rush off, and they needed holding back so the others could understand.
Still, on the whole an extremely worth while exercise that has benefited the
whole team. I would strongly recommend the approach to any team attempting a
Greenfield project using XP
Closing Comments
Good luck in your developments and roll on XP!
Dave Chaplin
Other Articles
Test Driven Development (Dec 2003)
The Losers Olympics (Sep 2003)
Making Projects Succeed: Part 1 - Measurable
Business Goals (Sep 2003)
Pitfalls In Software Development (June 2003)
Extreme Web Architectures - Testing Web Applications In
Seconds (June 2003)
Pair Programming and Quad Programming - From
Experience (June 2003)
Making Extreme Programming A Success (April 2003)
Contractual Test Driven Development (TDD with DBC)
(April 2003)
Moving To XP (Feb 2003)
Maximising Development Productivity (Dec 2002)
Writing Automated Browser Tests Using
NUnit and IE (Oct 2002)
Mitigating Requirements Risk With Agile
Practices (Oct 2002)
10 Tips for Successful Team Leading (Oct
2002)
Developing Automated Using Tests Using NUnit 2.0
With VB.NET (Sep 2002)
Quality By Design - Part 1.doc (May 2001)
Quality By Design - Part 2.doc (May 2001)
Quality By Design - Part 3.doc (May 2001)
Other Resources
NUnit
http://www.nunit.org/
http://sourceforge.net/projects/nunit/
Extreme Programming
http://www.extremeprogramming.org/rules/testfirst.html
http://www.extremeprogramming.org/index.html
Refactoring
http://www.refactoring.com
Agile Modelling
http://www.agilemodeling.com/
|
