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)?
Related posts:
- Are You Actually A Post-Agilist?
- Effective vs Ineffective Pair Programming
- Is Your Code Worthy Of Being Improved
- To Code With Or Without Music That Is The Question
- Building Software Development Expertise – Using The Dreyfus Model
- The 4 Unlikely Traits of Good Developers
- The Perfect Size For An Agile Team – 1 Person – It’s Crazy!
Chris Roane (3)
apeiros (2)
Dan Kubb (2)
Kevin (2)
Korny (2)
kt (2)
Ahmed (1)
Barak A. Pearlmutter (1)
Bert Willems (1)
Carolyne (1)
{ 5 comments… read them below or add one }
Nice read. For me, I guess WTF/minute is a good measure. Anyway, maybe because I’m an amateur learning under a GEEK. So I get WTFs every other time!
Nice post. In my opinion, code quality is a very subjective topic, and when measuring code quality one must be a little careful.
For example, what is better – very clean readable code which is easy to understand but might not be as optimised as it could be, or highly optimised, great, intelligent code, which is a nightmare to read and maintain due to the many advanced techniques being used?
As I see it, both coding styles are good and both have their uses, but they cannot really be compared together. They should be compared to code similar to their style and requirements.
I agree code quality is extremely subjective, I believe that we always write code for other people to read so it should be made as easy for others to understand as possible. But that is just my view and other people will have different ones which is ok.
The trick is to make sure that there is a consistent view on what constitutes quality code within your team and hopefully within your company. When people who work together have wildly different ideas on the subject, that’s when it can get a little hairy.
Nice read. The comic is quite funny. However, I do disagree with the statement “Every good developer intrinsically knows if his/her code is good enough!”. In my experience most developers will say their code is good and code he/she did not write is easily ‘bad’. Even, when the ‘other’ code is better if you take a look at it more objectively.
I do know what you mean though, real developers with hearth for their code will ‘feel’ if their code is good/bad enough already. I won’t argue there.
I’m writing a thesis about software quality, it is related to my job. My first question actually is “what is software quality”. As you said, it is subjective. In that sense we (developers) have to agree on a term we call “quality”.
I am still working on that definition. But from there it will be easier. Using Software Quality factors you might be able to know what Developers tend to like (ie, try to figure out what other developers think of in terms of quality). A good example is “maintainability”. You hear about that all the time. But even maintainability can be split up into tinier pieces.
Once i have my definition clear i can investigate metrics and such. Using such tooling I can score the quality factors we find important. Also, the tools will point us into pieces of code that should be worked on if we want to deliver quality as we see it.
Short answer is: Try to make it objective, and work from there. And even then there is only this little piece you probably have taken care of. Because, what *you* see as quality (as developer) might be totally different than your customer thinks off… but thats worth another thesis i guess :)
I will always be appreciative to the prof. who insisted his budding computer scientists read “Zen and the Art of Motorcycle Maintenance”. Among other things, it contains many reflections on whether quality is mystical or measurable.