Developing software ain’t easy.

How do you know how you are doing ?

You could start collecting metrics about your code. These can give you some indication how maintainable and  reliable  it is.

The metric which come to mind to the most people is code coverage. Some people say it must be near 100%, other say 80% is a good number. At the end it can’t tell you if you are doing great or good. The only thing you might read from it is that a low number indicates a potential problem.

Duplication is another one you should look out for. A high number of duplicated code might bring up the problem that a bug was fixed in one place but lives on in other. If you are doing code generation (e.g. from WSDL’s) you might have a lot of duplicated code reported to you. A closer inspection is needed to really make sure this is a problem in the code you have written and is not auto generated.

Test success is not a metric you should be worried to much about. It just needs to be 100% at every checking in a shared repository. No discussion.

Cyclomatic complexity let’s you measure the number of linearly independent paths through your code. A high number means a more complex code. A complex code base is hard to maintain and involves a lot of work to adopt it to new requirements.

Dependencies between packages is another important value to check on (see Uncle Bob’s paper on Acyclic Dependency Principle). Basically it revolves around that packages should not have cyclic dependencies between them since this does have an impact on releasing and testing (and therefore coding). A change in one package could trigger a whole system build to make sure everything works together.

Tools like Findbugs let you define rules to which your code should comply to. This is great because it is tailored to your code/company and ensures you control and fine tune the measures. Or so. It requires some time to define these rules. They need to be refined over time and you have to understand them to make use of it. Of course you can leave out some of these and reduce complexity. Do not underestimate the effort to implement these.

This rounds up the metrics you can get from your code base.

But wait, there is more.

A valuable metric is the meantime between reporting a feature or bug and fixing. This gives your team (and management of course) a rough estimate how fast you can react to market changes.

To get an estimate of the mean time before a failure happens you can measure the time between two bugs. The higher the number the better. Current reported bugs per lines of code can also be measured. These metrics will give you some confidence in your code base.

At the end of the day the ultimate measure is the money on the company’s bank account. If this is not working out you are in trouble.

How to get all of these ?

There are some static code analysis tools to get you started. I only can talk about Java related tools but there are others as well.

• Checkstyle
• FindBugs
• PMD
• Cobertura
• Structure 101
• Sonar

To get more information about your bugs should query your bug tracking system like Jira or Bugzilla.

Summary

There are much more numbers out there but I think these are the ones you should always keep an eye on.

Look out for

• Code Coverage
• Duplication
• Cyclomatic complexity
• Cyclic dependencies
• Test success
• Time to market
• Mean time between failure

What metrics do you look out for ? Let me know in in the comments and why.

What is Extreme visibility?

Extreme visibility is all about providing information about the code to every team in near real time. We show several metrics such as complexity of the code (xs), todo’s, deprecated methods, number of broken builds, open tickets and their priority and so on. These are distributed over a couple of screens which our software is rotating through. Every team member can easily see if his or her commits effecting the code quality in a good or bad way and makes the members aware of certain quality standards we try to keep in our code base.  A typical screen looks like this (mockup):

Extreme Visibility

We discovered that showing these kind of statistics to the team has the effect that everybody in the team room cares about the numbers (and therefore the code quality). Without this display you just don’t know how your changes will effect the overall quality of the code. It might seem a bit threatening to individual team members at first (like we do show who checks in without a commit message) it turns out this is not really a problem.

While we did provide very detailed information in the past about the trunk and every branch (every user story is on it’s on branch), we found out that too many screens are counter productive and results in not caring about the values displayed too much anymore. We also do believe that showing time line and progression information on several metrics are very motivating to the team. We are planning of tweaking the information this way in the near future.

The software we use is written by ourselves in Grails. On the front end we simply have Firefox running a full screen mode. Every team has a big screen TV  connected to a computer (turns out I could connect my Sega Dreamcast too). We did collect some good feedback and learned a lot about the usage in the last couple of months. The next step now is to enable the teams to write their own modules to provide the information which is the most useful to them.

I’m not aware of any open source (or other) software doing the same kind of thing. Writing it by ourselves we could tailor it to our specific needs like showing svn information, showing Teamcity build statistics or information about the code using Structure 101.

Overall the team I’m working in is very happy with the information we get from our extreme visibility monitor. XV makes sure we all can see  how the quality of our code develops and we get warning signs to take counter measures to bring it back on track. And that’s what we want after all .