Tidy First?

Chapter 20. Getting Untangled

You’re changing the behavior of some code. You see a tidying that would make it easier to change. You tidy. Then you write another test case. Now you need to change the behavior some more. That leads to more tidying. An hour later you:

• Actually understand all the behavior changes that need to be made

• Actually understand all the tidying that eases those behavior changes

• Have a mess of tidyings and changes all tangled together

You have at least three options, none of them attractive:

• Ship it as is. This is impolite to reviewers and prone to errors, but it’s quick.

• Untangle the tidyings and changes into separate PRs, or a sequence of PRs, or a sequence of commits in a single PR. This is more polite, but it can be a lot of work.

• Discard your work in progress and start over, tidying first. This is more work, but it leaves a coherent chain of commits.

The sunk cost fallacy complicates the choice between these options. You have some new tests. They pass. Why would you want to throw that away?

The answer, as always, is because you are not just instructing a computer, you are explaining your intentions for the computer to other people. The shortest path to instructing the computer is not an interesting end goal.

By this point in the book it may not surprise you that I encourage you to experiment with the last option. Re-implementation raises the possibility that you will see something new as you re-implement, letting you squeeze more value ...