More on Code Quality

Is Code Quality, like beauty, in the eyes of the beholder? Perhaps not as much, but there is a significant amount of subjectiveness in any assessment of code quality. Technical leaders need to be aware of the many layers of code quality:

1. Coding conventions and standards


2. Adherance to the best practices of the programming language and paradigm


3. Optimal algorithms and design


4. Architectural and cross-cutting concerns

Static analysis provides a convenient way to improve layers (1) and (2) in a scalable manner. These tools are meant to reduce the noise and help technical leaders focus on the more important layers (3) and (4), which invariably require a deep-dive/manual review. I've covered the dangers of over-reliance on these tools in my previous blog post.

So what should you do if the static analysis tools come out with a bad report on your code?The most common mistake in this scenario is to focus the team on immediately fixing the layer (1) and (2) issues. It's easy to fall in to the trap of focussing on just those areas, that are immediately visible to the managers. Instead, this should be read as a warning sign of much worse things in layers (3) and (4), and the first order of activity should be to do a deep dive to figure out the more critical issues in layers (3) and (4). Fixing should prioritize on the most impactful areas across the four layers rather than just those immeidately visible to the "managers". For example, it's far more important to fix connection leaks and exception and logging issues than it is to fix a coding style issue. This is not to say the style issue should not be fixed - that should be a given. Setting a design right after the fact, however is a complicated and risky proposition, and that is where the technical leader's good judgement comes into play. I've seen technical leaders either shy away from this difficult decision, or become a cowboy and plunge right in, without the safeguards in place. Unit testing is your best friend when engaging in such a refactoring job.

Ofcouse, as always, an ounce of prevention is far better than a pound of cure. A deep dive into the first 100-500 lines of code written by the team and regular reviews thereafter is the best safeguard against code quality going astray later on. The paradox of code quality is that although the architecture and design is usually done by senior technical leaders in the project, the entire team including the junior-most engineer need to understand this in order for the code to come out good. Strong leadership and communication traits are essential to drive this common vision and understanding among the team and prevent the disaster caused by poor code quality.