An Issue With Code Quality Metrics

Introduction

In software quality analysis, there is the idea that, if your code is mostly clean, then any imperfections in the code will stick out, and will be more likely to be fixed. This essentially boils down to the idea that codebases that are really bad seem beyond fixing, so people don’t bother. The issue with this is that there are more types of issues in a code base than small issues that are spread around evenly.

A Sugar Bowl

Over a year ago, I dropped my sugar bowl and one of the handles broke off. I was very upset about this. If I had completely broken the sugar bowl, I would not have been very upset. Damaging it, especially in a way that did not significantly degrade its usefulness, is in some ways the worst outcome. A destroyed sugar bowl, I would simply replace. A damaged sugar bowl, on the other hand, has gone on to mock me for over a year.

Back to Code

The same applies to software. Sometimes, the code that gives me the worst headache is not the worst code. The worst code gets refactored. It is the code that is just a bit smelly that we have to pay attention to, lest it stick around for a year, laughing at us.

The End of this Post

You have reached it. Congratulations! The last post was so long that this one is intentionally short. Also, yes. The aforementioned sugar bowl is real. Here is a picture of it: