Some interesting new tools in the field of continuous integration and code analytics are getting to speed and are exceeding past the old first-movers.
Two such tools are the build server Hudson and the “Code quality management platform” of Sonar. The first gives you a very quick to install and get running build server, with a very inviting and intuitive user interface and an open platform for third party plugins. Forget the dinosaurish CruiseControl (for Java at least) as the open source build server, Hudson serves you way better.
Your development team will love the excellent dashboard with sunshine and clouds showing how your projects are doing, and the metrics graphs with history of build and test results, build times, tasks etc. In terms of “smartness” it is said to read your Maven pom.xml and ensure that dependent builds are ran in the correct order (still need to try that).



Sonar joins a number of open source code analytics tools and puts it into a nice but at bit over cluttered dashboard. Look here to see a Sonar site of the Apache frameworks. I just want to show one of the features which I find most useful, the coverage cloud:



It identifies the classes probably needing an extra look, because complexity is running high and code coverage are running low. Brilliant way of visualizing code quality.

But remember: one thing is to know the state of your code –  another is to act wisely on it. Code coverage derived from automated test suites does not tell you, if you have assertions in your unit test. Without assertions you can add and delete code without test failing.
The violations of code quality rules and the complexity measures of you components, does not tell you if your design is thought out well, or express the domain your trying to support, only a combined effort of analysis with your customer and experiments can reveal this for you. But on the of path of getting less variation in code and fewer defects – that this getting closer to software nirvana – I will not be without Hudson and Sonar giving me daily updates on how we are doing.
By Jesper Thaning

Creating quality software on a continuous basis is a complicated business.

I think it is a sign of maturity if your team can admit that there are daily problems which are ultimately obstructing flow. While not everyone will appreciate that your team does a complete halt until the obstruction has been removed I think it is a necessity for a team to stay in good shape and continue to deliver frequently.

Just the other day I came to think about what were the most common obstructions of flow we see in software development environments. So here is my preliminary list -- I bet you have seen them all.

1. Build breaks
If you don't have a build, you don't have anything. Nobody is able to do any progress progress as the state of the product is unknown. Developers cannot check-in, as they will not get any response from the continuous integration environment. Testers cannot try out the latest build. Users cannot see the product in action, and the list goes on. A build break is like a blindfold, and you should treat it as such. Don't try to go anywhere until you have your vision back.

2. Test failures
If you have a failing test, you have dysfunctional software. Imaging somebody fitting some cool new styling parts on to a car with a busted engine. Now, who would ever do that? It really is the same with software. Why do any feature work on a software product which has a failing test? I know this can be hard to respect, especially when a deadline is closing in on the team. Deadlines however, does not justify continuing without stopping the line upon test failures.

3. Bug reports
If you have bug reports, you have dysfunctional software. There is no need to do any feature work, until the product is stabilized. Bug reports are even worse than failing automated tests as those bugs can only be reproduced by a human. You should not spend work hours on anything but writing tests for these bugs, and fixing them.

4. Any other blocks keeping the team from a steady flow
If you are experiencing an obstruction which is keeping from moving forward as fast as you could, suggest to the team that you stop doing anymore feature work, until you are able to eliminate the obstruction. One obstacle which I think is quite common is builds that take way to long time. "Yeah, but how can you build 2 million lines of code in less than two hours?" -- Well, I suppose you could start by reorganizing your code and build only the module related to a particular source control check-in. Hopefully you don't have modules consisting of 2 million lines of code!

I'd like to hear about any other obstructions you may have experienced in a software development environment.

By Sune Gynthersen