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

The other day Danish newspaper Politiken had an article about how Toyota is renting a ship to store unsold 1200 cars in the harbour of Malmö, the Swedish town just across Øresund from Copenhagen. My guess would be that there's some hansei - reflection in Japanese - going on at the world's best manufacturer and the inventor of Lean. Obviously, Toyota has been producing to forecast and not to actual custumer pull. Some of the questions the people at Toyota probably could be asking themselves are these: Why didn't we sense the actual market conditions during the fall of 2008 and changed our production schedules? Why did we resolve to wishful thinking about customer demand? Why did we end up with overproduction? - the worst of Toyota Production System genius Taichi Ohno's seven types of waste in manufacturing.

When I saw the picture of unsold cars accompanying the article in Politiken I once again had the thought: Wouldn't it be nice if overproduction could be much more visible in software development? In much software development people are also producing to very uncertain forecasts without being in contact with the actual customer pull. And in software development the forecasts come in the form of big specifications of features that in many instances end up being delayed. And even worse, features not being used by the users when finally implemented.

If we had to rent ships to store all the implemented, but unused features, there might be some more hansei going on to avoid implementing those features in the first place?

By Thomas Blomseth