The Sonar team is proud to announce the release of Sonar 2.2. As usual, this new release includes numerous improvements, bug-fixes and also brand new features that we believe are worth stopping your daily work for a few minutes to review. Those features can be divided into three categories :

• Favourites resources
• Filters homepage
• Plugin classloaders

Favourites

When you are working in a company that makes an intensive usage of Sonar, the project(s) you want to monitor can be quickly lost among hundred of others projects. Favourites makes it possible to flag those projects but also modules, packages and files. You then get quickly an overview of those resources at any time.

To use this feature, the user must be logged into Sonar. Resources can then be flagged by clicking on the star icon available in the “Dashboard”, “Components” and “Filters” pages :

Once a resource is flagged as a favourite, it is automatically displayed in the “My Favourites” tab in the homepage :

Filters

The Sonar homepage had several drawbacks when Sonar was intensively used :

• Displaying the page took too much time with more than 500 projects
• Only root projects were displayed
• There was no way to quickly get a list of resources according to some criteria. For instance, the list of projects whose technical debt ratio is greater than 10%, the list of Files whose complexity is greater than 300…
• The Treemap was too small and so not usable with many projects
• There was no way for a user to customize the homepage

The new “Filters” page allows to overcome those limitations :

Of course, this feature comes along with configuration capabilities :

Plugin classloaders

Plugins are now executed in independent classloaders. The main advantage is that plugins can declare and embed their own dependencies instead of being limited to libraries provided by Sonar. As a direct consequence, Sonar no longer depends on Maven Checkstyle and PMD plugins but now directly embed Checkstyle and PMD libraries.

To find out more about Sonar 2.2 and the 63 issues that have been fixed, you can read the release notes or maybe you prefer to download it to give a ride. Have fun !

The survey I’ve been writing about (raw results here) was intended to give us speakers at the continuous deployment webinar (Timothy Fitz, Jez Humble, and myself) some background on the attendees. I’ve saved the best (most informative) question for last: what practices do attendees use in software development. Here is the data:

Some thoughts:

• Business-based operations metrics. One of the key insights of continuous deployment is using business-oriented metrics to monitor operations instead of the more natural (for programmers, anyway) technical metrics. If you expect 50 sign-ups per minute and the rate suddenly dips to 20/minute after a deployment, it’s time to roll back. The practice is not in common use.
• Kanban versus iterations. Iterations still dominate, even though the additional flexibility of kanban is a better match for continuous deployment.
• Pair programming. For all the complaints I hear about pair programming, I would have expected this number to be lower than 25%.
• Test-driven development. 50% is higher than I would have expected. Adoption of TDD is excellent preparation for teams wishing to deploy more frequently (see my commercial screencasts for more details).
• Continuous integration. I expected this number to be higher. CI was the first practice from Extreme Programming to spread widely, but, at least among this audience, it is not pervasive.
• More than 75% of teams test manually before deployment. This is a sensible practice until the defect rate is brought down and the operations infrastructure made robust in the face of errors, but I expect the number to drop as teams mature in their application of continuous deployment.

Change generally happens on a time scale of decades. Mass production and then lean production each took upwards of fifty years to become widespread. I don’t mean to be overconfident, but the picture above (skewed as it is by selection bias) paints a picture of software development that is substantially different than common practice twenty or even ten years ago. There’s still a long way to go until software development pours out the stream of value it is capable of, but we’re making progress.

Commercial plugs: Check out my series of screencasts on intermediate-level test-driven development, $25 for four episodes. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin, $50/year until August 1, 2010.

Today’s question is, “How often do you commit code changes to the shared repository?”

One of the essential practices of continuous deployment is that everyone stays very close to the mainline, typically by checking progress into HEAD frequently. This requires developers to be careful to only make changes that are safe and to only reveal functionality when it is ready for real users. The change of task sequence this requires is an acquired skill, but once mastered results in a low-risk development style.

The data shows that many projects are checking in very frequently:

The question needs followup, as it doesn’t ask whether there is a single mainline that people continually integrate with, and which direction the integration goes.

Tomorrow is the final question of the survey, which asks which practices folks are applying.

Commercial plugs: Check out my new series of screencasts on intermediate test-driven development. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin.

Props to Chartpart.com for the lovely front end for Google Charts.

Running functional tests generally takes longer than running unit tests, so as expected, most people run unit tests more frequently than they run functional tests:

I was a bit surprised at how many people are running tests on every change, but that’s good news for JUnit Max, which shaves seconds off the delay waiting for feedback from tests. If those delays happen a hundred times a day, the cumulative effect of a tool like Max can be substantial. I’m not sure what to make of the teams that run unit tests daily or weekly. I’d like to talk to such a team to understand more about their process.

Unit testing wasn’t explicitly addressed by any of the presenters at the Continuous Deployment webinar, I think because unit testing is assumed when you’re deploying on a short cycle. I don’t recall who said it first, but the model I use is that the defects leaving any stage are proportional to the defects entering that stage. No matter how good your functional tests are, defects leaving the programmer’s desk need to be rare if the software is always going to be ready to deploy.

Following up on the continuous deployment survey question about frequency of deployment, the question for today is, “How often do you run functional tests?” Here is the data:

What I take from this is that there are a considerable number (~30%) of people using continuous integration in the poll audience. The ~10% of people who have brought functional testing into the inner loop of coding is also a bit surprising, although we do it to great effect while developing JUnit. Another surprise to me is seeing that the majority of these projects get feedback from functional tests every day.

All the panelists (Jez Humble, Timothy Fitz and I) agreed on how essential automated functional testing is to applying continuous deployment. I think of it as a stack of filters, each removing defects–personal habits, social processes (like pair programming or reviews), unit tests, and functional tests. If the functionality flowing from the whole stack is high enough quality, then continuous deployment is possible.

Manual testing has a place in projects applying continuous deployment, just not on the critical path to deployment. It might seem like a big step to remove that last human “sanity check” before deployment. If it seems like a big step, then you’re likely not ready. Keep working on the filters to improve the deployability (is that a word?) of each one’s output. When you heard someone say, “Why are we checking this by hand? We never find anything,” then you’re ready.

Next question: how often do folks run their unit tests?

Commercial plugs: Check out my new series of screencasts on intermediate test-driven development. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin.

In conjunction with the Leaders of Agile webinar on Continuous Deployment I hosted yesterday for SD Times, I ran a poll asking attendees about various of their development activities. I’ll be posting a short piece about each question, the answers we got, and the webinar material that connects with that question.

My co-presenters were Timothy Fitz of IMVU and Jez Humble of ThoughtWorks. Timothy talked about continuous deployment in a large web/client application with ~50 developers while Jez covered CD for IT applications. Both made a nice contrast to my experiences with CD for individual or pair projects, and immediately addressed the “sure, but it won’t scale” objection. My thanks to Timothy, Jez, and Alan Zeichick of SD Times for their work setting up and delivering the webinar. (I’ll post here when a recording is available.)

For the poll, the questions were posted two days before the webinar. We had ~200 responses out of the 1100 registrants and 430 attendees. Beware of extrapolating too far from the data because the poll suffers from both selection bias and an amateur question author (me). However, the responses do provide some idea of how at least a slice of our industry works.

The first question I will cover from the poll is, “How often do you deploy to production?” That’s the fundamental measure of continuous deployment, at least as narrowly viewed (more about that later). Here’s the raw data:

Deployment cycle starts with the orange slice for annual deployment at the bottom right. Going clockwise from there, the three biggest slices (quarterly, monthly, weekly) take up most of the chart. Completing the circle, there are almost as many people deploying on every commit as deploying annually, so continuous deployment already has significant traction.

One of the surprises of the webinar was Jez Humble’s flexibility with regards to how far towards real deployment Continuous Delivery (his phrase and the title of his forthcoming book) needs to go. His strategy is to take the rapid iteration that is made possible in development by Extreme Programming and gradually extend it down the deployment pipeline, even if that stops short of real actual live deployment with real actual live users. My general preference is to work the other way around. I like to get the whole team–business, development, and operations–working with the same rhythm, then gradually increase that rhythm. There’s no right or wrong approach, it’s just interesting to see the contrast.

Next question: how often do you run functional tests?

Commercial plugs: Check out my new series of screencasts on intermediate test-driven development. If you run unit tests for Java in Eclipse, check out JUnit Max, the continuous testing plugin.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Use Sonar to Develop a Quality Feedback Loop into the Build Cycle

By Brian Chaplin on ServerSide, 29 june 2010
The number of business defects in an application tracks with the number of technical defects. More technical defects normally means more business defects. This means that technical defects can be used as a metric for the overall quality of a development approach. Sonar is a great dashboard for tracking code quality at the project and file level. But how can it be used to as part of the daily workflow?

Making the Most of Maven: Nexus, Hudson, Sonar
By Joel Confino, 15 June 2010
Maven is a build tool. I like Maven because it supports dependency management, consistent builds and a modular code base. But if you are just using Maven without using Nexus, Hudson, Sonar you are really missing out on a lot of goodness. Nexus is a Maven repository manager, Hudson is a CI server, and Sonar is a code metrics server.

Google Summer of Code 2010 with Sonar team – first steps
By Evgeny Mandrikov, 7 June 2010
As I promised in previous post, that progress of my work on Google Summer of Code 2010 would be available publicly – here is a brief overview of what was done for Sonar IDE project, what we have now and what expected in nearest future.

The Code Quality game
By Ricki Sickenger, 4 June 2010
Most programmers think they can recognize good code and a lot of them think they produce good code, but the sad truth is that not a lot of programmers actually do. Between time constraints, feature creep, and laziness, programmers hardly ever end up producing super quality code.

Code-Metriken auf dem Prüfstand
By Sandro Ruch, 4 June 2010
Wie lässt sich die Qualität von Code bestimmen? Welche Kriterien sollen dafür hinzugezogen werden? Eine mögliche Antwort könnte sein: “So gut wie die Abnahme-Testresultate des Kunden”…

Changing a project’s artifact id in Sonar
By Oliver Gierke, 2 Jun 2010
Sonar is a great tool to take care of code quality in your software projects. I use it heavily to monitor the open source projects I am involved with. When working on getting Hades published into Maven central I had to polish it’s pom.xml and felt the need to align the parent project’s artifact to our chosen OSGi compatible package notation for artifacts

Code Quality Management Tool Sonar Provides Design and Architecture Metrics
By Srini Penchikala on InfoQ, 1 June 2010
The new version of open source code quality management tool Sonar provides design and architecture metrics. Sonar 2.0 introduced the analysis of design, architecture and object-oriented metrics for Java applications. And Sonar 2.1 version, which was released recently, supports the detection of unused methods.

It has now been more than ten years since Kent Beck and Martin Fowler started to talk about Continuous Integration. At that time, it was hard to believe this practice would have such an impact on our daily work and would be so much adopted in the world of software development. Today, we at SonarSource but also in many places, can simply not imagine to go back and work without Continuous Integration.

Here is what can be read about Continuous Integration on Wikipedia :
Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.

The ultimate goal of Continuous is to be able to fire any type of release at any time with minimal risk whether it is a Milestone, Release Candidate or GA : quality requirements become a must-have and no more a nice-to-have. Let’s review which requirements are correctly covered by continuous integration environments today :

• Anybody must be able to build the project from any place and at anytime.
• Every Unit Tests must be executed during the Continuous Integration build.
• Every Unit Tests must pass during the Continuous Integration build.
• The output of the Continuous Integration build is a package ready to ship.
• When one of the above requirement is violated nothing is more important for the team than fixing it.

This is a really a good starting point but does not sound sufficient to talk about total quality . What’s about those other source code quality requirements ?

• Any new code should come with corresponding unit tests (regardless of previous state in code coverage).
• New methods must not have a complexity higher than a defined threshold.
• No cycle between packages must be added.
• No duplication blocks must be added.
• No violation to coding standard must be added.
• No call to deprecated methods should be added.
• …

More generally, those requirements are about keeping overall technical debt under control and only let it increase consciously (see the Technical Debt Quadrant) : this is the concept of Continuous Inspection. This concept seems to have appeared around five years ago (see this IBM Article) and has been recently described and defined (see DZone Refcards 87 about Continuous Integration and Continuous Inspection, see book “Continuous Integration : Improving Software Quality and Reducing Risk” ) but is still an emerging concept as was Continuous Integration ten years ago.

Continuous Inspection requires a tool to automate data collection, to report on measures and to highlight hot spots and defects. Sonar is currently the leading “all-in-one” Continuous Inspection engine. A Continuous Inspection engine can be seen as an Information Radiator dedicated to make the source code quality information available at anytime to every stakeholder. Transparency is certainly one of the main reason why Open Source Software is most of the time of better quality than Close Source Software. A developer writing a new piece of code should always think about the next person/team who will maintain it : Continuous Inspection helps to never forget this golden rule.

But of course, Continuous Inspection only comes after Continuous Integration is solidly implemented : this is the next maturity level and this maturity level can be implemented with Sonar.

I’m pleased to announce that TestDriven.Net 3.0 is now available. Finally! I know many of you will already be using the Beta and RC versions, but if you look at the release notes you’ll see there’s been many refinements since then, so I highly recommend you install the RTM version. Here is a quick summary of a few new features:

Visual Studio 2010 supports targeting multiple versions of the .NET framework (multi-targeting). This means you can easily upgrade your Visual Studio 2005/2008 solutions without necessarily converting them to use .NET 4.0. TestDriven.Net will execute your tests using the .NET version your test project is targeting (see ‘Properties > Application > Target framework’).

There is now first class support for MSTest when using Visual Studio 2008 & 2010. Previous versions of TestDriven.Net had support for a limited number of MSTest attributes. This version supports virtually all MSTest unit testing related attributes, including support for deployment item and data driven test attributes. You should also find this test runner is quick. ;)

There is a new ‘Go To Test/Code’ command on the code context menu. You can think of this as Ctrl-Tab for test driven developers; it will quickly flip back and forth between your tests and code under test. I recommend assigning a keyboard shortcut to the ‘TestDriven.NET.GoToTestOrCode’ command.

NCover can now be used for code coverage on .NET 4.0. This is only officially supported since NCover 3.2 (your mileage may vary if you’re using the 1.5.8 version).

Rather than clutter the ‘Output’ window, ignored or skipped tests will be placed on the ‘Task List’. You can double-click on these items to navigate to the offending test (or assign a keyboard shortcut to ‘View.NextTask’).

If you’re using a Team, Premium or Ultimate edition of Visual Studio 2005-2010, a new ‘Test With > Performance’ command will be available. This command will perform instrumented performance profiling on your target code.

A particular focus of this version has been to make it more keyboard friendly. Here’s a list of commands you will probably want to assign keyboard shortcuts to:

Name Default What I use TestDriven.NET.RunTests Run tests in context   Alt + T TestDriven.NET.RerunTests Repeat test run   Alt + R TestDriven.NET.GoToTestOrCode Flip between tests and code   Alt + G TestDriven.NET.Debugger Run tests with debugger   Alt + D View.Output Show the ‘Output’ window Ctrl+ Alt + O   Edit.BreakLine Edit code in stack trace Enter   View.NextError Jump to next failed test Ctrl + Shift + F12   View.NextTask Jump to next skipped test   Alt + S

 

By default the ‘Output’ window will automatically activate when there is test output or a failed test (this is an option). The cursor will be positioned on the stack trace of the last failed test, ready for you to hit ‘Enter’ to jump to the fail point or ‘Esc’ to return to your source (assuming your ‘Output’ window is set to auto-hide).  If your ‘Output’ window isn’t set to auto-hide, you’ll need to hit ‘Ctrl + Alt + O’ then ‘Enter’. Alternatively you can use ‘Ctrl + Shift + F12’ (View.NextError) to navigate between all failed tests.

 

For more frequent updates or to give feedback, you can find me on twitter here.

I hope you enjoy this version. Let me know how you get on. :)

The Sonar Team is very proud to announce the availability of the first version of the Sonar Eclipse plugin. This plugin is part of the Sonar IDE Project. This first version comes just few a weeks after the release of the Sonar IntelliJ IDEA plugin. The project has 2 active contributors : Jérémie and myself.

The work has been greatly facilitated by the good feedback we received from the Sonar community on the release candidate version. It is going to be followed by new ones in the upcoming weeks/months (see My proposal for GSoC (Google Summer of Code) 2010).

This version 0.1 only displays violations. Duplicated blocks, code coverage and commented out lines of code will be added later. As for the Sonar IntelliJ IDEA plugin, source code is decorated on the fly with information provided by the Sonar web server.

As usual for releases, let’s go through screenshots to discover this new functionality and how it can be used in your daily work to track violations. Enjoy !

Configuration

By default, the plugin tries to reach a local Sonar web server on port 9000 to get violations. But it is possible to define different and several Sonar web servers to use in the Eclipse global preferences :

For instance, for Open Source projects available in Nemo, the configuration would be :

Once, the Sonar web server to be used has been configured, the next step is to activate the Sonar plugin on a given project. If you use m2eclipse, there is nothing to do as the groupId and artifactId of your project are automatically configured. Nevertheless, you may want to change the default Sonar server to use :

Source code decoration

Then you just have to open the java file you want to work on and violations are displayed with markers (on the left-hand side) :

Global source code Inspection

To start hunting violations on the overall project, you can use the Problems View :

Go to Sonar

At any time you can jump onto the Sonar Web dashboard directly from the IDE, to get information that is not yet available in the Sonar Eclipse plugin :

Navigator

Sonar Server Navigator allows you to browse all available projects in a specified Sonar server :

Roadmap

Next version 0.2 will allow to visualize duplicated blocks, code coverage, … directly inside Eclipse, so stay tuned.

To give it a try, you can add it to your favourites in Eclipse Marketplace or install directly using update-site. For more information you can visit Sonar IDE site.

I usually just tweet my book reviews, but this one required more explanation.

XIX Olympiad

I was seven in 1968 when the Mexico City Olympics rolled around. They were the first sporting event I devoted myself to completely. I had been happy earlier that year when the first Super Bowl was played, proving once and for all the superiority of what is now the NFC, but with the Olympics I fell in love.

I bought the whole Avery Brundage/Chariots of Fire line: amateurs competing only for the glory of sport and the honor of their nation. I was happy to US athletes do well, but I was happier to see an athlete surpass his own limitations. Bob Beamon’s jump was remarkable not because he was American, but because it was such a remarkable performance. It was possible for people to become gods, if only for a moment.

Tommie Smith & John Carlos brought a discordant note to my proceedings with their medal stand protest. My father was outraged but I understood that they had a legitimate complaint and no better way to speak of it. Still, sport was supposed to be about sport, right?

By the closing ceremony/party my discomfort was washed away in a music-powered dancing unification of all humanity. Sport was the highest and best in us.

1968 was a confusing time to be seven: body counts on the nightly news, “duck and cover” drills at school (and we lived on the Moffett Field final approach, so this was an immediate, if futile, concern), hippies, and anti-war protests. At seven I had the intellectual capacity to understand a surprising amount of this, but no emotional tools with which to deal with it personally. Don’t worry, in sport I had a perfect refuge.

XX Olympiad

Four years later I couldn’t wait for Munich to start. At first everything was as I hoped it would be. There was even a rare note of international harmony in the house because my rabidly anti-communist father, then 140 kg, idolized Alexiev. There was Dave Wottle’s incredible kick–zero to hero on the final straight. Bruce Jenner, local boy making good on the biggest stage in the world.

Then came the reports of the massacre. All day we sat glued to the TV, stunned. I was eleven at the time, so my emotions were a violent tempest in an extremely small tea pot. Bitterly furious at the Palestinians, terrified for the hostages, utterly baffled at why someone would do this to sport, to me, blindly hopeful when the choppers took off, inconsolable when it became clear that everyone was dead.

The lasting emotion was rage, rage that someone would violently pervert sport to suit their own needs. In sport I had a refuge where the world made sense and that had been ripped from my hands and smashed on the floor. I was ready to drink blood.

Psychologists tell us that when a trauma happens, people often aren’t prepared to deal with the intensity of emotions in the moment, so they bottle it up. When this happens, emotional development pauses. The theory is that by working through those stored emotions later in a safe environment, emotional development can continue. I fell like I’ve experienced a bit of this effect thanks to the book Vengeance.

Vengeance

Vengeance tells the story of an Israeli hit squad put together to assassinate eleven high-ranking Palestinians involved in terrorism, one for each dead Israeli athlete. By the end of the book this attempt to balance the books has wrought a terrible vengence of its own on the surviving members of the team. In the end, the author/protaganist is estranged even from his own country.

Debate raged when the book came out: fact or fiction? good or evil? I won’t address any of these questions here. I also don’t intend to debate the ethics of the actions described or the preceding events. What I’d like to highlight here is what the book did for me.

While I was reading Vengeance, that furious little eleven-year-old that I’d put in a box was able to come out and read along. I got my wish–kill those responsible with my own two (borrowed) hands. What happens then? The human cost to the protaganists is horrifying, along with the effects on those close to the murdered. Yes, vengeance is physically possible, but at the end what has been achieved? I felt those long-ago emotions again and was able to let them go.

In the months since reading Vengeance, I’ve noticed that I am able to read about and think about Middle Eastern politics without the same surges of rage that I used to experience. I can see that both sides have unmet needs. I can see that many of their actions will not lead to those needs being met. At the same time I can have compassion for those making those decisions. If I was filled with rage for 38 years for something that happened five thousand miles away, how much more difficult must it be to move past personal experiences of terror, grief, and rage?

I’m sadder and wiser (I hope) in my view of sports now. Sport can’t solve problems, but, at its best, it can remind us that we can solve our problems, we can overcome. Shalom. Salam.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Developers dashboard : Mash-up activity streams from Jira, Sonar and Hudson
By exoPlatform, 21 May 2010
We are going to build a space in exo social to follow the development of a software. We are going to take as an example the development of eXo Social. We want to integrate the 3 following things: Our task manager – Jira, our code quality tool – Sonar and our building system – Hudson.

Coding Standards with Sonar, Maven and Intellij IDEA
By Mike Nash, 18 May 2010
One of the ways to ensure quality in a software project is to find a set of coding standards that your team can agree on then put automated checks in place to ensure they are adhered to. In this post I’d like to take a very small example of such a stanard, and show how you can use several different tools to help ensure and measure compliance.

Sonar Cobol Plugin released
By SonarSource, 17 May 2010
We are happy to announce the release of the Sonar Cobol Plugin. SonarSource has developed its own state of the art Cobol parser and packaged it as a Sonar Plugin. It allows to perform objective and automated Cobol code reviews against pre-defined or homemade coding best practices.

Passing Hudson BUILD_NUMBER to Sonar Plugin
By arensa, 17 May 2010
Sonar is a great source code analysis tool that integrates through its plugin neatly into the Hudson continuous integration server. One major feature of Sonar is the module called “Time machine” where you can review the progress of the quality metrics for your project over time.

Obeo et SonarSource annoncent la sortie du plugin Sonar1.0 pour VisualBasic 6
By Programmez!, 12 May 2010
Les deux sociétés ont décidé de combiner leur savoir-faire afin de fournir une solution permettant d’analyser automatiquement la qualité du code d’applications VisualBasic 6.

The perfect agile test management tool
By Gojko Adzic, 4 May 2010
David Evans and I facilitated a session on designing a killer agile test management tool last week at the UK Test Management Forum, with the goal of learning what are the biggest currently unsolved problems for agile teams in the area of testing at the moment. So for any tool vendors our there, here are the ideas.

First build of JTheque with Sonar 2.0
By Baptiste Wicht, 2 May 2010
This week-end I updated the version of Sonar to the new version 2.0 and migrated it from Tomcat 5.5 to Tomcat 6.0. I waited until now for the plugins I use to be compatible.

An IntelliJ IDEA Plugin for Sonar
By Evgeny Mandrikov, 1 May 2010
The Sonar Team is very proud to announce the release of a first version of a Sonar plugin for IntelliJ IDEA. Sonar (http://sonar.codehaus.org) is an open-source Code Quality Management Platform based on many well known analysis tools like Checkstyle, PMD, Findbugs, Cobertura, …

Sonar: Understanding your codebase
By Mark Thomas, 29 March 2010
Large code bases can be difficult to understand, particularly for a new joiner to a team. Reading code is a great way to get the detail, but getting a high-level view can sometimes be hard. There are a range of open source tools that can provide Information about code coverage, design attributes and complexity, but it is often hard…

Java Build Server
By Manuel Küblböck, 23 January 2010
In my last Java project, I set up a build server with Continuous Integration (CI) capability. I am a big fan of Test Driven Development (TDD) and I quite enjoyed Hudson telling us right away when someone checked in code that broke the build. It just gives you so much more confidence in your code and keeps it releasable at all times. In addition, we used Sonar to measure the quality of our code.

Getting Real by 37signals is a must-read for those writing web applications. The book was first published in 2006; and despite the progress and changes in web development since then, this remains an accurate source of inspiration. I’m re-reading it these days, and the following section entitled “Make Opinionated Software” kind-of summaries the state of mind I have when developing theSCRUM:

Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible.

We think that’s bullshit. The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision. Decide what your vision is and run with it.

And remember, if they don’t like your vision there are plenty of other visions out there for people. Don’t go chasing people you’ll never make happy.

A great example is the original wiki design. Ward Cunningham and friends deliberately stripped the wiki of many features that were considered integral to document collaboration in the past. Instead of attributing each change of the document to a certain person, they removed much of the visual representation of ownership. They made the content ego-less and time-less. They decided it wasn’t important who wrote the content or when it was written. And that has made all the difference. This decision fostered a shared sense of community and was a key ingredient in the success of Wikipedia.

Our apps have followed a similar path. They don’t try to be all things to all people. They have an attitude. They seek out customers who are actually partners. They speak to people who share our vision. You’re either on the bus or off the bus.

The goal of theSCRUM is not to be the swiss knife of Agile teams, or to be a challenger to advanced solutions like VersionOne. If I should describe the vision for theSCRUM:

• Reduce the time spent on the tool, focus agile teams on the product they are building, not on the tool they are using,
• Just the necessary level of features: management of product backlogs, sprint backlogs if teams don’t want to use post-its, and product roadmap. That’s all.

The next version is coming soon, with improvements of the current tools… Stay tuned!

Up to version 2.1, Sonar was relying only on external coding rules engines such as Checkstyle, PMD and Findbugs to report violations on Java applications. But since version 2.1, Sonar also provides its own rules engine to work on Java dependencies. This rules engine is based on Squid and three rules are currently available :

Squid provides an easy to use visitor pattern to be able to visit dependencies between methods, fields, classes and packages. This visitor pattern has been used in Sonar 2.0 to calculate Object Oriented metrics like LCOM4, RFC, DIT, NOC, … and has been reused in Sonar 2.1 to implement this new rules engine.

Here is a description of the three new rules :

• Use of deprecated method : Once deprecated, a method should no longer be used as it means that the method might be removed one day; it might also mean its usage is inefficient or does not enable to benefit from certain features. Using a deprecated method is a sort of technical debt that must be repaid earlier rather than later. The rule detects calls to deprecated methods not only inside but also outside the project. It means that you can track usage of deprecated methods on Java API or any other external libraries. Here is an example of violation :
  
• Unused protected method or Unused private method : Protected or private methods that are never used by any classes in the same project are strongly suspected to be dead code. Dead code means unnecessary, inoperative code that should be removed. This helps in maintenance by decreasing the maintained code size, making it easier to understand the program. Protected methods that override a method from a parent class are not considered as dead code as those methods are most often used through polymorphism.

To support those new functionality, a new Open Source library called sonar-check-api has been added in the Sonar toolbox. This library offers a mechanism to describe the rule : title, description, default priority, ISO category… For Checkstyle, PMD and Findbugs, an XML file is used to provide such description but this library allows use of java annotations to embed the description inside the rule. Here is an example of use with the new “Use of deprecated method” rule :

Have fun with those three new rules while waiting for new ones like a rule to define the architecture layering :)

Since many of the readers of this blog weren’t around for some of my earlier writing, I will occasionally mix in popular articles I wrote some time ago. The plus for me is that I don’t have to spend so much time writing. The minus is that I cringe to see the thought errors in my earlier work. I wouldn’t write this way now, but rather than bowlderize my own history I’ll present it as is, binary thinking, exaggeration, and all.

This piece one entitled “One Team”, about the evolution of my thinking about software development teams. It was initially published in July of 2001. It was interesting to me to re-read it in light of Steve Blank’s Customer Development and the Problem Team in Lean Startups.

Stupid Mistake

The biggest error in Extreme Programming Explained is the implicit assumption that you have a technical team serving a single customer.

The lonely customer orbits a team of programmers

I had this picture in my mind because of two experiences. At a mutual fund company I had a customer who had been a customer service representative for seven years, a supervisor and trainer for three years, and then threatened to quit if the crummy old system wasn’t replaced. At a large manufacturing company I had a customer who had run a finance department for years, knew all the ins, outs and exceptions, and was willing to work very hard to keep up with the programmers.

The picture of a single person feeding expectations to a whole team of programmers is seductive. You don’t have to worry so much about disagreement in detail, and political disagreements are even rarer. You don’t have to worry about finding the appropriate expert to answer a question.

Don’t get me wrong. If you can find that one person who knows the whole domain, is willing to make quick decisions and fix them later, can speak to you both concretely and abstractly, and can put up with a room full of nerds you are likely to be successful. First, though, such folks are understandably rare. Second, this picture seems to exclude many people who now dedicate their talents to software development, like analysts, testers, and modelers.

It Gets Worse

The problem is compounded in XP Explained (and subsequent writings and conversations) by referring to the programmers when using the phrase “the team,” as in “the customer speaks to the team with one voice.” This usage always bothered me, but I didn’t know what to do about it.

Cracks Appear

The first inkling I had that “the team” shouldn’t mean just programmers came out of my experiences at Evant Solutions (evant.net). We (I’m a sometime coach and stock holder) have about ten programmers on (what we’ll call for nearly the last time) the team. But the product, a demand chain management tool for retailers, requires specialized knowledge of many different aspects of retailing. No one customer has sufficient knowledge or perspective to guide the programmers in implementing the whole system.

“The customer” consists of six product managers. One (I’ll call him “Jim” because that’s his name) is the uber-product manager, overseeing the competitive vision of the entire product. Working with him are five product managers specializing in aspects of retailing: assortment planning, purchase orders, inventory, and some other stuff I don’t understand even that well (contact Evant for useful details).

Evant chose a three week iteration, curiously beginning on Tuesday (Jim says, “Planning sucks and Monday sucks, why put them together?”) On Tuesday, the product managers present their stories to the programmers for tasking and estimation. Sometimes one product manager dominates the iteration, sometimes the stories are spread around, and sometimes they are shared. Curious. Even curiouser is the frequent appearance of fresh bruises and bandages on the product managers at the iteration planning meeting.

A Team Is Formed

What gives? Jim says,

The short of it is that we hold a pre-planning meeting before each cycle to discuss which use cases we want to attack. Usually, we have a theme/focus to each cycle that is provided by our clients (i.e., incorporating feedback from XYZ Inc. regarding planning) that makes the discussion around which use cases to select somewhat “non-toxic.” Although our process is very collaborative and democratic, my “uber” nature does make it easy to “break the tie” when we have competing requests.1

Regardless of Monday’s disagreements, Tuesday morning the customer team presents their story choices to the development team with one voice. It is as if they agree, at least as far as the programmers can tell.

Stranger in a Strange Land

The second crack in my model of the lone customer orbiting “the team” came during a visit to Japan in April 2001. The Extreme Hour is an exercise invented by Peter Merel to simulate the dialog used to choose scope in an XP project. A group of eight people is split into four developers who draw pictures of a coffee maker, two customers who write stories about a coffee maker, and two testers who verify that the coffeemaker as drawn satisfies the stories.

For ten minutes the customers write stories and the developers estimate how long they will take to draw. Then comes the interesting part. In five minutes the customers have to choose which stories will go into the first release of the coffee maker based on the estimates on the stories and the developers’ estimate of their overall speed.

I say interesting, because the choosing phase always takes too long, at least a minute or two. The customers disagree on the relative priorities of the stories, they argue with the developers over estimates and speed, and they are reluctant to make a final decision until absolutely compelled to do so.

I gave a private XP lecture to a group of 20 programmers from Technologic Arts, the sponsor of my trip. The first phase of the exercise went as expected—they wrote a bunch of stories. The second phase was interesting.

Instead of six or seven minutes to pick the stories for the initial release, each of the teams was done in two minutes. Strange, but after all these were bright folks who had been studying XP for a while.

The next day I gave an all-day lecture to 200 programmers and project managers. My hosts (hi Marika and Yoshi!) insisted we could run the Extreme Hour with the whole group. I was unconvinced, but it was their show, so what the heck.

The attendees were sitting four to a table, four tables across. The easiest way to form the teams was to have every other row turn around. The backward-facing attendees were the customers and the forward-facing attendees were the developers (we skipped the testers for simplicity).

The first ten minutes went better than I expected. We had them work on a tea maker (although my translators told me later they would have preferred coffee since there are two words for tea and they didn’t know which one I meant). Every team wrote plenty of stories (with a little prompting). We were ready for the first release plan.

In a giant room, with 200 people who had never tried the exercise before, giving instructions through simultaneous translators (who were excellent, but still), the entire room, all 25 teams, had their release plan finished in, you guessed it, two minutes.

Westerners hearing this story often comment, “Sure. Japan is a hierarchical society. The senior customer decided and the others followed.” Au contraire, my ethnocentric friend. In the conversations I watched, every customer talked about the same amount. Body language was similar in the whole customer team. Without knowing Japanese I can’t tell for sure, but I’m guessing the four customers simply formed a team faster than I could recognize and got on with working together. Yoshihide Nagase comments,

Japan has many hierarchical styles. Software development in Japan is hierarchical, too. But manufacturing development (such as in Toyota, Sony, Epson and so on) uses small teams. Maybe attendees of your XP seminar here felt like these small teams, not the usual Japanese Software Engineering way.

The Last Straw

My identification of “the team” with “the programmers” finally died when I had the chance to visit a testing conference and a modeling conference in quick succession. In both places the primary question was, “I’d like to try this. Where do I fit into the XP picture?” As long as the XP picture contains a lone customer orbiting a team of programmers, the answer is “nowhere.” I know that many of the skills and attitudes of modelers and testers would be a huge asset on my teams. If they are right, then my XP picture must be wrong.

One Team

What if we redrew the picture to reflect what happens at Evant, and what I observed in Japan?

The new picture reminds me of American football teams. The offensive and defensive teams have different skills, values, and perspectives but they share a single goal, winning the game.

Where do our good testers and modelers fit in? On the Business team. Helping scout, write, slice, dice, and verify are everyone whose lives will be affected by the scope and quality of the released software:

• Analysts
• Representative users
• Testers
• Marketers
• Customer support
• Sales
• Modelers
• Interface designers that watch what real users do and help “pave the paths”
• Business strategists

Their jobs are different than they have been in the past. No longer can any one of these groups grab a phase to themselves, either before development starts or after it finishes.

Looked at from Here

Once I shifted to viewing one team, some problems I had been wrestling with for months came into focus. Martin Fowler reported a team at Thoughtworks where the programmers brought their workload and stress level under control with the Planning Game, but only at the expense of overloading the analysts. Analysts need liberation, too. ThoughtWorks has since been using teams of analysts and QA in its larger XP projects for a year or so now with reasonable success http://martinfowler.com/articles/planningXpIteration.html.

Another problem that came into focus for me was the growth of the customer team on the C3 project, XP’s spawning ground. At first there was only one customer. After a few months another payroll expert joined the team to help prepare test data. A few months later a third payroll expert joined. The One Team picture explains this. As the business sponsors discover how responsive the development team could be they chose to increase their business investment.

Far from being the norm, perhaps the original “one customer/many programmer” picture is weird. A picture with the teams more nearly balanced in size may be more healthy.

But Wait, There’s More

Our happy little family would be complete, if only we didn’t want to get paid. And if we always got along. And probably eleven other impossible things before breakfast.

I spoke at the University of Oregon CS commencement this year. One of my old professors, Andrzej Proskurowksi, heard the XP story and likened the picture above to a two-legged stool. And he’s absolutely right. There are questions that are outside of the scope of the people on the team as we’ve drawn it so far.

• How does the project get started?
• How is investment increased, reduced, or terminated?
• How are disagreements resolved that aren’t handled by business and development?
• How are relative priorities set between this team and all the other projects that need doing?

I would love to have a better name for the team that answers these questions. The only one I can think of threatens to unstopper the bottle into which we have just so laboriously stuffed the Demons Control, Hierarchy, and Certainty. But, my failings as a thinker being what they are, I’ll just have to call this, for the moment, the Management Team.

But I really mean “team”, not “manager” and certainly not “roomful of hens squabbling over too few grains of corn.” To scale XP practices to the next size of organization (up to about 150), the members of the management team must work together to solve problems at the scale of the whole organization, typically by breaking them into bite-sized chunks that can be chewed and swallowed by individual teams.

Being on the management team is no easy ride. XP Management is not there to Make Decisions, and certainly not there to Fix Things. Managers are there primarily to notice when the words and the deeds don’t match, to market and sell the achievements of the teams, and to make sure there aren’t obviously better ways to spend money.

In redrawing the picture, I’m forced to switch metaphors. If I draw three circles, whichever one ends up on top will think it’s in charge. If two are on top, whichever one ends up on the bottom will think it’s being oppressed. Circles just won’t cut it. However, Andrzej’s suggestion has merit:

I like this picture. First, the three legs are equal partners. Without the support of any one team, the stool collapses. Second, it’s an Aalto design, and I’m a big Aalto fan. Third, imagining the stool in use, the three sub-teams have to work together to withstand the pressure from the …, well, from above.

Making the Shift

I’ve been using “the team” to mean the whole team for a week or so now. Old habits die hard, but it’s starting to feel natural. If you want to try it, talk about “the team” to mean customers, programmers, and managers. Talk about the customer team, the development or programming team, and those clueless suits (just kidding, talk about the management team) when you need to discuss narrower concerns. Give it a week and see how it goes.

Some Predictions

Where will it end? I’m reminded of engineering driven startups, where engineers often form 80-90% of the employees. As these firms grow and mature, the proportion of engineers drops to something like 10-15%.

Will we see this as XP teams mature? Will we ever see a customer team of 10 marketers, domain experts, representative users, sales people, analysts, testers, and usability engineers feed stories and acceptance tests to 4 programmers with 3 managers? What would happen if there was such a team?

Roles

The division of the One Team into three sub-teams smells of taylorist division of labor. I can imagine someone reading this and saying, “Oh, I have to decide once and for all whether I’m a manager or a customer.” In practice, people move between the teams, sometimes even iteration-to-iteration. And once the team is clicking, the artificially hard divisions blur, and rightly so.

However, the social contract of work is different between the members of One XP Team. Before you can begin messing with the roles you have to get used to how they are different. Then you can begin experimenting while working together towards the ultimate goal: getting as much of the most valuable stuff done as possible by a given date.

Sidebar: Customer Team at Thoughtworks

Martin Fowler writes:

At ThoughtWorks the notion of “one team” makes a lot of sense. We often staff projects with our own analysts, who are often business experts. Indeed in some business sectors our analysts are more familiar with the specialized domain than our clients. QA is also obviously an agent of the customer, as indeed it was in the early days at C3.

Our largest XP-ish project has a full team of analysts and a full QA team—all as part of the overall project team. The analysts need to collaborate to present the stories with one voice to the programmers. They’re also a mixed bunch combining both business experts with pure analysts.

They’ve recently set out some of their conclusions about making the customer team work.

• They’ve missed having some kind of “big picture” to act as a road map
• They’ve found it hard to divide up functionality into suitable story-sized chunks
• They’ve found it frustrating to not give an indication to developers of which direction future function is likely to go
• They’ve found that specialized analysts are better at looking at the thorny details of exceptional cases – in other projects testers have reported a similar phenomenon.

The danger with an analyst group is always that they can end up being a communication barrier rather than a communication enabler. The notion of the single business expert customer helps prevent that, but I don’t think there’s any way to structurally avoid a barrier. The key lies in the attitude of the people involved. Particularly on the customer side of the team you have to build the roles around the people – not the other way around.

Certainly the programmer-centric attitude of XP has caused frustration. Part of XP’s guiding mission is to heal the rift between business and technology. For this to work we need to better understand the various aspects of the customer team. In many ways it’s a more complex team than the developer team. It’s also one where the techniques are less developed.

1 Jim Bahrenburg, personal communication, 22 June 2001.

As usual this new release includes numerous improvements, bug-fixes and also brand new features that we believe are worth stopping your daily work for a few minutes to review. Those features can be divided into two categories :

• Libraries cartography : what project is using which library and how ?
• Powerful Squid rules to detect dead methods and calls to deprecated methods

Libraries cartography

Starting from use cases is the best way to explain how useful those new features are and how Sonar can now easily help you to solve your problem.

Imagine that you want to eradicate the use of Commons Logging library from your projects (because it’s evil). Simply go to the new “Dependencies” page, search for “commons logging”, optionally select a version of the library and quickly see which applications need to be refactored :

Let’s say that you now want to know which transitive dependency can explain why your application depends on Fusesource Commons-Management library. Simply go to the new “Libraries” page on your application and start typing fuseso… :

For more details, you can read the user guide.

New Squid rules for Java

Squid, the home made parser embarked within Sonar, has a pretty unique capability in the fact that it works not only on source code but also on byte-code. So far Squid was only used to compute metrics like LCOM4, RFC, complexity, …. From Sonar 2.1, we have created a rule engine on top of Squid. Three rules are already available :

• detect unused private and protected methods as they are dead code. Dead code means unnecessary, inoperative code that should be removed. This helps in maintenance by decreasing the maintained code size, making it easier to understand the program.
• detect calls to deprecated methods. Once deprecated, a method should no longer be used as it means that the method might be removed sooner or later. Squid analyzes both application, java API and external libraries bytecode to determine which methods / classes / fields are deprecated.

System info

The new page “System Info” provides detailed information about system properties, sonar configuration, installed plugins, Java VM memory statistics and database statistics. As the Sonar ecosystem is growing, there is a real need to provide such administration tools . In the upcoming Sonar versions, a new page should allow to dynamically install, uninstall, upgrade plugins and thereby imitate its older brother Hudson CI engine.

Better usability of drilldown pages

Small but useful UI improvement : when navigating through the drilldown pages, the columns are now automatically scrolled to the selected items, so they are always displayed. This little UI improvement was loudly requested by the Sonar community :)

To find out more about Sonar 2.1 and the 50 issues that have been fixed, you can read the release notes or maybe you prefer to download it to give a ride. Have fun !

Hi everybody!

The iceScrum development team is glad to announce the immediate availability of iceScrum R2#15.1 version.
Get it now in the download section!

Changes overview

This is a minor release that includes some new stories and fixes defects discovered in the previous release. Get the complete list of changes in the release notes (in english or in french).

Release Plan and Sprint report PDF generation

In the previous version, there was an action to print the Release Plan, but it was very simple and it was difficult to get something workable when one wanted to get everything (sprints, all stories) at one time. Now, we’ve added a new feature to generate a PDF of the complete Release Plan. An icon has been added in the toolbar, and has replaced the old « Printer » icon.

The new icon in the toolbar

The resulting document lists every sprint of the release with their associated stories. It looks like the Release Plan view in iceScrum.

An exemple of the generated (pdf) release plan

We also added a new generated document in the Sprint Backlog: the Sprint report. This feature will generate a document containing a textual report including all the stories planned in the Sprint Backlog with all their functional test details.

An example of generated (pdf) sprint report

A short overview of bug fixes and other minor evolutions

• The annoying bug affecting the product backlog has been fixed (a new story wouldn’t show up in the backlog unless the user close it and reopen it).
• The Fibonacci suite is now using the real suite (and not the one used by some planning poker cards) and stops at 34.
• It is now possible to create, edit, and delete stories from the table view mode of the product backlog.
• And more… (check the release notes).

We hope that you’ll appreciate this new version. Try it!
On our side, we are working for offering you the best services for your agile projets; you can already take a look on the first ones: http://www.icescrum.com.

Cheers,

The iceScrum team.

The Sonar Team is very proud to announce the release of the first version of the Sonar IntelliJ IDEA plugin. The Sonar IDE project consists at the moment of two plugins, one for Eclipse and one for IntelliJ IDEA, and has 2 active contributors : Jérémie and myself. This release is going to be followed by new ones in the upcoming weeks/months.

The main objective of the Sonar IDE project is to bring the power of the Sonar platform inside the developer’s IDE. In the initial versions of both plugins, the source code will be decorated on the fly with information provided by the Sonar web server. It means that the footprint of the plugins are very light and the continuous workflow of the developer is not disturbed. Note that source code from Sonar server may be slightly different from source code of the working copy, this is why a heuristic algorithm is used to match violations lines.

Version 0.1 has the following limitations : it only works on Maven projects (feel free to vote for issue SONARIDE-38 if you wish support for non-Maven projects to be added) and only displays violations. Duplicated blocks, code coverage and commented out lines of code will be added later.

As usual for releases, let’s go through screenshots to discover this new functionality and how it can be used in your daily work to track violations. Enjoy !

Configuration

This step is straightforward : once a Maven project has been opened, the URL of the Sonar server and optionally username and password must be defined :

Source code decoration

Then you just have to open the java file you want to work on and violations are displayed with markers (on the left-hand side) :

Global source code Inspection

In order to start hunting violations on the overall project, you can use the IDEA inspection toolset with a separate inspection profile for Sonar (All violations are currently associated to a single priority – warning, see SONARIDE-31) :

Go to Sonar

At any time you can jump into the Sonar Web dashboard directly from the IDE to get more information not yet available in the Sonar IntelliJ IDEA plugin :

Roadmap

Next version 0.2 will allow to visualize duplicated blocks, code coverage, … directly inside IDEA, so stay tuned.

To give it a try, you can download it or more simply install it using IntelliJ IDEA Plugin Manager. For more information you can visit Sonar IDE site.

Once again I’ve managed to stir up unexpected trouble on Twitter. Twitter for me is just an inflammatory blog post waiting to happen, I just don’t know which tweet is going to set off the storm.

Here’s what happened this time. I read Michael S. Malone’s piece berating the tech press for covering Apple softly. Until I read this, I wasn’t too upset about iPhoneGate, but Mike’s article framed the situation differently for me: as a free speech issue.

Since my point seemed to be widely misunderstood on Twitter, I will say right up front that I am not commenting on the behavior of Gizmodo or the gentleman who found the phone and subsequently sold it. I would like to think that in the same situation I would return the phone to Apple, although I would certainly be tempted to post some pictures just because I think Apple’s paranoia deserves tweaking whenever possible. Not returning the phone to its (obviously) rightful owner was wrong, but it’s an everyday kind of wrong and it doesn’t affect my life so I’m not going to get too upset about it.

What bothers me is Apple’s reaction. Without knowing the details of the activities that went on, from up here in southern Oregon it looks like Apple enlisted the police to make an example of Gizmodo. If I had lost a hardware prototype and I called the San Mateo police or the REACT group or the Superior Court judge, there’s no way they would have reacted in the way they did. Apple got special treatment because they are large. That’s wrong.

I’ve learned to look for the intent behind behavior that I don’t understand. What could Apple’s intent have been in having Mr. Chen’s house searched in the manner it was? The explanation that makes sense to me is that they wanted to intimidate anyone who was thinking about writing about Apple “secrets”. The course of justice doesn’t demand what they caused to happen. They were looking for effect, is how I read it.

Here’s where it starts to affect my life–what if I figure out something about Apple next “big thing”, purely legitimately? Am I going to write about it? Well, if it’s me I probably will because 1) I’m clueless about what’s going to upset people (obviously) and 2) I hate people telling me what to do. I’d certainly think about it, though. What if Apple took umbrage at what I wrote? Josephine County sheriffs would be battering down my door in no time, and there’s nothing I could do about it. I don’t like that feeling.

My conclusion is that Apple has read too many of its own press releases and thinks the world should run for its benefit. I expect more boorish behavior and increasing alienation from the needs of customers and developers. That’s too bad, because I like my Apple products.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Practical Maven tips – Part 1
By Mike van Vendeloo, 27 Apr 2010
Since I have used Maven a lot over the years, I know my way around Maven. However I encounter a lot of people in projects that just know a few commands (mvn clean install) by head and do not know how maven works or how to add and use functionality within Maven.

An introduction to Sonar
By Freddy Mallet and Olivier Gaudin, 23 April 2010
Sonar is an open source Platform used by development teams to manage source code quality. Sonar has been developed with a main objective in mind: make code quality management accessible to everyone with minimal effort.

The Sonar page in Wikipedia
By Mercer Traieste, 21 April 2010
Sonar has now got a page in Wikipedia, thanks to Mercer.

Code Analysis Tools and Tips
By Darryl Parks,
This talk will present a variety of tools that analyze Java source code. It will begin with an introduction and statistics related to manual code analysis (code reviews). Next, it will introduce automated code analysis and show basic setup and examples of…

Compare between RSM and Sonar
By Rajesh Kumar, 16 April 2010

Analíza la calidad de tu código Java con Sonar 2.0
By Jota, 6 April 2010
Sonar es un proyecto OpenSource de codehaus.org para analizar la calidad tu código en Java con diferentes tipos de métricas, solo funciona con proyectos construidos con Maven2.

Tool to compute Technical Debt as a Percentage and a Dollar amount
On Yahoo Groups, March 2010