Dueling Devs: A Pattern for Effective Pair Programming

We do a lot of Pair Programming at Acklen Avenue. From experience, we’ve learned that there are things we can do to kill pair programming, making it a complete waste of time. We’ve also, over time, developed some patterns that, for us, make Pair Programming what it REALLY SHOULD BE. I thought I’d share one of those patterns with you today.

One complaint some developers have about Pair Programing is that it can be boring. Well, that, in and of itself, is something that can kill pair programming after just one day. We have felt the same way at times, so we developed a pattern we call “Dueling Devs”. Later on, we found out that we re-invented the wheel and that others had been doing the same for some time under the name, “Ping Pong Programming”… but we like “Dueling Devs” better. Since we practice test-first development, “Dueling Devs” actually works a bit like a game. Here’s an example, using the following user stories:

As a plumber, I can fix the sink.
As a plumber, I will show my crack.
As a plumber, I can leave trash all over the floor.

(in-case there are any plumber-by-day, dev-by-night readers… these user stories are by no means based on fact)

And, meet our developers: Byron (that’s me) and John

Byron: So, today, we’re going to create a domain entity that has the behavior of a real-life plumber.

John: Great. Where do we start?

Byron: We can start with the first user story and see where that leads us. “As a plumber, I can fix the sink.” Seems pretty simple. John, why don’t you start us off.

John: Ok, here goes…

namespace RentAPlumber.Specs { public class when_a_plumber_fixes_a_sink { static Plumber _plumber; static Sink _sink; Establish context = () => { _plumber = new Plumber(); _sink = new Sink { Leaks = new List<Leak> { new Leak(), new Leak() } }; }; Because of = () => _plumber.FixSink(_sink); It should_ensure_that_the_pipes_do_not_leak = () => _sink.Leaks.ShouldBeEmpty(); } public class Sink { public List<Leak> Leaks { get; set; } } public class Leak { } public class Plumber { public void FixSink(Sink sink) { } } }

John: Tag, you’re it.

Byron: Great. We have our first failure. How exciting. Now to fix the leaks.

Byron: Hey, this plumber is good! Zero leaks. Now to put him to the real plumber test… “As a plumber, I will show my crack.”

namespace RentAPlumber.Specs { public class when_a_plumber_fixes_a_sink { static Plumber _plumber; static Sink _sink; Establish context = () => { _plumber = new Plumber(); _sink = new Sink { Leaks = new List<Leak> { new Leak(), new Leak() } }; }; Because of = () => _plumber.FixSink(_sink); It should_ensure_that_the_pipes_do_not_leak = () => _sink.Leaks.ShouldBeEmpty(); It should_reveal_the_plumbers_crack = () => _plumber.CrackShowing.ShouldBeTrue(); } }

John: And he calls himself a plumber! Let’s get him moving in the right direction.

public class Plumber { public bool CrackShowing { get; private set; } public void FixSink(Sink sink) { sink.Leaks.Clear(); CrackShowing = true; } }

John: There we go. A -real- plumber. Hmm. What’s next?

Byron: “As a plumber, I can leave trash all over the floor.”

John: Right. He can’t be a true plumber unless he leaves a mess.

public class when_a_plumber_fixes_a_sink { static Plumber _plumber; static Sink _sink; Establish context = () => { _plumber = new Plumber(); _sink = new Sink { Leaks = new List<Leak> { new Leak(), new Leak() }, Floor = new Floor { Trash = new List<Trash>() } }; }; Because of = () => _plumber.FixSink(_sink); It should_ensure_that_the_pipes_do_not_leak = () => _sink.Leaks.ShouldBeEmpty(); It should_reveal_his_crack = () => _plumber.CrackShowing.ShouldBeTrue(); It should_leave_trash_on_the_floor = () => _sink.Floor.Trash.ShouldNotBeEmpty(); }

John: So, because of that test, I had to create two new classes and add a Floor to the sink.

public class Floor { public List<Trash> Trash { get; set; } } public class Trash { } public class Sink { public List<Leak> Leaks { get; set; } public Floor Floor { get; set; } }

John: And a glorious failure…

Byron: To the rescue!

public class Plumber { public bool CrackShowing { get; private set; } public void FixSink(Sink sink) { sink.Leaks.Clear(); CrackShowing = true; sink.Floor.Trash.Add(new Trash()); } }

John: Done!

Byron: Great dueling with you.

In case you didn’t figure out what we were doing, Dueling Devs is where you each take a turn 1) writing production code to pass a test and 2) writing a failing test to drive out production code. Although not all applications involve plumbers and cracks, Dueling Devs makes pair programming fun and effective.

Awkward Coder

Learning to behave in public.

Dueling Devs: A Pattern for Effective Pair Programming