I started myself on a bit of an experiment. Like any great scientist (trust me, I took organic chemistry), I’d like to share my findings, lessons learned, and why 80% of the time this experiment made me a horrible developer.

The Experiment

Each week, I opened up a seemingly random file in my current project, scoped out the test suite, then went to work on refactoring the file and its associated tests.

This is the worst idea I’ve ever had, including the time I tried to cook hamburgers in a toaster

What I did wrong

As it turns out, if you’re refactoring both the file and corresponding tests, you are likely to have a more brittle test suite than when you started.

Refactors are safe as long as you look at your tests before you start playing around. Do you trust your tests? If so, then don’t touch the test file. Tests are there so that you can refactor freely, like a mad man. It’s awesome. If you don’t trust them, then the only file you should refactor in this exercise is the test file.

Tackling Tech Debt (and when to stop)

Normally, a developer discovers technical debt for two reasons 1) he just wrote this awful code, but he’s on a deadline and wants to get value to his customers or 2) he picked up some shiny, newly assigned feature work, opened up the appropriate file, and realize that some jerk has written the worst code ever. So he’ll huff and puff, git blame the code, realize it was him, and then get to work.

This is usually done without much thought. As developers, we don’t necessarily assess whether the code is “good enough”. We don’t take into account how much time it will cost us. These factors are put aside because it would mean fighting the amygdala hijack from the horrible horrible code.

Alright, so let’s say the developer calms himself down. He now has to figure out whether or not he should tackle this debt.

Is it time to recycle?

• Is this file constructed well enough to be easily maintainable if I have to come back in here and do feature work?

• How much time will this refactor take compared to how much time I will save future developers working in this file?

• Have I been working too hard on feature work and need a relaxing recycle task to balance out my workload?

public Boolean isFileInNeedOfRefactoring() {
  if(isReadable || isGoingToTakeForever || !isDevBurntOut){
    return false;
  }
  return true;
}

Conclusions

I practiced this exercise at least once a week, and I realized that a developer who dives deep into refactoring land may lose sight of the bigger picture: the customer, the product, the things that keep you employed.

The danger in this game comes from a simple truth: developers tend to be artists about their work. A developer is naturally driven towards perfection. No artist - painter or coder - wants to give up his work. He can always find a way to improve it. It takes a strong artist to remember that the function of perfection is asymptotic. You will never reach your absolute maximum. With time you get better, and with time the code gets better, but you aren’t building things for yourself most of the time. Most of the time, you have people who rely on you to produce work.

So play the refactor game every once in a while, with this caveat in mind: Don’t aim to be perfect. Aim to be maintainable, readable, functional, and great.