I’m not sure if this is a “new” feature or something I just don’t know how to do with SonarQube. What I would like to do is measure “churn”. When I think about the efficiency of a team, the amount of change in a set of code from an initial PR to its push to production seems like it might be an interesting thing to look at. Is there a way to use SonarQube to do something like this?
jeff
Hi Jeff,
That functionality doesn’t exist, so this is the right category.
Ann
I didn’t think so. Figuring out how to do this with SQ would be pretty interesting and offer a different type of health metric on a team especially if you could categorize the root cause of the churn (bugs, code quality, cyber, lack of tst coverage, bad requirements, etc.). I realize this is a bit outside the scope of how developers typically use SQ, but as a developer it could be really helpful to see how much of your churn is being caused by poor requirements or something else that usually just ends up being the “dev team’s fault” when that is not the case.
jeff
Hi jeff,
I’m curious how you would categorize churn from poor requirements versus churn from true developer mistakes. And as a developer, do you have any trepidation about churn metrics being held against you? (Honestly, that fear was my knee-jerk reaction.)
Ann
Typically branches are tied to a Jira ticket. A ticket has a set of acceptance criteria. We would tag a branch/Jira ticket that failed due to not meeting the acceptance criteria as a bug. Something that was not accepted by the PO for the functionality, but did meet all the AC would be tagged as missing AC (aka missing requirements).
End of the day, things that don’t work seem to always land back at the feet of the developers anyway. I was looking at this as a glass half full: You might see that 30% of the stuff developers get blamed for is actually issues with non-development tasks and this could be used to improve overall team performance. Of course developers should also be helping to flesh out stories and requirements too so if things are not going well, a good team wants to have full visibility to improve.
I would also like to see churn metrics. Being able to know the cause of the churn seems out of the scope of any automated analysis tool, but being able to just see which files/lines of code have changed the beyond some threshold limit count could be useful. When certain files or lines of code are frequently changed, it could indicate a violation of the open/closed principle of SOLID design and warrant refactoring by the team to reduce risk introduced by future changes that are likely to continue happening around that part of the code base. Churn can also indicate areas that are prone to bugs, since developers keep having to go in and make changes.
I think that Churn would be of great use when deciding which code needs extra attention in terms of review for readability/maintainability/usability.
If some code suddenly changes a lot, or more developers are suddenly involved than ususally, it is probably a sign of “something”.
We are considering the tool GitForensics. Having everyting in SonarQube is nicer for a “one stop shop experience”. Even integrating GitForensics in SonarQube would be cool.
Is this functionality something that is planned for SonarQube. I think it would be really helpful.
Hi,
No current plans.
Ann
Still no plans?, is it something that SonarSource would consider adding to their roadmap?
This is something where your competitor codescene gives a lot of support. I think it would be wise to look into supporting the idea of seeing how your code base is “morphing” or “churning”. A lot of insights can be found in that data.
Hi Jeff, Robin, Johan,
I’m very interested in learning how you could use this information in your workflow.
What kind of problem would you be solving? Who would be interested in seeing the information (e.g. dev, lead, etc), in what moments, and what actions would be taken?
Where do you see that fitting with how you use Sonar today?
Hi,
I think that the paper “Crime as a Codescene” by Adam Thornhill sums up what this can be used for.
We want to use code-churn for determining:
The SCM history gives a lot of historic traces to why code looks like it does. Parts of source code that have a lot of churn may be “hot-spots” that needs to be reviewed both from a sytemic and software perspective.
Code that may seem independent from a strict software dependency perspective, may have high cohecien from a systemic perspective. If two parts of the coded base is often changed simulteneoud, this may give an indication of that there is a dependency.
High code-churn over long time indicates that more experienced programmers/designers should look at why that code “never stabilizes”.
I think that there are a lot of information that can be drawn from understanding how code evolve over time. Which modules change simultaneous. Which parts have temporal “churn-dependecies” etc.