Goodbye, Clean Code

> If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me something: You think your teammate is a worse coder than you, given you were able to solve it with "cleaner" code. You assumed that your solution was better, without talking to the person who authored it to see if they did things that way for a reason.

The time they spent developing the solution is a sunk cost. The only thing that should matter is whether the afternoon rewriting it is the most productive use of your time.

Also, rewriting something is far easier than writing it from scratch. Just because you can rewrite it quickly doesn't mean the original developer didn't save you a bunch of time by letting you see a workable first pass.

Clean Code sounds like a virtue, but it wasn't ever supposed to be a primary goal, it's more about disciplined with the code you write. Architecture and Design are more fundamental.

Removing duplication is most often about Design. Very easy to introduce unintended coupling if the only motivation is to reduce duplication. Coupling, Cohesion, Composition, and Abstraction are generally more important concerns than clean code. Sometimes simply by trying to remove duplication you find a better design, but sometimes you don't, sometimes you tangle your design with couplings that don't really make sense. However, after your higher concerns are taken care of, you should keep the code clean.

As a sidenote, what the author did by going to extremes and then backing out of it is actually a really good exercise in learning some of this stuff. We are fond of our "rules" for producing good software, they often encapsulate key insights. But there are no real rules, there's just the vast interacting world of these insights and how they play off against each other and how we socially interact with others with often similar but slightly different insights to create software as groups. It can be done many ways and should be a constantly evolving thing.

> Well, in that case, why do it now instead of waiting until “the future”? If it’s needed in the future, the cost is not more than it is now.

They're familiar with the code and its gotchas when it was written. In "the future" most of that context will be gone (people forget stuff, and change companies/teams/roles).

Better to get rid of the gotchas before you get burned.

> If it isn’t needed in the future, then he’s wasted his time.

The new version was still more readable to newcomers, and resizing stuff is pretty core functionality for a drawing program.

> If something similar is needed, but it needs to be refactored in a different way, they are going to have to refactor it

A second pass of refactoring tends to be easier than a big ball of mud. And in the worst case, they can always inline it and start over from the same state.

> There is no special case “trap”. Business requirements necessitated changes.

When requirements change you can either start adding special cases or rethink how it fits into the bigger picture. That matters in every layer, but it's especially important in the UI layer.

Unless you want to end up with an unusable Apple-style hodgepodge. In that case, go wild, I guess.

My takeaway from this is "do code reviews".

Weird that there's no mention of writing tests.

After all, they help in explaining the intent behind the given piece of code.

With well written tests even the most "clever" implementations become at least reasonably understandable.

Anyway, here's what I do to deal with this problem:

1. Write code (and tests).

2. Switch to some other task.

3. Forget about that previous piece.

4. Get back to it and judge if it's still readable.

If something is readable then it's likely to be modifiable as well.

One classic example of things that I learned to never de-duplicate is the routing configuration. In this instance anything that isn't an explicit list of URLs is usually too "clever" to be readable.