How to measure code quality

I want to begin by first answering what is good quality code and why it matters. And the answer is as follows.

Good quality code matters because it allows the business to pivot quickly to new challenges. It allows operations to function smoothly, and it allows developers to churn new features quickly. All of these have clear business advantages for any organization that runs on the technology they write.

With the above criteria in mind, these are my subjective measures of good quality code:

  • The good quality code makes it easy to adapt the system to new possibly unforeseen changes.
  • It also enables the teams supporting the production system to diagnose, probe and fix issues at runtime.
  • Finally, it allows the developers to learn, reason about and change code quickly and with confidence.
  • With that out of the way, let’s put together some indicators of good quality code. 

Let’s be clear, and these are indicators, not necessarily cast in stone. Human judgment should always override rigid rules.

Code flexibility

Very few systems are ever written complete and right the first time around. All systems change. The good code makes it easy to change and add new functionality or modify existing functionality over time.

When writing new systems, I like to measure system and package interface granularity — clearly, the more granular your package level interfaces, the better. The more business-focused your system-level interfaces, the better.

Another measure comes not from code, but your issue tracking systems. The average time taken for an incremental feature to be completed and deployed is a pretty good indicator of code flexibility. The more the time taken, the more you should look at your package and system-level interfaces for having the right kind of granularity. 

Monitoring

There are two very potent indicators that are predictive of ease of operational use of any system you write. The first is whether the right kind of profiling and logging is in place. The second is how easy it is to change or tune performance parameters at run time. 

The measures for these would be no log statements per public method of each package. 

The second should come from your production monitoring teams. The average time is taken to identify and resolve performance issues in the system.                                

Developer Experience

The last big category of measures is around developer experience. Time to onboard a new developer must lie at the very top of this category. The shorter the time, the better the developer experience. The next important measure in this category is the ease of unit and integration testing. The more “flaky” the tests, the worse the developer experience. The lower the test coverage, the more difficult it is for developers to change the system.

You will notice that I have not spoken of Sonar and Jenkins and things like that. Those are excellent tools to get to the first step, which is hygiene. You cannot have truly good quality if there is no code hygiene.

In our consulting assignments, we always try to make sure the code hygiene is always in place from day 1 and that code quality is maintained throughout. To learn more about how we achieve this, contact us.