There is lately an emerging obsession with beatiful code, up to the point where some programmers are overprioritizing it over more important goals such as:
When this is taken to the extreme, and all that the programmer cares about is the beauty of the code, can cause him/her to fall under the refactor syndrome.
The refactor syndrome has the following symptoms:
- Complete disregard for other’s people code.
- Obsession with naming variables and methods.
- Overuse and overvaluation of unit testing.
- Complete disregard for any sort of documentation, design or analysis.
- Ignoring end to end, and manual testing.
And usually causes:
- An explosion of services, managers, helpers or other utility like classes.
- Integration bugs.
- Lack of robustness.
- Loss of productivity.
The main issue with the refactoring syndrome is that is based in the beauty of the code, and this, upfront, has three big issues.
- Not achievable. All code is crap. This is one of my favorite quotes, and to me is proven by the following facts:
- Exclusion principle. All programmers tend to think that only their code is the only good code in the universe.
- Legacy code principle. As a programmer, as you learn new stuff, you even consider your not so new code to be crap.
- Experience principle.I have never seen, or produced any real code which I thought it was beautiful.
- Not so important. Even if beatiful code was achievable, it doesn’t prove that the code is correct, and among other things, correctness is way more important than beauty.
- Wrong perspective. Focusing in the code itself, and not in the application makes the programmer forget about other more important areas.
This refactor syndrome seems to be associated with some programmers taking the last agile tendencies as religious dogmas. This happens when programmers confuse the tools and engineering practies like TDD, refactoring, pairing and unit testing… with what needs to be achieved. This would be comparable to a builder who believes that having shiny, new and clean tools, is more important than the house he is building.
It is important to understand that none of the tools or engineering process that the different agile family of processes propose are bad per se, they are usually great. Is just that when we decide to overuse them that we might be getting close to the refactoring syndrome.
In summary, is important to remember that:
- It is not important how beatiful is your code if it doesn’t work.
- Refactor only when is necessary, not only when you don’t like the code or you think you are going to make it more beatiful. Not liking something IS NOT a reason enough to change it.
- Unit tests have very limited value when it comes to integration and end to end issues. Do real end to end test!!
- Know all the different tools and engineering practices, but don’t take them as dogmas, learn what is good and bad from each and apply them when necessary.
- Good programmers are gonna keep doing good software, bad programmers are gonna keep doing bad software, no matter what processes they follow.
Apparently this article is causing some controversy, so I want to make clear some points which I see after the comments I didn’t made clear enough.
- I do think that Unit Test is great, I just want to point out that it CAN’T and it SHOULDN’T pretend to substitute integration and end to end test from the developer.
- When I say that a bad programmer is going to write bad software, no matter what process he follows, I didn’t mean to say as in, a bad programmer also will always be a bad programmer, we all have been very bad programmers when we started, and we only hope that we improve as we aquire more experience.