A reflection on changing workplace practices I initially wrote this as part of my pair programming article but split it into a second post since I realised this is applicable for any workplace change. Some people thrive in a changing environment, others don’t, and a further group have more important things going on in their lives to spend energy on than your companies “Agile Transformation”. I have worked at three businesses during my career where pairing was the default practice.

Pair Programming For me, pairing is a key practice of Extreme Programming (XP). Pair Programming is a practice where two engineers work together to implement software. When pairing we take up the roles of Driver, the person typing, and Navigator, who is observing so they can focus on the higher-level concerns like the requirements, code design etc. The Driver and Navigator should swap roles regularly. These are what I expect to be the benefits of pairing:

Test-Driven Development (TDD) Martin Fowler describes TDD as the following: Write a test for the next bit of functionality you want to add. Write the functional code until the test passes. Refactor both new and old code to make it well structured. You continue cycling through these three steps, one test at a time, building up the functionality of the system. This cycle is known as “Red-Green-Refactor” Aiding high-quality design Using TDD encourages you to think about the interface(s) to the code before implementing those interfaces.