How to measure code quality

Category

Blogs

Author

Wissen Team

Date

April 28, 2023

I want to start with an answer for "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 enables operations to function smoothly and developers to churn new features quickly. All of the above have clear business advantages for an 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 possible 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 confidently.
  • With that out of the way, let us put together some indicators of good quality code. 

Let us be clear that these indicators are 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 from your issue tracking systems rather than code. The average time taken for an incremental feature to be completed and deployed is a pretty good indicator of code flexibility. When it takes more time, you should look at your package and system-level interfaces for the right kind of granularity. 

Monitoring

Two very potent indicators 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. It needs average time to identify and resolve performance issues in the system.                                

Developer Experience

The last big category of measures is around developer experience. The time to onboard a new developer must lie at the very top of this category. The shorter the time, the better the developer experience. Another vital 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 good quality if there is no code hygiene.

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