Extreme Programming Practices
I’ve been practicing Extreme Programming (XP) for over twenty years. It’s an agile software development methodology that promotes taking good software practices to the extreme in order to provide maximum benefit.
For example, we know that writing tests is good; XP developers take testing to the extreme by writing tests for everything, and writing tests first. We know that code review is useful; XP developers take code review to the extreme by pair programming, which results in instant, continuous code review.
Other practices include daily stand-up meetings, weekly planning meetings, continuous integration, small releases, collective code ownership, and sustainable pace.
The Daily Diff
One practice that isn’t part of XP but that fits in nicely is the daily diff. I was first introduced to it by my friend and former boss Greg Woodward. It’s a 10-20 minute exercise that is performed daily and familiarizes the team with all the changes happening in the codebase. That familiarity is important when practicing collective code ownership. I can’t count the number of times I’ve said while programming, “hey, didn’t we see something in diff the other day…”
I’ve practiced daily diff primarily with teams of 6-10 people. With much larger teams, it would presumably be very time consuming, and few people would have enough context to understand most of what they were seeing. Larger teams are often split into sub-teams; it’s probably best for those sub-teams to have their own daily diffs.
Step 1: Gather Around A Computer
Each morning, the entire team gathers around a computer. I’ve used a few different configurations over the years: a 27” iMac connected to a second 27” monitor mirroring the iMac’s built-in screen, an iMac connected to an 80” 4K TV, and a laptop sharing its screen over Zoom with a bunch of remote developers.
Step 2: Choose A Driver
I’ve found it useful to have a different person running diff each day. My favorite way to choose a person is to write each person’s name on an index card and randomly pick one. The stack of index cards also comes in handy for quickly deciding who will kickoff the daily standup meeting, who will lead the weekly retrospective meeting, and for choosing pairs for the day by randomly choosing cards in groups of two.
Step 3: Open The Diff
Daily diff is about looking at all the code that was changed since the last time diff was done (usually yesterday). Some diff tools and editors can show a side-by-side diff of multiple commits to see all the changes at once. GitHub’s web diff can do this, but only shows the changes in each file rather than the entire file that was changed. I personally prefer the full-file diffs but GitHub’s web diff is simple to use and is often good enough.
When working on a team that is working on multiple projects at the same time, I diff each project separately.
Step 4: Briefly Discuss Each Change
When a change shows up on the screen, the person or people who made the change or know something about it can very briefly explain why the change was made, or mention something interesting about the change. If a similar change was already discussed, or if the change is obvious, there’s no need to make a comment. People who weren’t involved in the change can use the opportunity to ask questions or to give praise. It’s not the place for negative criticism or for detailed discussions.
I have found the daily diff to be a valuable part of my daily software development practice and I recommend that everyone try it. Like everything, it might not be a good fit or might need some adjustment for your particular situation.