One of my takeaways from the Agile Conference last year was the need to learn how to divide work into as small a chunks as possible. In Alistair Cockburn’s Elephant Carpaccio tutorial, he presented an interesting statistic: programmers using Agile software development techniques commit code to their revision control systems ten times more frequently than programmers who don’t. That’s not because they work ten times faster; it’s because they see how to slice their work into pieces that are ten times thinner.
As I’ve been using these slicing techniques more and more in the last year, I have felt like the frequency of my commits has gone up. I did an experiment last week where I measured the time between my source control commits, just to see how big a chunk of work I was biting off each time. It turned out that over the course of a three-hour programming task, which represented adding a small new feature to the same code base I was working on yesterday, I was committing my code to the repository an average of every twenty-five minutes. The variation wasn’t high either; that was just the natural rhythm I fell into — and it felt good. I’d do the Red-Green-Refactor loop a few times until it felt like I had a substantial enough milestone to check in, commit it, and then take on the next chunk. I was developing this code in parallel to the existing code, so I kept everything working at all times. It was only in that last chunk that I switched over the main code path to using the new functionality I’d developed, and because of the way I’d put it together, the switch was easy to make. It was one of the most satisfying programming experiences I’ve had.
Which makes it particularly ironic that I utterly failed to apply these techniques yesterday, resulting in things going bad. But I’ll save that story for tomorrow.
UpdateFitness: Rest day
Sun, Moon, and Stars: 305 words, 390 seven-day average, 287 average, 53026 total, 26 past the goal for the week; 7-day streak