How about a game of ping pong?

30 03 2009

How about a game of ping pong?

Out of all the XP tenants, Pair programming gets the most attention.

However, IMHO, I do not think Pair Programming works very well.

I have been using the Extreme Programming methodology (or Agile methodology for the conservative or Politically Correct managers out there) for about 8 years. I have seen many advantages with some of the tenants … but Pair Programming has always been a disaster.

I tried it several times with different pairs and it always resulted in:

  • Significantly longer development times
  • No real increase in code quality
  • Keyboard / mouse hogging (the most assertive developer ends up driving)
  • Frustration

See here for scientific findings on Pair Programming.

While working on some code the other day, I had an idea of how to improve pair programming. I like to call this approach Ping Pong Development (P2D).

The basic idea is that each feature is developed by 2 or more people. Note… DEVELOPED … not PROGRAMMED.

For example,

  • Two developers work on a new feature.
  • The first developer starts the work and completes a basic implementation
  • The second developer reworks implementation (and tightens things up).
  • The first developer then extends the feature to cover new use-cases.
  • The second developer writes additional unit tests.
  • The first developer presents the implementation to the team.
  • The second developer fixes issues raised during the testing phase.
  • The first developer carries out the performance tuning.

Each developer works independently (so there is no keyboard hogging and no increase in effort). However, each developer knows that his work needs to be understood and extended in the very near future to complete the feature. The work is sent back and forth between the developers (just like a ping pong ball) until the feature is complete.

The advantages are:

  • It puts positive pressure on each developer to produce high quality code (easy to understand, conforming to code standards, well documented, hack free).
  • Knowledge of every feature is spread amongst at least 2 people. There are always multiple sets of eyes to pick up problems.
  • Issues would tend to be bigger and of higher value than the small programming ones picked up by Pair Programming.
  • Issues would be picked up very early. For big systems, code can sit around for years before someone needs to understand it / change it / extend it. Using P2D, the code is looked at and improved hours after it was written.
  • Both developers need to have an excellent understanding of the feature. For many code reviews, the reviewer does not really understand the code. They end up finding superficial issues. With P2D, both developers need to have an excellent understand the code and the requirements to complete the feature. No extra code reviews are needed!!
  • It is not revolutionary, so it is easier to sell / implement. There is no reorganization of desks, doubling of estimates, added resource planning complexity, etc. From the management point of view, it is business as usual … except they get a higher quality, better understood code base implemented by a more cohesive team.

First there was Programming (P), then Pair Programming (P2), then Ping Pong Programming (P3) and now Ping Pong Development (P2D)…

Hopefully, I will get a chance to try this idea out. Let me know what you think of it.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: