I discovered the Cobertura code coverage tool the other day.  It is an elegantly simple tool, which produces simple, easy to read reports.  My current project is using Apache Maven for its build system, and with the Cobertura Maven plugin provided, I simply added a couple of lines to my project file, and ran a build.  From start to finish, I spent less than five minutes to go from nothing to having some really useful code coverage data.  The report even includes a code complexity metric to help you identify the more complex areas of code.

I’m impressed by the simplicity of this tool – quite a few years ago, I spent months and months getting code coverage data for a large project (code coverage was relatively new then), and it’s great to see how easy it has become to use this technology.  I’ve previously used Emma for code coverage, which is also a great tool, but I think Cobertura has the edge when it comes to reporting.

Every time we add a new configuration option, switch or dial to our software, I get a little edgy.  I work on a very small and outwardly simple software component, which has grown over the years, as more and more people have come to use it.  Without fail, every time someone new tries to use the software, or someone tries to use it for a different project than before, they ask for a new option to be added – “it would be great if it could just do XYZ”.  Every single one of these requests is completely reasonable, and would ostensibly make the software better.  Combine all of them, and you have a usability and (perhaps more importantly) a testability problem – every dial and switch that we add means a new combination of things to test.  What you can end up with is a slightly larger, and outwardly quite complicated piece of software.

This is a problem that plagues software, and there’s no good answer – when you get a customer who says “I need feature X before I buy”, then of course you want to add that feature – it’s just that eventually, you can end up with a mess.  Apple is a company that I think does well to resist this temptation, but probably reduces its potential market share as a result – that’s a tough one to call.

Interesting reading (see the section entitled “The Question of Preferences”): http://ometer.com/free-software-ui.html