Re: PG: Hackers and Painters

[Jerry Jackson <address@hidden>]

Bruce Lewis wrote:

> I thought that pair programming meant one person wrote code to perform a
> certain function, and the other wrote unit tests to make sure the first
> person's code was right.  In this case the first person is the clear
> "owner".
> 
> I agree with PG that things work best when there's an owner.  Other
> people provide feedback, even enhancements, but clearly delineated roles
> work best.
> 
> 

I've actually done pair programming on some projects.  I was pleasantly
surprised at how well it worked.  I did have the advantage of working
with someone really good, though.  It's definitely _not_ the case that
there is one owner and another unit tester.  In particular, when following
these methodologies, the unit tests are written before the code anyway.
The typical cycle is:

One person drives, the other watches.

1) Write a unit test.
2) Ensure that it fails.
3) Write code to make it pass.
4) Switch roles (i.e. hand the keyboard to the other person),

repeat.

I've only done this on particularly hairy internals of complicated systems.
In that situation, there's a big dividend in having more than one person
really understand the code.  I don't believe there's any good way to
pass on that level of understanding otherwise.

I believe most of the people with objections to pair programming haven't
tried it.  I was very sceptical before I tried it.  It's a lot like
an ongoing design discussion but more grounded in implementation reality.

On an ongoing basis, we don't do pair programming as a matter of course but
the test-driven development approach has totally changed the way we write
software.  I think it's safe to say that it's the most important new idea
in software that I've run into in the last 15 years.

Try it sometime.  It may change your life :-)

--Jerry