[Sussex] This months BCS Sussex Group Lecture

[Geoffrey John Teale]

Hi Thomas,

On Sun, 2004-11-07 at 20:52 +0000, Thomas Adam wrote:
> I'd be interested in how you find that approach. Unfortunately Brighton
> is too far away for me, otherwise I wouls have gone. I'm currently
> looking at ICONIX and working in teams to get various tasks done, at
> Uni. 
> 
> Perhaps you can describe what the process is like for you?

OK, well it's really just part of the processes we use.  We're vaguely
based around an eXtreme Programming process, but we're not really doing
it as the books say any more, we've evolved into our own way of doing
things.  Loosely however, we get work broken down into "stories", mostly
written by "customers" (in practice "customers" are business leaders
within the company who are a point of contact with an external
customer).  We split work into iterations with a bigger development
target (a release).

At the start of each release we sit down as a team and review the
requested "stories".  After that meeting we usually split up and each
developer will flesh out a story into tasks that need to be completed.
Then the team comes back together and estimates the stories.  

Having estimated the stories we then work out with the "customers" which
stories we can fit into the iterations (trying to do the most important
bits first).

Once that's all done work commences - a developer will take the lead on
a story and will pick another developer to pair with him (this can be
dictated by resources, but we try hard to rotate and make sure that
everybody gets a handle on what's going on).

Pair work as an experience varies a lot depending on who you're working
with - everybodies style is different.  Hoewever a few key things
usually happen:

 - one person focuses on the fine detail of what you're doing, the other
thinks more about the wider goal.
- the person not typing (or "driving" as its known) usually picks up on
simple mistakes and typos as you go.
- the temptation to cut corners is usually beaten down by the least
fatigued of the pair.

When we develop we write a test framework first, before we produce any
part of the implemenation we ensure these tests represent defined goals
(a given set of output and side effects for a given set of input and
environmental conditions).  This can seem like a lot of work to the
unitiated developer but it pays massive dividends  when you have to
revisit the code later.  When you change functionality you can often
just change the tests and the run them, making incremental changes until
you eventually have fully working tests again.  This helps breed
confidence in the code and saves a massive amount of time.

Speed is an interesting issue.  Combined knowledge means less time spent
working things out, but more timre spent discussing the right way to do
something.  We also spread knowledge about the product by pairing, and
this means that should one of us be away for any reason we're not
missing part of the product knowledge should it be needed.  This process
also makes it less painful to take on new staff.  We have a code base
that exceeds 80,000 lines of product code (python) a few thousand more
lines of test code (python) plus at least one C program, a large base of
bash scripts, many debian packages and a suite of XML, XSLT and DTD
code.  Learning this code base to any productive level takes several
months, but during this period a new developer will always be paired
with an experienced staff member - this way they get introduced to the
code base as a whole alongside someone who knows it well, yet they're
nearly as productive as an experienced pair (the quality is almost
definitely not as good as an experienced pair, but much better than the
new guy working in his own). 

On the whole I'd say we're definietly slower than we would be working on
our own, but we spend much lest time dealing with errors than we would
do if we worked alone - it's hard to say what would be fastest overall,
but I know it's more fun doing green field development that bug fixing!

Now, there are obviously problems - the biggest one is what happens if
you employ the wrong people.  Pair programmers need to be active,
intelligent and have strong ideas and opinions.  However it is equally
important that they are able to accept when someone else has a better
idea and move on.   We had one guy (no names mentioned) who just
couldn't deal with having to work in a pair, and having to write tests,
he found it infuriating because he was used to doing his own thing and
always getting his own way.  I think that for this reason it's probably
easier to build a development team around pairing rather than force it
upon an existing team. 


-- 
Geoffrey John Teale <tealeg at member.fsf.org>
Free Software Foundation