Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Is there any recommended practice for how frequently code quality metrics should be reviewed by the team? I'm not sure how often should we be conducting a review of code quality metrics to look for potential issues that need to be addressed. We are working in Scrum sprint cycles, but I don't know if Scrum provides any advice?
Should it be reviewed daily, weekly, end of every sprint or what?
I'm thinking here of code quality metrics such as cyclomatic complexity, etc.
From a technical standpoint, code metrics should be baked into your test-driven development (TDD) or acceptance testing, preferably in an a fully-automated way. However, from a Scrum perspective, the framework is not prescriptive.
The correct framework perspective is that gathering and checking your current code quality metrics should be part of your Definition of Done. Reviewing the usefulness or accuracy of your metrics should be an ongoing part of your inspect-and-adapt cycle, which means:
This may not be an industry standard, but instead of measuring quality we're preventing it from decreasing. We simply do not allow programmers to commit anything to the master branch, unless it passes all quality checks. For example, cyclomatic complexity, which you mentioned. No programmer can merge anything into master branch, if his/her code has complexity higher than 5.
These two articles explain this approach in more details: Master Branch Must Be Read-Only and Strict Control of Java Code Quality
In my experience metrics are not a very reliable tool to gauge code quality. They are useful to a certain limited extent, if used as an indicator rather than an absolute measure. And they can cause even more harm if used without thinking or overzealously.* Ultimately only the expert developers familiar with the code can assess its quality. So I wouldn't spend an inordinate amount of time trying to "perfect" automated metrics - IMHO team members' energy is probably more efficiently used to fix blockers or work on value generating tasks instead.
Once they are set up and tailored to our needs, I prefer to use criteria similar to what @yegor256 describes in his answer. IMHO it may be enough to do a full review of the metrics a few times a year. I would rather look at it from the other end of the pipe: whenever we find a code defect (in the broadest sense), inspect how it could have been prevented. If we find that better code quality metrics or different evaluation criteria would have prevented it, change the rules accordingly.
* Recently in one of our projects, higher management requested that all issues brought up by an automated code quality metrics tool be fixed. And the task was given to a junior developer who completed it to the letter... The end result was a stinking heap of mysterious bugs all over the codebase (mysterious until we realized their source, that is).
Some metrics like "function cyclomatic" should be checked and alerted on each commit, as they might be harder to fix later on, but release quality metrics such as "no commented out code" can be left to code review on version delivery.
We use Sonar CI for simple daily auto-inspections, and ProjectCodeMeter for end of sprint (release) code reviews.
