We add the implementation to make the tests pass.

public void add( int card )
{
  if(card < 2 || card > 11)
    throw new IllegalArgumentException("Not a valid card value " + card);
  cards.add(new Integer(card));
}

Now however we have the same guard clause in Deck and Hand checking that the argument represents a valid card value. Our rules of simplicity say we need to remove the duplication but in this case it not as simple as an Extract Method refactoring⁶. When we see duplication across more than one class it is a good indication that we're missing some concept. Here it's quite easy to see that a Card class can take on the responsibility for knowing what values are valid and Deck and Hand become more communicative as containers of Card.

We introduce the class Card and refactor Deck and Hand accordingly, as shown in Listing B

public class Card { private final int value; public Card( int value ) { if( value < 2 || value > 11 ) throw new IllegalArgumentException( "Not a valid card value " + value ); this.value = value; } public int getValue() { return value; } } public class Deck { private static final int[] NUMBER_IN_DECK = new int[] {0, 0, 4, 4, 4, 4, 4, 4, 4, 4, 16, 4}; ... public void add( Card card ) throws IllegalStateException { if(NUMBER_IN_DECK[card.getValue()] == countOf(card)) throw new IllegalStateException("Cannot add more cards of value " + card.getValue()); cards.add(card); } public Card top() { if(isEmpty()) throw new IllegalStateException("Cannot call top on an empty deck"); return (Card) cards.get(0); } ... private int countOf(Card card) { int result = 0; for(Iterator i = cards.iterator(); i.hasNext(); ) { Card each = (Card) i.next(); if(each.getValue() == card.getValue()) result++; } return result; } } public class Hand { ... public void add( Card card ) { cards.add(card); } ... }

The test-code-refactor cycle involves different types of thinking at each stage. During testing the focus is on the interface of the class being implemented. Coding is getting the test to pass as quickly as possible. The refactoring stage can be thought of as a mini code review using the rules of simplicity for guidance. Is there any duplicated or similar looking code, not just in the current class, but in other classes in the system? What can go wrong with the current implementation and is it clearly communicated to users of the class?

Critical Success Factors

• Small steps â€" TCR is not an easy change for developers. Take it a step at a time and understand there is learning curve.
• Be disciplined â€" doing only TDD or only refactoring is not going to give you the real strides that the whole TCR cycle can achieve. Give yourself adequate time to try it and get the benefits. Pressure and deadlines can push the team back into old habits â€" be vigilant!
• Refactor the process â€" talk about how it is going get feedback from everyone on the team.
• Understanding â€" ensure that the team fully understands what TCR cycle is and how to do it. Considering getting training or a workshop together on the subject.

Pair Programming â€" Step 2
The TCR cycle can be done by a developer on their own, but the real power of Agile and the TCR cycle comes from pair programming. In Agile, developers write all production code in pairs, with one person acting as the "driver" (working the keyboard and mouse), while the other works with the driver in solving problems and looking at the bigger picture. The driver in the pair switches as necessary. Pairing allows you to address immediate goals, while always ensuring the overall project aims are kept in mind. It ensures that someone is thinking about the next place to go and the next problem to tackle.

Pair programming can cause a lot of controversy, yet is something most good developers do anyway, at least some of the time. Managers may believe that pairing reduces productivity, and while there is an initial dip in productivity as a team moves to pair programming, studies have shown that pairing benefits in terms of quality and increased productivity far outstrip developers working alone⁷. Developers on the other hand may see pairing as difficult as it is more intense in terms of interacting with people, and having another developer working on code with them. But it's also one of the best ways to create an environment of cross-learning.