Quick, Often, and Clean

Karl M asks:

More refactoring please! What techniques do you find yourself using? What do you love about it? Aesthetics? Patterns? ‘Craftsmanship’?

The phrase that’s stuck with me over the years is “ratcheting in the gains.” I first encountered it in a programming context sometime around 2002. I don’t remember where anymore, but it was probably in one of the XP books. I’ve carried that idea with me and used it as an ideal for years.

You see, the biggest problem I’ve seen on software projects I’ve worked on is moving in the wrong direction. When schedules slip, it’s not because we haven’t been moving forward fast enough, it’s because we’ve actually been moving backward. Developers break existing code without realizing it all the time. Unless, of course, they have a ratchet.

In the physical world, a ratchet is “a mechanical device that allows movement in only one direction.” In software, it’s something that makes sure that your changes are not breaking existing functionality. Having a comprehensive regression testing suite is the answer most developers have to this problem. That is necessary but not sufficient.

Refactoring and other agile software techniques recognize that in order to act as a ratchet, regression testing has to happen at the same frequency as coding. The cycle time of your test feedback needs to be roughly equal to — if not less than — the amount of time it take to make a code change. Running the tests, seeing them clean, and committing the code to version code is what setting a ratchet point is in software. Until you’ve done all three, you can still move backwards.¹ After that, you’ve always got a known good point.

Another critical piece in ratcheting in the gains is setting those ratchet points as often as possible. I’ve seen material that indicates Agile developers commit code to version control ten times more often than non-Agile developers, not because they work ten times as fast, but because they see how to split the work into slices ten times as thin. I’ve seen my coding undergo exactly this transformation over the last year as I’ve started to use refactoring and TDD more effectively. Last week I did in six steps what I used to do in a single shot, because I’ve seen the value of being able to revert at any point. It’s like setting chocks while climbing: The closer together you set them, the less far you can fall.

The third critical ingredient that turns a regression test suite into a ratchet is the attitude that the tests always have to run clean. There’s no such thing as a “known failure.” If a test fails, you stop the line and fix it. If your tests are comprehensive, fast, and run often but you let them fail, you’re letting yourself move backwards.

Having that ratchet, climbing with those anchor points, is probably the thing I love most about refactoring. I can make changes to code much more quickly than I could before. Some people think that it’s odd that one of the XP values is courage, but my experiences over the last year have shown me why. In order to respond to changes — to truly be Agile — we have to have the courage to make quick changes to our code. It’s not foolish bravery, because we’ve taken the right precautions. We’ve made sure that we can’t go backwards, only forwards.

Update

Fitness:
Writing:

fn1. There really is a fourth step, which is seeing everything run clean in the production environment. Getting these three in place is still quite an accomplishment for a lot of teams and developers.