Lars Trieloff's Collaboration Weblog

Did I already mention that I am a fan of Hudson? Yes, I did, but this new feature is too nice not to blog about:

I've updated to Hudson 1.200 to fix a bug with Maven 2 multimodule builds, and was surprised by the new long-time build trend indicator that shows you the "build status weather report". At a glance you can see if the current build is a stable build in a row of stable builds or if it just has been fixed or broken. A really nice feature.

Whenever I install or upgrade Hudson, the easy-to-use, Java-based continuous integration server, I am positively surprised how quitely and effectively new features are added and implemented. This time it is the dependency tracking of projects that is automatically extracted from Maven pom.xml files which leads to a complete rebuilt of all upstream projects once a dependency has been changed.

In any case you should check out the interview with Kohsuke Kawaguchi, creator of Hudson at java.net.

The last two days Jan, intern at Mindquarry spent fixing a bug in Cocoon's AJAX form handling. In the end Alexander and I joined him because we had more experience with Cocoon's internals and finally we found and fixed the problem. Having identified a bug, but not the bug's cause or resolution is a terrible feeling. You try this approach, you try that approach, you discuss, consult search engines, and feel more and more incapable of understanding the problem. But once you have found the solution, you feel great, you feel like being able to grasp the most complex technical structures.

I keep saying "Software development is 90% baning a head agains the wall and 10% breaking through the wall". Bug fixing multiples this principle. 99% of the time, the actual bug fixing, searching for the cause and solution makes you feel bad, but the 1% of time when the bug is finally fixed is simply great. The joy of bugfixing outweights the pains of fixing the bug, this is way bug-days when a whole development community spends a day fixing bugs are so popular.

Cedric Beust, lead developer of TestNG writes in More testing doesn't mean less debugging

This myth that "testing means no more debugging" needs to die. Seriously. Anyone making this claim is doing a lot of damage to the software engineering world. Just as we are finally getting good IDE's, good debuggers and, more importantly, an increasingly widespread conviction in the developer community that these tools are part of a healthy software engineering process, a new vanguard of smug programmers come out of the woodwork with their superior attitude and resurrect the old mantra that only bad developers use debuggers.

Cedric continues to point out how the debugger has become an invaluable tool for software development as it allows him to verify his assumtions during development, to examine the runtime behaviour of the software, as the pure static sourcecode is just a description of a software system.

The value of unit tests in regard to debugging is that they allow more structured, repeatable debug situations. I use test cases to create situations that need further verification and can then step through the program at runtime.

Some days ago I wrote about Hudson, a continuous integration server:

It is not as feature rich as some other continuous integration systems listed on the Continuous Integration Server Feature Matrix, it's Maven integration is not as deep as Continuum's but it does its job, is easy to setup and offers a clean and friendly user interface.

At least for the Maven 2 support I have to revise my statement. With Hudson 1.78 released yesterday there is experimental Maven 2 support. Kohsuke Kawaguchi, creator of Hudson writes:

Since I rely more on Maven2, I wanted more Maven2 support in Hudson. It can already build a Maven project, but it didn't natively understand Maven — so you still have to specify what jar files to archive, what javadoc to copy, what builds to run once your build is finished, etc. But since much of the information is in POM already, I thought it would be really nice if Hudson can understand POM. So I started working on this some time ago, and it's finally getting into a presentable shape. The newly posted Hudson 1.78 is the first version with this feature enabled.

One thing I like most is the relatively loose integration with Maven. In Continuum for example you have to upload a pom.xml and if this pom does not include properly configured version control system links, you cannot start a build. With Hudson you still have the opportunity to start with an underspecified pom and a Subversion URL and your sceduled build is prepared in minutes.

For one week we (Mindquarry) are now using Hudson as a continuous integration server. It replaces our old CruiseControl installation and so far I am very satisfied with Hudson's performance: It was very easy to setup:

1. install Apache Tomcat 5.5
2. download hudson.war
3. start tomcat

With Hudson's web-based administration user interface I could setup tasks for every Mindquarry sub-project without editing configuration files, everything I needed was pointing Hudson to the Subversion URL and enter the maven goals. Hudson sends e-mails to everyone who broke the build and the project manager, creates RSS feeds, has a nice user interface and just works.

It is not as feature rich as some other continuous integration systems listed on the Continuous Integration Server Feature Matrix, it's Maven integration is not as deep as Continuum's but it does its job, is easy to setup and offers a clean and friendly user interface.

In fact, in the beginning of the Hudson project, it was heavily inspired by DamageControl, a Ruby-based Continuous Integration Server project that I contributed to, but evolved into a stable and useful project of its own.

Frank Kelly's excellent blog article Analyze This - Put your code on the couch! discusses the most important bugs and code smells the three static analyzers Checkstyle, PMD and Findbugs are able to find. Together with unit testing and code coverage for dynamic quality assurance they can help you creating much better Java code.

Luckily there are Maven 2 plugins for all three of them:

• How to use the Maven 2 Checkstyle Plugin
• How to use the Maven 2 PMD Plugin
• How to use the Maven 2 Findbugs Plugin

Signal vs. Noise, contains an interesting entry about the relation of Writing words vs. writing software. The basic idea of this post is that programming software is very similar to writing a book or a blog entry, because the most important aspect of writing is rewriting, constantly improving what you have done in order to achieve better quality. And also for software development, the ability to rewrite, or to refactor your code is most important for achieving great quality.

Of couse, there are more similarities: Writing and software development require a great deal of analysis of the problem, conceptionalization and abstraction. There are many different parties involved, the writer or developer, domain experts, editors, QA persons, testers and so on.

In order to achieve the best results, recognition of the importance of the teamplay of all involved parties is essential. After realizing the importance, proper means to optimize the teamplay are to be taken in order to make writing or software development an experience of productivity.

Measuring the value of anything is a hard task, but it is much harder to measure the value of intellectual goods. And it is even harder to measure the value of something that is given away for free like Open Source Software. Or as Oscar Wilde put it:

A cynic is a man who knows the price of everything but the value of nothing.

When it comes to measuring the value of software, the most obvious approach is to calculate the cost of development by assuming a proportional correlation between lines of code and cost of development as done by koders.com. The flaws of this approach, even if it uses more sophisticated parameters like age of project and number of active developers as done by Ohloh have been described by Steve Loughran: Dubious Statistics. The salaries of developers are far-fetched, they do not include real costs for the employer or customer and there is no way to take quality into consideration.

But even if these flaws had been corrected, e.g. by adjusting salaries to average salaries for software developers in the respective contries and only tested lines of code had been counted, the main point of value is not considered: the value to the user.

Take for example JUnit. koders values this framework with 25.000 USD, Ohloh with 143.000 USD, but none of them catches the invaluable impact JUnit had on today's best practices for Java development. This little test framework created an unified way of measuring quality of software projects. It set the minimum standard for development practise and it prevented millions of bugs.

Even an automated value guessing system should try to take usage and usefulness into consideration, e.g. by estimating how many other projects are relying on the code, how many users are posting to the mailing list of a project and how many weblogs lik to it's homepage.

xml.com features an interesting series on metrics for XML projects. So far most of the metrics focus on measuring XML schemas, not XML documents, but they are nevertheless worth reading:

• Element and Attribute Count
• Production Count
• XML Mapping Completeness Ratio
• XML Mapping Additions Ratio
• Structured Document Complexity Metric