wood burning stoves*
The moose likes IDEs, Version Control and other tools and the fly likes SonarQube: Talking to managers/execs about code quality Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "SonarQube: Talking to managers/execs about code quality" Watch "SonarQube: Talking to managers/execs about code quality" New topic
Author

SonarQube: Talking to managers/execs about code quality

darren hartford
Greenhorn

Joined: May 17, 2010
Posts: 17
I'm sure I am not alone in these scenarios where a manager or executive want to "stop having too many issues in production" or "reduce bugs" or "reduce the number of hotfixes/downtime related to hotfixes".

So the question becomes, how does one 'show' a stakeholder the quality has been improved in a way that makes sense to them?

I've seen things like the 'SIG maintainability' metrics, but I think that was a commercial plugin for Sonar. But using that as an example, it provided a 'grade' that a business stakeholder took away....whether appropriate or not as developers we know may not necessarily be the case.

What other metrics/reports have people had success showing improvement in code quality to non developers?

thanks!
-Darren
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
I can't speak for the authors, but I like the Technical debt widget (details here) - partly because most managers and some execs have at least heard the term before.

It lets you see what kind of issues you're having (code complexity, duplicate code, coding violations, etc) and provides an estimate of the time and cost to clean it all up. You can customize it to some degree (details here) - and worst case, you can just show how the cost has increased or decreased over time.

I hope this helps,
Burk


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Patroklos Papapetrou
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 32
    
    5

I assume you're talking about non-technical managers
Well these managers care about costs, time-to-market, ROI, and productivity right?

As Burk said, the Technical Debt plugin might be useful especially if you want to give them one single number and combines most of quality axes of SonarQube.
But again you may miss something. What's the main reason why productivity is decreasing? Why it takes too much to add new features? Why we spend more time in fixing bugs than adding new features? I've been asked many time such questions from managers and my answers where more or less the following :"Our system is too complicated", or "Fixing a new bug or adding a new piece of code is a nightmare because we don't know what regression bugs this might create" or even "no one wants to touch this part of the code"...

So here comes SonarQube. You can show your boss that since you're improving test coverage, you have a safety net to change code, refactor or add new features. You can show your boss that decreasing the number of issues or eliminating duplications you're resolving potential future bugs which means that you'll have more time for new features -> more productivity . You can show your boss that decreasing code complexity allows you to make more quickly future changes and deliver fast new versions to the market

My point is that you have to translate core metrics to what bosses understand and how do these numbers affect the evolution of the product.


Follow me on twitter ( @ppapapetrou76 ) or see my linked profile and connect with me
You can slso subscribe to my technical blog
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30753
    
156

You can also compare your projects to each other and other projects (on nemo.). If you have multiple projects, it is best to compare internally. Then you can show that your app is as good as one they like or better than one known to have problems. Or you can use Sonar to compare to a baseline to show you have made progress.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Patroklos Papapetrou
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 32
    
    5

@Jeanne : Yes that might be a good case by you must be very careful when comparing projects. It's not always goof practice to compare projects that have different purposes or even written in other languages. For instance comparing an API library vs a web application will probably lead you to false conclusions because they have different needs.
Comparing is great when you do it between two versions ( snapshots ) of the same project. There, you can really get useful insights and trends about the quality.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30753
    
156

Patroklos Papapetrou wrote:@Jeanne : Yes that might be a good case by you must be very careful when comparing projects. It's not always goof practice to compare projects that have different purposes or even written in other languages. For instance comparing an API library vs a web application will probably lead you to false conclusions because they have different needs.

Good point. I was thinking of comparing similarly architected web apps by different teams. (I work for a large company so we do have some things that would be comparable.) Comparing random projects would be a horrible idea!
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Patroklos Papapetrou wrote:So here comes SonarQube. You can show your boss that since you're improving test coverage, you have a safety net to change code, refactor or add new features. You can show your boss that decreasing the number of issues or eliminating duplications you're resolving potential future bugs which means that you'll have more time for new features -> more productivity . You can show your boss that decreasing code complexity allows you to make more quickly future changes and deliver fast new versions to the market

Looking back at the original question, "So the question becomes, how does one 'show' a stakeholder the quality has been improved in a way that makes sense to them?" I'm wondering if we're looking at the wrong tool. Based on my experience, if someone's concerned about the number of bugs found in QA, then they want to see fewer bugs found in QA, and they don't particularly care whether the "code quality" goes up or down. I'll admit it's probably to decrease the bugs found in QA if the code quality drops, but showing them an increase in quality won't mean anything unless it's accompanied by a drop in the bug count too.

Similarly, if an exec declares that there are too many production outages, then they expect to see fewer outages, and are not interested in how much our code quality has improved. I think for most people outside the dev team, code quality is our responsibility to maintain while also meeting their deadlines for getting "real" problems solved.

My two cents,
Burk
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30753
    
156

Burk,
Sometimes management has unstated goals too. For example, they would prefer that it take you an hour to do an emergency bug fix than 8 hours. This is a metric relevant to Sonar. If developers have to spend a long time reading the code because it is poor quality, fixes take longer.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Jeanne Boyarsky wrote:Burk,
Sometimes management has unstated goals too. For example, they would prefer that it take you an hour to do an emergency bug fix than 8 hours. This is a metric relevant to Sonar. If developers have to spend a long time reading the code because it is poor quality, fixes take longer.

Jeanne,
Very true. However, darren's question was asking what to do when stakeholders have concerns about too many production issues or the need to reduce bugs. To that I say show them data directly related to their concern - fewer production issues, fewer bugs. You can also point out that the reason it's gotten better is that you've improved the code quality. But, if all you can do is show the quality's gone up while the issue/bug count hasn't improved, then don't expect the stakeholders to be happy with your report.

Fixing production bugs quickly is often a high priority. If it means fixing it with an ugly patch in an hour or taking eight to do it right, then as long as the quick fix will work and not break something else, I believe it makes sense to fix it fast now - then fix it right once production is up and running again. It means intentionally incurring short-term technical debt. but you're paying it off before there's any appreciable interest accumulated.

And two more cents makes four,
Burk
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2402
    
  28

IMO, non-technical management is going to come to you with a business need. They might ask for improvement in time to market, or reduce defects found by customer, or improvement in turnaround time for critical customer facing issues. They are trusting your professional judgement to execute that change. You can use your professional judgement to determine that improvement in code quality will result in the company meeting a business need. You can track the code quality metrics for yourself, but that doesn't mean that you can show the code quality metrics to the non-technical management. The business is interested in meeting business needs. If you spend time and effort to improve code quality and that doesn't meet the business need, you are going to get fired. It doesn't matter how good your code looks if it doesn't save the business some money.

Business managers think in terms of ROI. What you need to do is figure out which ROI metrics you can show to the business that represents the business need. Also, you need to be able to track your code quality metrics against the ROI metrics that you are going to show to the business. If the ROI doesn't improve in one or 2 iterations, you have to be able to figure out what went wrong.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Amen, brother.
G. Ann Campbell
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 33
    
    5
What was it you guys needed me & Patroklos for, again?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SonarQube: Talking to managers/execs about code quality