The Word “Consistency” Should Not Enter Code Quality Discussions
This is not to say that consistency is bad. This is only to say that it should never be an argument for why things should be done a certain way.
We’re not talking about indentation or formatting. In that case, pick something standard and stick to it.
We’re talking about the code itself: frameworks, methodologies, and approaches to solving a problem.
You will not see “consistent” in any of the common lists of code qualities.
You’ll see “extensible,” “secure,” “robust,” “performant,” “easy-to-reason-about,” etc. These are all good words to use in conversations about code quality (if you can back them up.)
Problems with a “consistency” rule
Considering consistency to be a quality on its own leads to
- stagnant thinking
- compounding interest on technical debt
- reluctance to pay down debt
- frustration among team members who would like to make things better
- frustration among team members who would like to experiment with a different approach
Benefits of inconsistency
When there are multiple ways of doing something and no one can think of a technical reason that one is better than another, let them all thrive.
Eventually, one of the ways might emerge as having some advantages. We might be surprised about which one it is.
This would never be discovered if we insisted on consistent code.
Do things differently every time until you find technical reasons to prefer one or another. Then have a conversation with your team about these reasons.
This raises the quality of your software.
But don’t stop after this one step! Continue to allow new approaches to be tried, as long as they aren’t worse than this new, best-of pattern.
How to approach inconsistent code
If someone does things differently to your existing pattern, do not say, “this should be consistent with the way we do this elsewhere.” Instead, give a technical reason that the existing pattern is better than this new way.
If you don’t have a technical reason but suspect there is one, then start a conversation with, “I wonder if there’s a reason it’s been done this other way elsewhere.”
If no one can think of a reason — and “consistency” is not a reason — then let it go.
Conclusion
The word “consistency” should not come up in discussions about code quality. It is not a code quality.
