There was a comic going around a few weeks ago about code quality, you remember the one:
Pretty amusing, but it got me thinking, what IS a good measure of code quality? Quality after all is very subjective, what I might perceive as being great, you might perceive as crappy for a host of reasons. A pet pattern wasn’t used quite right, the unit tests aren’t “real” unit tests, you know of a library that would have made the whole thing 10 times easier, etc.
There are all sorts of different measures that might relate to code quality, the level of coupling, the testability of the code, the test coverage, adherence to standards and many others and yet all of these are still subjective to a degree. There are times when not adhering to standards is best, just as there are times when a low level of coverage is good enough, it is all different from system to system, situation to situation. So is there no one good measure of code quality?
I contend that there is only one measure of code quality that is worth anything. We can argue all we want about numbers and patterns but in the end, one thing will always be true for every good developer:
Every good developer intrinsically knows if his/her code is good enough!
That’s right, you already know if your code is good enough, if you think that you don’t then you’re deceiving yourself and need to ask yourself the following questions.
If you were to think of a developer you admire, would you be proud to show your code to that person or would you cringe in shame if they were to see it? By extension, if that person were to criticise your code for whatever reason, would you vigorously defend it with all your heart or would you put in a token defensive effort for appearance sakes?
Due to the nature of our work, developers are part artist, part craftsman and part scientist and the one thing that all those people share is the ability to know if what they’ve produced is worth anything. Therefore, before we go and try to find an external way to validate our code for quality (and that includes getting it reviewed by other people) we need to be completely unequivocal about our answer to the question:
Do I think the code is good enough?
If the answer is not unequivocally yes, then there is no point going any further and you have some work ahead of you. If the answer IS yes, it doesn’t mean the code is perfect and can’t improve, it means that only more knowledge and/or experience can make it better. This is when involving someone else is a good idea, sharing knowledge and experience is (partly) why we work in teams after all.
The above works even better for pair programming, but the question becomes:
Do we as a pair think the code is good enough?
This works better because as a pair your internal threshold for quality will most likely be higher than it would be for each of you individually and you’re already sharing knowledge and experience. The threshold becomes higher still if you regularly rotate pairs. Although I do believe there will be diminishing returns if too many people have a stake in the code, but if the story size is small enough, this should not be an issue.
Well, those are my thoughts on measuring code quality I wonder what everyone else thinks. Do you agree with me or do you perhaps think that I am way off base? Do you know of a better way of measuring code quality (no, WTF per minute doesn’t count)?