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

Just the other day I was thinking about the core ideas of Agile software development, and I believe I came to an interesting conclusion. I think the core of agile development is all about one thing -- Aggressively attacking risks. Well, maybe there is more to it  but that is what I'll talk about in this blog entry.

Whether you start up a new software project, or join an existing team that has been constructing something for years, you need to consider what the risks to the project are, and especially what you can do about them.

Risk of not shipping on time (or not shipping at all)
Practice makes perfect. Start shipping from day one -- That is, for instance ship a new release every week. Naturally it depends on the kind of product you are working on, but more than often this is perfectly feasable. In fact, this happens every single day for many web-applications, and users may not even notice.

Risk of building the wrong thing
Have developers work closely with users throughout the project, and encourage them to build an executable and testable model of the business domain, without too much focus on integration. This ensures that the product can in fact solve the core business problem.

Risk of not being able to integrate different parts.
If there is a risk of integration issues, practice! Integrate risky parts from day one of the project. For instance, communication protocols that you haven't tried before may be risky. While accessing a database may be a walk in the park. Find out which integration points require early integration, and balance those efforts against the efforts involved with the risk of "building the wrong thing".

Risk of high long-term maintenance costs.
What you need is a software solution to a business problem. What you don't need is unneccessary technical complexity. Aggressively attack complexity, and make sure your product is still capable of solving the business problem.

Risk of shipping software with defects
Where are your defects? In the business logic, or at the integration points between different modules? No matter which, the answer is simple: Test it (automatically) -- From day one! And use every single defect found, to improve the development process so that you introduce less errors in the future.

Risk of unacceptable performance issues
Have your team commit to a measurable performance goal. ...And you never guessed -- Measure it from day one.

The key to long-term success, is knowing what your long term success factors are, and figuring out how to address them on an everyday basis. What is our long-term succcess factor? I bet you are looking for a cost/earnings ratio close to zero viewing at the entire lifecycle of the software product. This is done by either increasing the earnings, or lowering the cost of development and maintenance. Also a short time-to-market is most likely attractive to your company. Thus, address those every day.

That's it for now. Keep working on reducing your risks out there.

 

By Sune Gynthersen