Tidy First?: A Personal Exercise in Empirical Software Design

by Kent Beck

Those of you familiar with refactoring will see great similarity between refactorings, defined as changes to structure that don’t change behavior, and tidyings. Tidyings are a subset of refactorings. Tidyings are the cute, fuzzy little refactorings that nobody could possibly hate on.

“Refactoring” took fatal damage when folks started using it to refer to long pauses in feature development.

They even eliminated the “that don’t change behavior” clause, so “refactoring” could easily break the system. Let’s see: no new features, possible damage, and not...

Reorder the code in the file in the order in which a reader (remember, there are many readers for each writer) would prefer to encounter it.

Sometimes the increased clarity from slightly better cohesion unlocks whatever is blocking you from decoupling. Sometimes better cohesion helps you live with the coupling.

I didn’t have to change the behavior of my system to make it more valuable. As soon as I added to the options of what it could do next, I had already made money.

One of the coolest thing about options is that the more volatile the environment is, the more valuable options become. This was part of my motivation to subtitle my book Extreme Programming Explained “Embrace Change.” As a young engineer, I was terrified when a seemingly settled situation turned chaotic. As I learned to enhance optionality, I saw chaos as an opportunity.

What interferes with options? Here are some scenarios that reduce the options value embedded in your software: A key employee quits. Changes that would have taken days now take months. You distance yourself from your customers. If you get a provocative suggestion a month instead of one every day, you have fewer options. The cost of changes skyrockets. Instead of being able to exercise an option a day, you can only exercise an option a month. Fewer options, less value.

The structure creates options.

Here’s the problem: structure is not legible in the same way behavior is legible. There’s a reason product roadmaps are lists of features (behavior changes). It’s easy to see when the behavior changes—a button appears that wasn’t there before.

Even though we know that we have to invest in structure to maintain and expand optionality, we can’t really tell if we have. The code is easier to change? Really? We can’t really tell if we’ve done enough. If we invested more in the structure, the code would be even easier to change? Really? We can’t really tell if we’ve made the right investments in structure. The structure changes we made were the best way to make the code easier to change? Really?

reversibility.

In a chaotic situation, options are better than things, so create options in the face of uncertainty.

Earning money now can reduce future options. But maybe if you don’t earn money now, you won’t be around to exercise those future options.

This surprised me. I thought I was getting paid for what I had done (as per the previous chapter). I wasn’t. I was mostly getting paid for what I could do next.

Now, there are times to tidy first for sure. When: cost(tidying) + cost(behavior change after tidying) < cost(behavior change without tidying)

Your sniffer might tell you, “There’s more good stuff here, but I need to tidy to be able to see it.” That may be good enough evidence for more tidying.

In general, we should treat reversible decisions differently than irreversible decisions.

Another scenario where reversible design decisions become irreversible is when the decision propagates throughout the code base.

The word “coupling” has lost its meaning over time, coming to mean any relationship between elements in a system. “This service is coupled with that service”—okay, but how? With respect to what changes? It’s not enough to know that one service invokes another; we need to know what changes to one service would require changes to the other.

I remember an incident at Facebook where two services shared the same physical rack. One service changed its backup policy from incremental backups to complete backups. These backups saturated the network switch located on top of the rack, causing the second service to fail. The two services were coupled with respect to changes to the backup policy, even though the two teams working on the services weren’t even aware of each other.

power law distributions,

Tidyings are the Pringles of software design. When you’re tidying first, resist the urge to eat the next one. Tidy to enable the next behavior change. Save the tidying binge for later, when you can go nuts without delaying the change someone else is waiting for.

but the ultimate payoff of this brilliant technique you are learning is to get along better with people who aren’t like you.