We should really love the mess in our code because it is really useful information about the way that our code is developing over time.

We should develop this wabi-sabi sensibility about our code. I don’t wanna sound like a lean consultant. I apologize for adding more japanese terminology.

So maybe instead of we should say we should see the mess in our code as a patina that it develops over time. Like the way a leather jacket, belt, boots or old denim develops a beautiful wear in it over time. So does our code.

As long as it doesn’t get too messy, it’s OK.


I am not saying “Don’t do any refactoring” because that would be impossible. What I am saying is: don’t refactor so much in a way that we end up with crystal like structure that can not change and can not absorb new ideas and new designs in it locally and incrementally.

Enjoy the mess in your code. Understand it. Learn to read it.

Maybe toolmakers one day will have a way of showing us the 3D shapes of our code as we work in it, in a way that helps us understand changes in design and the way design is morphing over time.

But for now we will have to basically learn to love the mess and inconsistencies, the bit of duplication and keep just enough around to keep our code flexible and enjoyable and relaxing to work in rather than always stressing about whether we’re in the right paradigm or whether we’re into the architectural conventions properly and so on.

Refactoring should only be done when adding new stuff. If you never need to change the code, then it doesn’t need to be refactored. So if you want to change it, than you need to clean it up a bit. But if you clean it up 100% so there’s an absolute perfect design and never change it, it’s a kind of wasted effort. You might as well stop a little bit early and enjoy the sort of slightly shambolic nature of your code.

Nat Pryce, in his presentation Stop Refactoring!

Usually, this is because the reason that people want to rewrite code is because they don’t understand it.

Yet, rewriting code often requires us to understand it well enough to proceed with the rewrite, especially if there are existing customers who depend on all of the nuances of behavior that the system has consistently exhibited.

Michael Feathers, revealing the paradox of rewrites in The Carrying-Cost of Code

Look at the code and see where it becomes complex.

Look at the function and consider the likely areas of error.

Your tests will not find every bug, but as you refactor you will understand the program better and thus find more bugs.

Although I always start refactoring with a test suite, I invariably add to it as I go along.

Martin Fowler, in Refactoring
Refactoring can lead to simpler designs without sacrificing flexibility. This makes the design process easier and less stressful. Once you have a broad sense of things that refactor easily, you don’t even think of the flexible solutions. You have the confidence to refactor if the time comes. You build the simplest thing that can possibly work. As for the flexible, complex design, most of the time you aren’t going to need it.
Martin Fowler, in Refactoring

What is it that makes programs hard to work with? Four things I can think of as I am typing this are as follows:

· Programs that are hard to read are hard to modify.
· Programs that have duplicated logic are hard to modify.
· Programs that require additional behavior that requires you to change running code are hard to modify.
· Programs with complex conditional logic are hard to modify.

So, we want programs that are easy to read, that have all logic specified in one and only one place, that do not allow changes to endanger existing behavior, and that allow conditional logic to be expressed as simply as possible.

Kent Beck, in Refactoring
The first time you do something, you just do it.
The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.
The third time you do something similar, you refactor.
Don Roberts’ guideline to refactoring, as described by Martin Fowler in Refactoring

Without refactoring, the design of the program will decay. As people change code - changes to realize short-term goals or changes made without a full comprehension of the design of the code - the code loses its structure. It becomes harder to see the design by reading the code.

Loss of structure of code has a cumulative effect. The harder it is to see the design in the code, the harder it is to preserve it, and more rapidly it decays.

Regular refactoring helps code retain its shape.

Martin Fowler, in Refactoring