Mob Programming: A 2009 Refactoring Case Study

In 2009, while leading the GoCD team, we practiced what is now called mob programming —a software development approach where the whole team works on the same task at the same time, in the same space, using a single computer.

Wikipedia defines mob programming as:

Mob programming (informally mobbing) is
a software development approach
where the whole team works on the same thing,
at the same time,
in the same space, and
at the same computer.
This is similar to pair programming.

In simple terms, the entire team tackles one task together, using one team, one active keyboard, and one screen (projector).

We called this practice “Team Pair‑Programming”. Over a two‑hour session in a small meeting room, with one computer and a projector, we refactored a module to address technical debt by introducing a missing domain object.

The main benefits were that everyone was on the same page, quickly understanding why a change was needed, what the code modifications were, and how the new domain concepts would affect future development.

Two essential prerequisites made the session possible: a powerful development environment capable of large‑scale refactoring, and comprehensive automated tests.

Our outcomes included:

Identifying a missing domain object and defining a refactoring technique.

Determining the presence of technical debt by observing that the code still worked but became cumbersome as features grew.

Presenting the original pseudo‑code:

public class A {
   @Autowired private BService b;
   public A() {
   }
   public doWork() {
       …
       C c = b.doSomething();
       …
   }
}

Through a series of Q&A, we discovered that class A (a domain object) incorrectly depended on BService , and that a new domain object D should be introduced, provided by EService . The refactored code became:

public class A {
   public A() {
   }
   public void doWork(D d) {
       d.doXXX();
   }
}

public class D {
   public D() {
   }
   public boolean doXXX() {
       …
       return m == null ? true : false;
   }
}

public class EService {
   public EService(…) {
   }
   public D findDByID(int id) {
       …
       return d;
   }
}

The method call was updated to:

a.doWork(eService.findDbyID(id));

This case study demonstrates how analyzing object lifecycles can reveal missing domain concepts, guide refactoring decisions, and improve code clarity and maintainability.