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.
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
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.
Let's go to the waterfront with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton