An Opinion on Code Quality

September 22, 2026

I only reflect on my opinion and make no recommendations in this note.

In a previous role, there was a very high bar for code quality. And this was enforced in different ways; >80% code coverage score, static analysis, cognitive and cyclomatic complexities.

I maintained some of the libraries with the highest scores for these metrics. And that naturally placed me at the right spot to drive an organization-wide initiative to standardize code quality measurement and enforcement.

The approach was to have QAs write test cases in Gherkin along with tickets. Then my prototype tool would pull those specificiation files, generate code for them that engineers will need to implement, run the tests on CI, collect reports and sync somewhere.

Talking about this recently, I realize that this is likely a symptom of bad quality in engineering.

It is quite hard to explain a visceral understanding of taste in code quality. When one begins to nudge other (usually junior) engineers in that direction, one tends to reach for some objective approach that can be mathematically measured and proved.

That lands you metrics that don't mean much. I noticed a lot of engineers writing low quality tests just to get their 80% or risk their PMs hounding them for unmerged changes.

I do think that tests are important. However, the metrics around them are much less so. I hated Sonar's cyclomatic complexity reports. In my opinion, it objectively lacks taste! And that is because rules that can be proven are rigid.

If there were only very senior engineers in that company, I believe we would have no need for those scores. Maybe this is also an indictment of engineering management styles. I find that some lessons in taste must first be accepted before they make sense.