Metrics in practice
July 5th, 2008 at 4:08 pm by Arjen van Schie
This blog is about software metrics in a very broad interpretation; software quality metrics. During our last project we wanted to elevate the software quality and the quality of the software development process. The first thing that came to our mind was to focus on metrics to evaluate and guide the quality of the code, but after further thought we decided this was not the complete answer. We needed to upgrade our development process first. On the other hand we didn’t want to try it on the whole project so we decided to build one component using the new strategy and the other using the default one.
To realize a better workflow the first thing we did was to implement a build-server. We used CruiseControl which suited perfectly for the task, it’s pretty easy to setup and it has a lot of extension points to combine it with all kinds of tools (notifiers, automated tests, software—metrics, version control etc.)
This way we would be able to keep an eye on the status of the code in version control. And we could see when the software ‘breaks’ or works. Well actually we could only see if it would compile, which is not the same 
So we installed the automated testing component of CruiseControl and were ‘ready to rock’ the project.
Then again, automated testing only works if you got the right tests. So we decided to use the test-driven approach. First write the test, then the code. This way the build server could tell us, what functionality was thought of, and which part was actually working.
Was this it? Well not really, as the test-driven approach was new for our team it was easy to fall back on the old approach, with the risk of writing more code then was necessary to pass the test. Resulting in untested code.
To pin-down this risk we decided to integrate test-coverage into the build-server, cobertura. This way we would be able to see what code was touched by the test and what code not.
What did we learn with our experiment? First of all it felt like the whole process was going a lot smoother, the test driven approach and tooling made us feel much more confident about the quality of our work. And we realized a pretty high velocity, (the work was done much faster then expected).
This project was for a backend component which I think suits the testdriven approach better then a pure frontend component.
So using this approach(TDD+Cobertura+CruiseControl) for this project helped us achieve a better software engineering process. And it’s very likely that we’ll re-use this approach on our next project.
Popularity: 847 points
July 7th, 2008 at 11:43 am
Great to read that this approach appears to be so successful. In one of my previous projects we also used this approach and felt very confident about it. At one point we decided to use Jetbrains Teamcity as our buildserver instead of CruiseControl. We choose Teamcity for its ease of use and nicer looking AJAX GUI. Teamcity is free for up to 20 users.
July 8th, 2008 at 8:20 pm
Great to see that this continious integration approach is applied in projects at Logica! Arjen, can you tell me if you eventually used an extension to evaluate the metrics and how that was adopted by software developers on the project?
And what was the reaction on publishing test-coverage? I have the feeling that a risk of showing test-coverage is that people will write useless tests just to stimulate the amount of test-coverage. What is your experience in this particular project?
July 9th, 2008 at 2:45 pm
We didn’t apply software metrics as part of the build process. The reason for this is that in my opinion it is better to evaluate them once in a while instead of continuous, to prevail the metric driven development risk.
On the other hand the code coverage metrics were used to guide the team. Failing test were fixed quite fast. And it was aimed to keep the coverage above 80%.
Because it was a new code base with test driven approach, the chance of useless test-code(trivial tests) is marginal. Because the code you write is supposed to be preceded by test(all code should be written to pass a test, and no more).
Although I won’t claim there isn’t any trivial test at all.
March 20th, 2009 at 11:15 am
[...] - bookmarked by 1 members originally found by joersch on 2009-02-22 Metrics in practice http://www.bloggingaboutjava.org/2008/07/metrics-in-practice/ - bookmarked by 1 members originally [...]