Tidy First and the art of not sweeping the whole house

I think a lot of people have the problem that when you open that messy file up, and you just want to change one line, but one hour later you have changed the name of half the variables and reorganized all the functions and still haven’t changed the line you wanted. It seems productive, mostly it’s really just a fancy way of procrastinating.

Tidy First? by Kent Beck is a book about that exact moment, the one right before you change some messy code. Should you clean up first? His answer, roughly, is “often, a little, and in a separate change.” It came out in October and it’s short enough to read in one sitting, which I did, on a couch, with a cup of tea going cold.

It’s a list of little cleanups. A page or two each. Guard clauses instead of conditionals. Removing dead code. Making similar code look the same. Moving a declaration close to its first use. Extracting a helper. (Or, reversing it - putting back some spread out stuff into a lump again if it’s causing confusion). Nothing really new. It’s just like someone listing all the things you have to do. (Motivational somehow).

Favorite is probably the guard clause because that’s something I already do. Nice to be validated.

// Before
function shippingCost(order: Order): number {
  if (order.items.length > 0) {
    if (!order.isPickup) {
      return rateFor(order.address) * order.weight;
    }
  }
  return 0;
}

// After
function shippingCost(order: Order): number {
  if (order.items.length === 0) return 0;
  if (order.isPickup) return 0;
  return rateFor(order.address) * order.weight;
}

The second part is about how to actually practice this without it eating your week. Keep tidying in its own pull request, apart from any change in behavior. Keep batches small. Tidy in short bursts, minutes, maybe an hour. And if you notice you’ve tangled tidying and behavior together in one change, consider throwing it away and doing it again in the right order. That last bit made me wince, in the way good advice sometimes does.

He’s also clear that you tidy the code you’re about to change, not whatever code happens to offend you. That one line would have saved me a lot of the afternoons I described up top.

The third part is theory, and it’s the part I keep chewing on. Every change is either to behavior or to structure. Behavior is what people pay for. Structure is what makes the next behavior change cheaper. Money now beats money later, which argues for shipping the feature, but options have value too, which argues for keeping the code easy to bend. And the cost of changing software, he says, is mostly the cost of coupling. I like that framing a great deal. I also noticed it stops just short of telling you what to do on a given Tuesday. The real answer to the title question turns out to be “it depends,” with some very good reasons for what it depends on. I was fine with that. Some readers won’t be.

Here’s where I got a little skeptical, though. Separate tidying pull requests are lovely if someone reviews them quickly. If a pull request sits for a day waiting on a reviewer, nobody is going to open three of them for one feature. They’ll bundle the tidying in, or skip it, and honestly, who could blame them? The practice itself costs almost nothing. The review habits it leans on are a team thing, and those are harder to come by than a book can fix.

And also, it’s the first of a series (or at least it sounds like it), and so feels like the first chapter. The larger issues (team-wide design, design over years, etc) are gently avoided.

I’m going to take a stab at smaller pull requests for a while, and see if people notice. (The tea was actually completely undrinkable.)