“Adversarial Programming”

I am not talking about having two coders, each of which is trying to destroy the other’s life and career, being chained together and forced to pair. What I am talking about, though, is an idea to add to the list of pairing/mobbing options that exist.

One of the typical rules observed in any multi-programmer paradigm is that there is one and only one driver. That one person at the one keyboard is the only one who presses the buttons and makes the magic appear on the screen. What if we did something different than the one-driver rule?

I’m proposing doing just that. But instead of just having two different people at two different keyboards clicking away madly, we merge in ideas from TDD. In this case, one of the keyboards is writing tests, the other is writing code. Tests are an expression of requirements; code fulfills those requirements. As functionality develops, tests can be written to expose possible corners where behavior may not be as desired. Tests try to break, code is refined to fix. The adversarial back-and-forth creates a rhythm that should have an optimizing effect upon the process.

This could also be fruitfully extended to a mob programming context (and may, in fact, work better there). There would still be two drivers, but the other members of the team would be making contributions as appropriate.

[I’m looking forward to an opportunity to implement this, at least in the small. I’l report back.]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s