Recently I was working on some code. The code was trying to tell me many things, but I was not sure if I was understanding what it was trying to communicate. It just felt irrelevant or noise at that moment. Somehow the right level of abstraction was missing.

When I started I had:

1
2
3
4
5
6
7
8
9
10

private final UserService userService = createMock(UserService.class);
private final DomainNameService dns = createMock(DomainNameService.class);
private final RandomNumberGenerator randomNumberGenerator = new RandomNumberGenerator() {
    @Override
    public long next() {
        return 9876543210L;
    }
};
private final IdentityGenerator identityGenerator = new IdentityGenerator(randomNumberGenerator, dns, userService);
private final User naresh_from_mumbai = new User("naresh", "jain", "mumbai", "india", "indian");

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

@Test
public void avoidRestrictedWordsInIds() {
    expect(dns.isCelebrityName("naresh", "jain")).andStubReturn(false);
    expect(dns.validateFirstPartAndReturnRestrictedWordIfAny("naresh")).andStubReturn("naresh");
 
    expect(dns.isCelebrityName("nares", "jain")).andStubReturn(false);
    expect(dns.validateFirstPartAndReturnRestrictedWordIfAny("nares")).andStubReturn(null);
    expect(dns.validateSecondPartAndReturnRestrictedWordIfAny("jain")).andStubReturn(null);
    expect(userService.isIdentityAvailable("[email protected]")).andStubReturn(true);
 
    expect(dns.isCelebrityName("nares", "india")).andStubReturn(false);
    expect(dns.isCelebrityName("naresh", "india")).andStubReturn(false);
    expect(dns.validateFirstPartAndReturnRestrictedWordIfAny("nares")).andStubReturn(null);
    expect(dns.validateSecondPartAndReturnRestrictedWordIfAny("india")).andStubReturn(null);
    expect(userService.isIdentityAvailable("[email protected]")).andStubReturn(true);
 
    expect(dns.isCelebrityName("nares", "indian")).andStubReturn(false);
    expect(dns.isCelebrityName("naresh", "indian")).andStubReturn(false);
    expect(dns.validateFirstPartAndReturnRestrictedWordIfAny("nares")).andStubReturn(null);
    expect(dns.validateSecondPartAndReturnRestrictedWordIfAny("indian")).andStubReturn(null);
    expect(userService.isIdentityAvailable("[email protected]")).andStubReturn(true);
 
    expect(dns.isCelebrityName("nares", "mumbai")).andStubReturn(false);
    expect(dns.isCelebrityName("naresh", "mumbai")).andStubReturn(false);
    expect(dns.validateFirstPartAndReturnRestrictedWordIfAny("nares")).andStubReturn(null);
    expect(dns.validateSecondPartAndReturnRestrictedWordIfAny("mumbai")).andStubReturn(null);
    expect(userService.isIdentityAvailable("[email protected]")).andStubReturn(true);
 
    replay(userService, dns);
 
    List<String> generatedIDs = identityGenerator.getGeneratedIDs(naresh_from_mumbai);
    List<String> expectedIds = ids("[email protected]", "[email protected]", "[email protected]", "[email protected]");
 
    assertEquals(expectedIds, generatedIDs);
 
    verify(userService, dns);
}

As you can see, my first reaction after looking at this code was that there is too much going on, most of which is duplicate. So cleaned it up a bit and made it more expressive by

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

private final Context lets = new Context(userService, dns);
 
@Test
public void avoidRestrictedWordsInIds() {
    lets.assume("naresh").plus("jain").isNotACelebrityName();
    lets.assume("naresh").isARestrictedUserName();
 
    lets.assume("nares").plus("jain").isNotACelebrityName();
    lets.assume("nares").isNotARestrictedUserName();
    lets.assume("jain").isNotARestrictedDomainName();
    lets.assume().identity("[email protected]").isAvailable();
 
    lets.assume("nares").plus("india").isNotACelebrityName();
    lets.assume("nares").isNotARestrictedUserName();
    lets.assume("india").isNotARestrictedDomainName();
    lets.assume().identity("[email protected]").isAvailable();
 
    lets.assume("nares").plus("indian").isNotACelebrityName();
    lets.assume("nares").isNotARestrictedUserName();
    lets.assume("indian").isNotARestrictedDomainName();
    lets.assume().identity("[email protected]").isAvailable();
 
    lets.assume("nares").plus("mumbai").isNotACelebrityName();
    lets.assume("nares").isNotARestrictedUserName();
    lets.assume("mumbai").isNotARestrictedDomainName();
    lets.assume().identity("[email protected]").isAvailable();
 
    List<String> generatedIds = suggester.generateIdsFor(naresh_from_mumbai);
 
    lets.assertThat(generatedIds).are("[email protected]", "[email protected]", "[email protected]", "[email protected]");
}

By introducing a new class called Context and moving all the mocking code into that, my test looked lot more clear. I was also able to create an abstraction that could communicate intent much more easily.

Next I reduced the clutter further by creating another level of abstraction as follows

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Test
public void avoidRestrictedWordsInIds() {
    lets.assume("naresh", "jain").isNotACelebrityName();
    lets.assume("naresh").isARestrictedUserName();
 
    for (final String[] identityTokens : list(_("nares", "jain"), _("nares", "india"), _("nares", "indian"), _("nares", "mumbai"))) {
        lets.assume(identityTokens[0], identityTokens[1]).isNotACelebrityName();
        lets.assume(identityTokens[0]).isNotARestrictedUserName();
        lets.assume(identityTokens[1]).isNotARestrictedDomainName();
        lets.assume().identity(identityTokens[0] + "@" + identityTokens[1] + ".com").isAvailable();
    }
 
    List<String> generatedIds = suggester.generateIdsFor(naresh_from_mumbai);
 
    lets.assertThat(generatedIds).are("[email protected]", "[email protected]", "[email protected]", "[email protected]");
}

But at this point, even though the code ended up being very dense, it was very difficult to understand what was going on and why so. In a desperate search for simplicity and better communication, I ended up with

1
2
3
4
5
6

@Test
public void avoidRestrictedWordsInIds() {
    lets.assume("naresh").isARestrictedUserName();
    List<String> generatedIds = suggester.suggestIdsFor(naresh_from_mumbai);
    lets.assertThat(generatedIds).are("[email protected]", "[email protected]", "[email protected]", "[email protected]");
}

What is interesting about this is that I made some simple assumption saying:

• every name is not a celebrity name unless specified
• every user name is a valid (non-restricted) user name unless specified
• every domain name is a valid (non-restricted) domain name unless specified
• every identity is available unless specified

All these assumptions are now capture in my Context object and rest of my tests can happily focus on what really matters. I really liked the way this reduced the clutter in my tests without compromising on communication.

Last week I posted a small code snippet for refactoring under the heading Refactoring Teaser.

In this post I’ll try to show step by step how I would try to refactor this mud ball.

First and foremost cleaned up the tests to communicate the intent. Also notice I’ve changed the test class name to ContentTest instead of StringUtilTest, which means anything and everything.

public class ContentTest {
    private Content helloWorldJava = new Content("Hello World Java");
    private Content helloWorld = new Content("Hello World!");
 
    @Test
    public void ignoreContentSmallerThan3Words() {
        assertEquals("", helloWorld.toString());
    }
 
    @Test
    public void buildOneTwoAndThreeWordPhrasesFromContent() {
        assertEquals("'Hello', 'World', 'Java', 'Hello World', 'World Java', 'Hello World Java'", helloWorldJava.toPhrases(6));
    }
 
    @Test
    public void numberOfOutputPhrasesAreConfigurable() {
        assertEquals("'Hello'", helloWorldJava.toPhrases(1));
        assertEquals("'Hello', 'World', 'Java', 'Hello World'", helloWorldJava.toPhrases(4));
    }
 
    @Test
    public void returnsAllPhrasesUptoTheNumberSpecified() {
        assertEquals("'Hello', 'World', 'Java', 'Hello World', 'World Java', 'Hello World Java'", helloWorldJava.toPhrases(10));
    }
}

Next, I created a class called Content, instead of StringUtil. Content is a first-class domain object. Also notice, no more side-effect intense statics.

public class Content {
    private static final String BLANK_OUTPUT = "";
    private static final String SPACE = " ";
    private static final String DELIMITER = "', '";
    private static final String SINGLE_QUOTE = "'";
    private static final int MIN_NO_WORDS = 2;
    private static final Pattern ON_WHITESPACES = Pattern.compile("\\p{Z}|\\p{P}");
    private List phrases = new ArrayList();
 
    public Content(final String content) {
        String[] tokens = ON_WHITESPACES.split(content);
        if (tokens.length > MIN_NO_WORDS) {
            buildAllPhrasesUptoThreeWordsFrom(tokens);
        }
    }
 
    @Override
    public String toString() {
        return toPhrases(Integer.MAX_VALUE);
    }
 
    public String toPhrases(final int userRequestedSize) {
        if (phrases.isEmpty()) {
            return BLANK_OUTPUT;
        }
        List requiredPhrases = phrases.subList(0, numberOfPhrasesRequired(userRequestedSize));
        return withInQuotes(join(requiredPhrases, DELIMITER));
    }
 
    private String withInQuotes(final String phrases) {
        return SINGLE_QUOTE + phrases + SINGLE_QUOTE;
    }
 
    private int numberOfPhrasesRequired(final int userRequestedSize) {
        return userRequestedSize > phrases.size() ? phrases.size() : userRequestedSize;
    }
 
    private void buildAllPhrasesUptoThreeWordsFrom(final String[] words) {
        buildSingleWordPhrases(words);
        buildDoubleWordPhrases(words);
        buildTripleWordPhrases(words);
    }
 
    private void buildSingleWordPhrases(final String[] words) {
        for (int i = 0; i < words.length; ++i) {
            phrases.add(words[i]);
        }
    }
 
    private void buildDoubleWordPhrases(final String[] words) {
        for (int i = 0; i < words.length - 1; ++i) {
            phrases.add(words[i] + SPACE + words[i + 1]);
        }
    }
 
    private void buildTripleWordPhrases(final String[] words) {
        for (int i = 0; i < words.length - 2; ++i) {
            phrases.add(words[i] + SPACE + words[i + 1] + SPACE + words[i + 2]);
        }
    }
}

This was a big step forward, but not good enough. Next I focused on the following code:

    private void buildAllPhrasesUptoThreeWordsFrom(final String[] words) {
        buildSingleWordPhrases(words);
        buildDoubleWordPhrases(words);
        buildTripleWordPhrases(words);
    }
 
    private void buildSingleWordPhrases(final String[] words) {
        for (int i = 0; i < words.length; ++i) {
            phrases.add(words[i]);
        }
    }
 
    private void buildDoubleWordPhrases(final String[] words) {
        for (int i = 0; i < words.length - 1; ++i) {
            phrases.add(words[i] + SPACE + words[i + 1]);
        }
    }
 
    private void buildTripleWordPhrases(final String[] words) {
        for (int i = 0; i < words.length - 2; ++i) {
            phrases.add(words[i] + SPACE + words[i + 1] + SPACE + words[i + 2]);
        }
    }

The above code violates the Open-Closed Principle (pdf). It also smells of duplication. Created a somewhat generic method to kill the duplication.

    private void buildAllPhrasesUptoThreeWordsFrom(final String[] fromWords) {
        buildPhrasesOf(ONE_WORD, fromWords);
        buildPhrasesOf(TWO_WORDS, fromWords);
        buildPhrasesOf(THREE_WORDS, fromWords);
    }
 
    private void buildPhrasesOf(final int phraseLength, final String[] tokens) {
        for (int i = 0; i <= tokens.length - phraseLength; ++i) {
            String phrase = phraseAt(i, tokens, phraseLength);
            phrases.add(phrase);
        }
    }
 
    private String phraseAt(final int currentIndex, final String[] tokens, final int phraseLength) {
        StringBuilder phrase = new StringBuilder(tokens[currentIndex]);
        for (int i = 1; i < phraseLength; i++) {
            phrase.append(SPACE + tokens[currentIndex + i]);
        }
        return phrase.toString();
    }

Now I had a feeling that my Content class was doing too much and also suffered from the primitive obsession code smell. Looked like a concept/abstraction (class) was dying to be called out. So created a Words class as an inner class.

    private class Words {
        private String[] tokens;
        private static final String SPACE = " ";
 
        Words(final String content) {
            tokens = ON_WHITESPACES.split(content);
        }
 
        boolean has(final int minNoWords) {
            return tokens.length > minNoWords;
        }
 
        List phrasesOf(final int length) {
            List phrases = new ArrayList();
            for (int i = 0; i <= tokens.length - length; ++i) {
                String phrase = phraseAt(i, length);
                phrases.add(phrase);
            }
            return phrases;
        }
 
        private String phraseAt(final int index, final int length) {
            StringBuilder phrase = new StringBuilder(tokens[index]);
            for (int i = 1; i < length; i++) {
                phrase.append(SPACE + tokens[index + i]);
            }
            return phrase.toString();
        }
    }

In the constructor of the Content class we instantiate a Words class as follows:

    public Content(final String content) {
        Words words = new Words(content);
        if (words.has(MIN_NO_WORDS)) {
            phrases.addAll(words.phrasesOf(ONE_WORD));
            phrases.addAll(words.phrasesOf(TWO_WORDS));
            phrases.addAll(words.phrasesOf(THREE_WORDS));
        }
    }

Even though this code communicates well, there is duplication and noise that can be removed without compromising on the communication.

     phrases.addAll(words.phrasesOf(ONE_WORD, TWO_WORDS, THREE_WORDS));

There are few more version after this, but I think this should give you an idea about the direction I’m heading.

Consider the following code

1
2
3
4
5
6
7
8
9
10

    public static <T> String join(Iterator<T> itr, String seperator) {
        StringBuilder sb = new StringBuilder();
        while (itr.hasNext()) {
            if (sb.length() != 0) {
                sb.append(separator);
            }
            sb.append(itr.next().toString());
        }
        return sb.toString();
    }

When I read through this code, checking StringBuffer’s length and then appending a separator does not communicate the intent very well.

4
5
6

            if (sb.length() != 0) {
                sb.append(separator);
            }

Here we are relying on the side-effect (StringBuffer’s length) instead of asking the iterator. So the code does not flow smoothly. Also, now if you want to add a prefix to the joined String this logic might break.

IMHO, following code solves this problem.

1
2
3
4
5
6
7
8
9
10

    public static <T> String join(Iterator<T> itr, String seperator) {
        StringBuilder sb = new StringBuilder();
        while (itr.hasNext()) {
            sb.append(itr.next().toString());
            if(itr.hasNext()) {
                sb.append(separator);
            }
        }
        return sb.toString();
    }

Here is a sample of code (happens to be from a test) which I think is not communicative.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class ContactNumberTest {
  final String exampleCountryCode1 = "91";
  final String exampleCountryCode2 = "1";
  final String exampleNumber1 = "8012345678";
  final String exampleNumber2 = "2028569635";
 
  ContactNumber phoneNumberA = new ContactNumber(exampleCountryCode1,exampleNumber1);
  ContactNumber phoneNumberB = new ContactNumber(exampleCountryCode1,exampleNumber1);
  ContactNumber phoneNumberC = new ContactNumber(exampleCountryCode2,exampleNumber2);
 
  @Test
  public void testEquals() {
    //Symmetry
    assertTrue(phoneNumberA.equals(phoneNumberB));
    assertTrue(phoneNumberB.equals(phoneNumberA));
 
    //Reflexivity
    assertTrue(phoneNumberA.equals(phoneNumberA));
 
    //Not equals
    assertFalse(phoneNumberA.equals(phoneNumberC));
  }
 
  @Test
  public void testHashcode() {
    assertTrue(phoneNumberA.hashCode() == phoneNumberB.hashCode());
  }
}

I know you must be wondering why in the first place someone is writing tests for equals and hashCode. I agree. Its not required. But lets say someone really needs to.

This is how I would refactor the code to make it more communicative.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

public class ContactNumberTest {
  private final String indiaCountryCode = "+91";
  private final String usCountryCode = "+1";
  private final String cellNumber = "8012345678";
  private final String mobileNumber = "2028569635";
 
  private final ContactNumber indianNumber = new ContactNumber(indiaCountryCode, cellNumber);
  private final ContactNumber sameIndianNumber = new ContactNumber(indiaCountryCode, cellNumber);
  private final ContactNumber usNumber = new ContactNumber(usCountryCode, mobileNumber);
  private final Map<contactnumber , String> users = new HashMap</contactnumber><contactnumber , String>();
  private String userName;
 
  @Test
  public void isSymmetrical() {
    assertNotSame(indianNumber, sameIndianNumber);
    assertEquals(indianNumber, sameIndianNumber);
    assertEquals(sameIndianNumber, indianNumber);
  }
 
  @Test
  public void isReflexive() {
    assertEquals(indianNumber, indianNumber);
  }
 
  @Test
  public void isTransitive() {
    ContactNumber newIndianNumber = new ContactNumber(indiaCountryCode, cellNumber);
    assertEquals(indianNumber, sameIndianNumber);
    assertEquals(sameIndianNumber, newIndianNumber);
    assertEquals(newIndianNumber, indianNumber);
  }
 
  @Test
  public void areNotAlwaysEqual() {
    assertFalse(indianNumber.equals(usNumber));
  }
 
  @Test
  public void equalsIsExceptionFree() {
    assertFalse(indianNumber.equals(null));
  }
 
  @Test
  public void isHashFriendly() {
    addUser("Foo").usingKey(indianNumber);
    assertEquals("Foo", users.get(indianNumber));
    addUser("Bar").usingKey(sameIndianNumber);
    assertEquals(1, users.size());
  }
 
  private void usingKey(final ContactNumber number) {
    users.put(number, userName);
  }
 
  private ContactNumberTest addUser(final String userName) {
    this.userName = userName;
    return this;
  }
}
</contactnumber>

My 2 cents, based on personal experience:

• With TDD, I’m a lot more confident about my solutions. If I spot a design improvement, I can quickly jump in and fix it with confidence. When given feedback, I’m able to respond to it quickly. I feel I’m in control.
• It really helps me keep my design and code minimalistic and clean. No bells and whistles. No buy one get one free combo offers. <Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away>
• Turns out that my code is lot more easier to test. Because its designed to be testable. Lots of people argue that they will write tests after writing the code and it would be more efficient. The biggest problem I find with this approach is that the code ends up being something not readily testable. Then either I’ve to spend time making it testable or I skip testing saying its not possible or not required.
• It helps me build a safety net of executable, living, up-to-date specification for my classes and features. Its a great starting point for new team members to understand my software. Tests are a great reference point for someone who wants to use my code.
• TDD is a great teacher. It helps me listen to my code and learn from it. It forces me to pay close attention to what is happening. Its easy to spot bad things faster. Its all about feedback and visibility.
• TDD forces me to slow down and think. It encourages me to take baby-steps. Sometimes I find people are in such a hurry that they spill mess all over the place. It takes soo much more time and effort to clean up the mess they leave behind.
• My tests tend to communicate my design choices much longer after I’m gone.
• I massively reduce the amount of time I spend in the debugger or trying to manually test (monkey test) from the UI. When something breaks, I no longer need to crawl through the logs to figure out where things are going wrong. I get pin-pointed feedback.
• TDD helps me maintain focus on measurable outcome (producing software that accomplishes a concrete objective). I’m not longer drifting down ratholes.
• TDD also helps me reduce the hand-overs between developers and tests and hence the wastage introduced because of all that overhead and context switching.
• And so on…

Having said that, TDD alone is not sufficient to achieve the above. At times you need to spike/prototype things. One needs to have (or at least start focusing on building) a good knowledge of Design Principles and Patterns. Its easy to get lost, having a pair can really help.

Again I don’t want to sound dogmatic. I don’t think TDD is the only way to build great software. There are lots of great developers out there, building amazing software without TDD. However I think TDD is a much easier approach to achieve the same.

Yesterday, I spent some time cleaning up Acceptance Tests on a project which exposes some REST APIs.

Following is a snippet of one of the tests:

1

Response response = REST_API_call_Using_Wrapper Which_wraps_xml_response_in_a_response_helper_object;

1
2
3
4
5
6
7
8
9
10

Assert.IsTrue(response.HasHeader);
Assert.IsTrue(response.HasMessageId);
Assert.IsTrue(response.Has("X-SenderIP: " + senderIp));
Assert.IsTrue(response.Has("X-SenderDomain: " + senderDomain));
Assert.IsTrue(response.Has("X-recipientDomain: " + recipientDomain));
Assert.IsTrue(response.Has("X-SPF: " + spfValue));
Assert.IsTrue(response.Has("X-1stClassification: " + firstClassificationResult));
Assert.IsTrue(response.Has("X-2ndClassification: " + secondClassificationResult));
Assert.IsTrue(response.Has("X-3rdClassification: " + thirdClassificationResult));
Assert.IsTrue(response.Has("X-MANUALLY-CLASSIFIED: " + manuallyClassified));

As you can see there is a lot of duplication (Assert.IsTrue is basically noise). It’s also not very clear what the intent of those assert is.

Since Response is a Test Helper class. We thought moving the asserts on the response makes sense. But we also want to make sure the person reading this test understands that we are verifying a bunch of things on the response object.

Since we are using C#, we could do the following using a Delegate.

1

public delegate void ThingsToBeVerified();

1
2
3
4

public void AssertThat(ThingsToBeVerified codeBlock)
{
  codeBlock();
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

response.AssertThat(
  delegate{
    response.HasHeader;
    response.HasMessageId;
    response.Has("X-SenderIP: " + senderIp);
    response.Has("X-SenderDomain: " + senderDomain);
    response.Has("X-recipientDomain: " + recipientDomain);
    response.Has("X-SPF: " + spfValue);
    response.Has("X-1stClassification: " + firstClassificationResult);
    response.Has("X-2ndClassification: " + secondClassificationResult);
    response.Has("X-3rdClassification: " + thirdClassificationResult);
    response.Has("X-MANUALLY-CLASSIFIED: " + manuallyClassified);
  }
);

Now that we got the asserts out of the way. The following things stand-out as redundant:

• The repeating response word
• The semicolon at the end of each line
• The ‘: ” + ‘ in each Has call

So we got rid of the delegate and used Method Chaining (fluent interfaces) instead. (Other samples of using Fluent Interfaces in Tests)

1
2
3
4
5
6
7
8
9
10
11

response.AssertThat.It
                      .HasHeader
                      .HasMessageId
                      .Has("X-SenderIP",senderIp)
                      .Has("X-SenderDomain",senderDomain)
                      .Has("X-recipientDomain", recipientDomain)
                      .Has("X-SPF", spfValue)
                      .Has("X-1stClassification", firstClassificationResult)
                      .Has("X-2ndClassification", secondClassificationResult)
                      .Has("X-3rdClassification", thirdClassificationResult)
                      .Has("X-MANUALLY-CLASSIFIED", manuallyClassified);

Now the Has call and the parentheses looks redundant. One way to eliminate that is by using Operator overloading, something like:

lets.checkThat(response).HasHeader.HasMessageId.Has + "X-SenderIP" = senderIp + "X-SenderDomain" = senderDomain
        + "X-recipientDomain" = recipientDomain + "X-SPF" = spfValue + "X-1stClassification" = firstClassificationResult
        + "X-2ndClassification" = secondClassificationResult + "X-3rdClassification" = thirdClassificationResult + "X-MANUALLY-CLASSIFIED" = manuallyClassified;

We have not implemented this, but technically its possible to do this.

Yeah, Yet Another Blog on Pairing and Pair Programming.

Question. What are the disadvantages of Pairing?

My experience with pairing has been good so far. I‘m not too sure if I can really point out disadvantages. But here are some things to be aware of.

1. One thing that does bother me a little is, it can get into the way of your creative thought process sometimes. But most of the times, I‘m happy with the end results.
2. Some people also complain about the trashing of ideas that goes on when people pair. It might feel like the pair is wasting a lot of time just abstracting arguing about the approach or their understanding of the problem at hand. Again, this is not really a disadvantage of pairing. Any time you have more than one person, there will be differences in their perception and approach. According to me, it better to clarify them sooner than later. Usually if the pair cannot converge on one approach, one of them drives [implements] her/his approach. If it works, they move on, else the other person drives her/his approach. Lot of times they come up with a 3rd solution which is better than both individual approach.
3. There might be other interpersonal issues that could arise while pairing. But its better to resolve them rather than ignoring them. And it‘s not unique to pairing. Any team activity would have the same issues. A good example that comes to my mind is ego clashes between people. It‘s better to resolve it rather than letting it grow.

Couple of things one should remember:

1. Pair programming is not about typing code. If you have watched a really good pair programming session, there is very little typing and more of communication/discussion. Designing good systems is not about typing code, it needs a lot of brainstorming. No I‘m not suggesting big upfront brainstorming sessions. You need Just-In-Time brainstorming. Closer to the time of implementation. Also people often under-value the feedback they get from code. Everyday I learn from my code and from other people on my team.
2. Pairing is not just limited to programming. We do a lot of cross-functional pairing. Developer pairing with the Business Analyst to write automated acceptance tests. Developers pairing with QA to recreate bugs. QA pairing with BA to do exploratory testing and so forth.

Question. Some people do not want to pair program, they are lone contributors and pairing slows them down, they just stop thinking, they feel less productivity. How do you deal with this? Can we possibly reduce pair programming hours? May be ask people to work separately for 2 hours and sit for 30 minutes to pair program.

Like any skill/habit, people take time to learn it.

When I was in University, the natural thing to do for me was to work with others [Profs and students]. I learned programming by working with other students [pairs]. Once I joined a software company, I was given a sound-proof cubical. I drifted on my own and after a while I got used to working on your own. Changing this habit back to working with another person took some time [a week or two]. But the people I was pairing with were really good and there was a motivation to pair with them. After that I don‘t see “the pair slowing me down“ thing happening much.

Every single time I‘ve worked with a team, “lower productivity” comes up as the first argument against pairing. Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. Since testing and debugging are often many times more costly than initial programming, this is an impressive result. There have been a lot of other studies, which prove that lower productivity due to pairing is a myth.

While we are on the topic of productivity, let me back up a bit. How do you define productivity? Amount of work done in an hour or day or sprint/iteration? This looks short-sighted. We are talking about software project which has a life span bigger than hours or days or sprints/iterations. Shouldn’t one consider, UAT bugs, production bugs, support calls, ramp up time for new team members, maintaining all kinds of crazy documents, etc?

Faster learning, better communication, collective code ownership, shared understanding, evolutionary design, better estimates, continuous code review, etc all go hand in hand with Pair programming.

So I would strongly discourage people working separately for 2 hrs and pairing for 30 mins as a regular practice. I would reverse the time.

Often on teams, people want time to check their emails, answer some calls, go to meetings, etc. These things do come in the way of pairing 8 hrs a day. So what we do on most teams is to have core-pairing hours.

For Ex:

• 08:50 : 09:00 – We have our stand up meeting
• 09:30 : 12:30 – We have the first core pairing session.
• 12:30 : 02:00 – People are free to do other stuff and lunch.
• 02:00 : 03:00 – Any team meetings if required.
• 03:00 : 05:30 – We have another pairing session.

Sometimes we have another stand up at 5:30.

So in an 8 hr day, we at least have 5.5 hrs of pairing. Remember pairing can be very intense and it could drain you out. So its usually not recommended to pair for more than 8 hrs everyday.

There is always going to be resistance to pairing. The biggest reason I have found so far in 10 years is, fear of exposing how much one knows to others. My theory is, usually junior people are much open to pairing, coz everyone expects that they don‘t know much and they don‘t really have any fear of exposure. Also they feel they can learn much faster that way. On the other hand, people who want to hide in their cubical will always resist it with irrational/unacceptable reasons.

The best thing to do is have an open team discussion on this topic. Challenge people in front of the whole team. Ask for facts.

IMHO, Pair programming is not effective in the following cases:

1. If you don‘t have a team room and team members are not sitting at a common table. If people go back to their cubical and try to pair, it is usually not effective. Most cubicles are built for one person to sit in. Trying to fit 2 people in there, mean one person is always going to look over the shoulder of the person driving.
2. If your are not following Promiscuous pair programming. If your pairs are not swapping frequently [at least once a day], then you are going back to old ways of programming. Instead of one person now you have 2 people. So what? You need more pair of eyes. You need collective code ownership and not pair code ownership. Please note Promiscuous means “making relatively unselective, casual and indiscriminate choices.”  Pod cast and Slides.
3. If developers are not involved in estimation and planning. If there is no collective ownership and self-organization.
4. If you already have spend more than 30% of your project budget on BIG UPFRONT DESIGN. And if you have architects on the team who don‘t want to pair but just want to create fancy documents and throw it over the wall.
5. If your manager assigns tasks to the pairs

Question. Some people want to pair program, but they do not pair well, i.e. though they are looking at the same computer but they are actually planning a vacation, i know this may sound ridiculous but it happens. How do you deal with this?

Talk to them. Very very important. Understanding their issues is most important. You cannot afford any communication gap.

Encourage them to try ping-pong pair programming.

Question. Where can we find a demo of good and bad pair programing?

At the end of the Programming With the Stars @ the Agile Mumbai 2010 conference, based on public demand, J. B. Rainsberger and yours truly did a 6 min public demo of Pair Programming. We started with an Ugly Pairing session, trying to show-case some pairing anti-patterns.

Followed by a normal pairing session:

Question. What does a really good pair programming experience feel like?

When each programmer has an implementation/design in mind, but in the process of pairing we end up with a 3rd, much better solution. The collaborative attitude and mutual respect amongst the pairs is very important.

Question. What does a really *bad* pair programming experience feel like?

When wavelengths don’t match and each programmer just wants to prove their point. Or Programming with someone who just does not care about the craft. If I was coaching them, these might be a good opportunity to educate them, but when trying to rapidly build world class products we don’t have time for this. Hence these are bad experiences from a pairing point of view, but good from coaching point of view.

Question. What setup makes pairing experience enjoyable? Both sharing one machine? Both sharing a single keyboard, mouse & screen Or Two keyboards, two mice & two screens?

I’ve paired for 10+ years now and based on that experience I don’t think any of these things matter. The attitude of the pairs matter exponentially more than the set up.

Question. In your good pairing experience, what best describes how you worked together?

1. We were both focused on the code, and probably shared the keyboard fluidly.
2. We were both focused on the code, and passed the keyboard according to a system (like ping-pong or popcorn pairing)
3. One pair sat back and watched while the other coded, and we traded occasionally
4. One pair did research or worked on something else while the other coded

While pairing, coding is a very small activity. What is most valuable is discovering an approach/solution through collaboration. Hence I would say who code does not really matter to me any more, as far as the pairs agree on the approach and then constantly inspect and adapt the approach.

Question. Some tasks do not seem fit for pair programming at all, they are too routine/mundane to have a pair work on them. Do you see this happening?

I often hear research, reading a book, searching on the net, learning new technology, documentation, etc. fit into this category.

I do most of these along with my pair and I find it really helpful and fast.

For Ex: While searching for something on the net, one might go to Google and start entering their search criteria. I often spend a lot of time refining my search criteria. While, when I‘m pairing, we discuss the search criteria, refine it and in the process always come up with a better search criteria, than the one I would have come up with myself.

Documentation is another very good example. Documentation is very similar to programming to me. There is something in your head, that you want to communicate. By working with a pair, one can ensure that what is been documented/expressed, is understandable by at least one other person. You might be making a lot of assumptions that are not clear to other people. Hopefully your pair will challenge some of those assumptions, leading to more understandable documents and hence better quality of the document.

I tend to pair on all these tasks, coz there is some knowledge involved in these tasks. I would like my team members to be aware of how to accomplish similar tasks later.

One of the things I have noticed in the past is, if its a single person trying to do these kind of tasks, they might be motivated to just manually do it and get done with it. Or sometimes, they might spend days together coming up with a framework to accomplish the task. But if a pair is working on it,

A [one of them] might say, “you know what, we might want to create this thing again and again, lets just quickly automate this“.
B might say, “but automating this might take 4 times more time than what we have estimated for this“
A: “Really, I was just thinking of writing an ant target to do this“
B: “Ohh…Yeah that‘s a good idea. But I‘m not very well versed with Ant“
A: “I have done some work with Ant, so I think we can get this done in 30 mins“
B: “Excellent! Lets get rolling”

You see…whenever there is learning involved, quality of end product is much better. Never under-estimate the outcome of 2 brains at work.

Question. What about remote pairing?

Since I’ve started working for Industrial Logic, I’ve spent a lot of time time pair programming with folks in the US. Yes, we do Remote Pair Programming.

Quite a few people have asked me:

• What special editor or tool we use for remote pairing?
• How effective is the pairing?
• How much time is spent in setup each time?
• How long does it take for one to get used to remote pairing?

Here is my answer:

The most important part of pairing is free flow of ideas between the 2 individuals. Its about the brains of the 2 individuals being at the same wavelength so communication can truly take place. Tools can certainly disrupt or get in the way of this flow. But IMHO the individuals contribute 80% towards the success of the pairing experience, tools contribute 20%. Skype with Video Sharing lets us achieve 80%. Better tools might improve that. We’ve experimented with some Eclipse based plugins, all of them have their trade-offs. There is no clear winner. Also on our team since we’re all used to Skype for conference calls, the threshold to get started is very low. So my recommendation is to get started with simple tools, something that you are already familiar with. When starting anything new, focus on the crux and not on the peripheral stuff.

Question. Won’t Pair Program kill our Productivity?

Often I find developers and managers who claim they understand the advantages of Pair Programming and are bought into the concept, but they are really concerned about loss of productivity.

This morning when I watched the following video, I thought, we could use this as an excellent example of what pairing can help you achieve.

My premise:

We are in the business of building software and this process requires craft and skill, rather than a series of manual steps. Programming requires lot of thinking, creating abstractions, figuring out the logic and trying out things. Its an evolutionary, iterative and collaborative process. Its a lot more than just typing code using the keyboard (or even worse, using the mouse).

If you resonate with the philosophy stated above, then you should be able to understand how pair programming can make it easier or more feasible to create master pieces that could be extremely difficult or rare for one individual to single-handedly create.