10-29-2012 4-37-59 PM

Answering questions about your code base — Part 2

on Apr 2, 12 • by Patti Murphy • with No Comments

In this continuing story about the journey to source code awesomeness, we left off at the point where we identified priority defect types for your organization, kicked off pre-checkin static analysis on developer desktops and saw build-over-build improvements in our trending reports as a result. The next question we...

Home » Software Complexity » Answering questions about your code base — Part 2

In this continuing story about the journey to source code awesomeness, we left off at the point where we identified priority defect types for your organization, kicked off pre-checkin static analysis on developer desktops and saw build-over-build improvements in our trending reports as a result.

The next question we tackle here is: What is my cost of ownership?

The answer, my friend, is not blowing in the wind, it’s in your Complexity Trend report:

Complexity Trend report

Why there? you might ask. Well, it’s because there’s a straight-line correlation between the complexity of a function and its cost per line to code and test.

If we see an increase in the Complexity Trend, we can use Complexity Details to pinpoint modules or files containing the most complex methods:

Complexity Details report

Looking at this report, I can see where my ownership cost is localized. More often than not, we find that the modules that contain the most defects are also those that contain the highest number of  complex methods.

Klocwork Insight metrics use McCabe Cyclomatic Complexity to assess the complexity of a program.

Another indicator of the high cost of ownership is the point at which defects are caught and fixed. Finding and removing bugs as early as possible in the development cycle lowers your ownership costs. This report shows fix activity between builds. You can toggle between views showing fix activity in the integration build and on the desktop. For now, we’ll look at All fix activity:

Fix activity by module

Here we see a spike in activity that occurred during the start of a new feature release.  If the upward trend continues, it can indicate a couple of scenarios. Either:

  • Your development team is growing and more developers are using static analysis on the desktop, or
  • Your team size is the same but developers are using static analysis more consistently.

Either way, more activity means more value from the tools and a lower cost of ownership. Developers fixing defects before check-in lowers your cost of ownership considerably.

Any more questions?

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top