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!