Measuring Churn

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.

 
:smiley:
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.

1 Like

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.

2 Likes

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.

1 Like

Is this functionality something that is planned for SonarQube. I think it would be really helpful.

Hi,

No current plans.

 
Ann