rob bowley

In part 1 I talked about how we’re using NDepend and NCover to generate highly visual reports for our projects.

These tools look great, but are of limited use without being able to analyse how changes to the code have affected the metrics. In this article I want to talk about a couple of ways we can use tools like NDepend, NCover and TeamCity to generate other visual reports to support our dashboards.

NDepend

VisualNDepend analysing the dashboards project

VisualNDepend is a fantastic tool, but takes time to learn how to use and it often requires considerable digging around to find what you’re looking for.  A more immediate and visual tool is the  NDepend report (example) which can be generated through VisualNDepend or via the NDependConsole.  It contains a nice summary of things such as assembly metrics and CQL queries such as methods with more than 10 lines of code. Importantly here, TeamCity can generate and display NDepend reports using NDependConsole as Laurent Kempé explains here (using MSBuild though it’s just as possible with NAnt or Rake).

However I find even this report contains too much information  so we’ve modified the NDepend configuration file to show only four of the sections (see example) Assemblies Metrics, Assemblies Abstractness vs. Instability, Assemblies Dependencies Diagram and CQL Queries and Constraints. It’s now much easier to read. For example, we can see the assemby metrics at the top show us some of the same metrics used in the dashboards but broken down by each assembly. When this is integrated into TeamCity you merely need to click back to see how any of them have changed since previous builds.

We can also see the method “WriteChange(…)” clearly needs some love being the top method to refactor. When you compare the two reports side by side it’s easy to see how, just like methods or classes with too many lines of code, too much information can make what are otherwise valuable reports unreadable. I have to admit it took me a long time to get into using NDepend well and a lot of that is down to the overwhelming amount of information it produces.

NCover

It’s no good finding out your test coverage has gone down if you don’t know why. You could pay for an NCover licence for each developer, but less costly is to integrate the NCover report into TeamCity. Again, Laurent Kempé explains how to do this here and here is an example of the NCover report for our Dasbhoards project.  It doesn’t provide the same amount of detail as the NCover GUI, but will at least give you a good head start in the right direction.

So, in the end we have three tabs in our TeamCity project builds which, when used in conjuction with each other, give us a highly visual representation of how modifications are affecting the maintainability of our code. Of course there are many other reasons why code could be problematic but the context these these tools open up make it much easier for developers to learn and understand and therefore be able care more about the maintanability of their projects and the consequences of writing bad code.

There are essentially two ways you can discuss the quality of software. External quality is something everyone can appreciate. For example, how easy it is for customers to use one of our products and whether they encounter any problems (bugs) whilst doing so. Internal quality however, is a lot more complex and tricky to get right, but is just as important as external quality (if not more so). To me, internal quality is about how efficiently you can add or modify functionality whilst not breaking any of the existing functionality, not just today but over a long period of time. This is also known as the cost of change.

Another well known term  is software entropy - the more you add to and change a piece software the more complex and difficult it becomes to do so. Eventually the cost of change simply becomes too high and the long and arduous task of replacing the system begins. Of course, doing this this has a massive impact on competitiveness as you’re unable to deliver new functionality until you’ve done so and why it’s so important to make the effort to keep your code in good condition.

In the new world of software development we’re all really keen on visualisation (or “information radiators” as we’re supposed to call them) and with good reason.  It aids conversation and helps identify any pain points so, as a team, we can focus on removing them. A while ago a former colleague and friend of mine Peter Camfield blogged about quality dashboards he and Josh Chisolm had been working on. We’ve recently implemented them at my current company as well. I’d like to go into more detail about the dashboards, some improvements I’ve made and how, in combination with other visualisation tools, we’re able to make the most of them.

The "traffic lights" for one of our applications

The dashboards are created by running NDepend CQL Queries* and NCover on the code and test assemblies for a project, aggregating the results, comparing them to previous recording and outputting them as a set of traffic lights with arrows to show whether the measurement has improved or worsened. The levels at which the traffic lights change colour are mostly based on recommendations from the NDepend Metrics Definition page.

We’ve been running them in TeamCity (and added the output as a tab) any time code is checked in. Having lived with these dashboards for a while now I can say I’ve found them invaluable. They’ve raised countless discussions around how changes to the code base have impacted the metrics and really made us think about what good internal quality is. However it’s also been frustrating as until now they’ve only shown changes from one build to the next, so I’ve recently spent some time working on adding line charts (using the Google Chart API) to show how the metrics have changed over time:

Line charts for the same application as above

The line charts are configured so that “up is good”. They give an immediate (albeit subjective) view on whether the internal quality is improving. We’ve only had these for a few weeks and it will be really interesting to see how easy it is to get all the lines to go up or at least remain stable** and whether improvements in the metrics are reflected in the cost of change.

In part 2 I will talk about how we can use these reports in combination with other visualisations to help us understand how code modifications affect internal quality.