Most IT people know Thoughtworks and its charismatic technical leader / evangelist Martin Fowler. But probably fewer know the Thoughtworks Technology Radar whose first publication was done in January 2010.

According to their authors :

The ThoughtWorks Technology Advisory Board is a group of senior technology leaders within ThoughtWorks. They produce the ThoughtWorks Technology Radar to help decision makers understand emerging technologies and trends that affect the market today. This group meets regularly to discuss the global technology strategy for ThoughtWorks and the technology trends that significantly impact our industry.

In its last publication (July 2011), Sonar platform made its first appearance in the “Assess” circle : “Worth exploring with the goal of understanding how it will affect your enterprise”

Read the rest of this page »

One of the main objective for Sonar in 2011 is to go a step further in the support of Continuous Inspection. Indeed, prior to version 2.5, Sonar could already take a snapshot of the overall quality of an application and view the evolution of quality measures across snapshots with the TimeMachine service. But this was not sufficient to provide at quick answers to some very valuable questions such as :

• what changed in my application over last 30 days ?
• did quality improve during version 2.7 software increment ?
• which violations have been created since 1st of January and by who ?
• how much is new code covered by unit tests ?
• which projects have increased their technical debt during last 3 months ?
• …

Read the rest of this page »

You probably remember that 4 months ago, we announced the availability of a SQALE plugin for Sonar. Since them, we have continued to work on it and have released a version 1.2. The new version greatly improves the usability of the plugin and makes it even easier for a non-technical manager to understand and manage the technical debt of his portfolio of projects.

Read the rest of this page »

After an initial attempt that ended up posting on what was accomplished last year, time has now come to discuss the plans for Sonar in 2011 and the associated roadmap !

In 2010, Sonar has progressively become a “must have in software factories” as are already Jenkins, Jira, Nexus or Subversion for instance. With Sonar, a quality platform can now be considered as a commodity which can be installed and used by everybody with only little investment whether it is time or money. We will still focus our effort in 2011 to increase the value of the platform and make teams capable of continuously assessing and reimbursing their technical debt even easily than today.

Read the rest of this page »

Six months ago, we would never have believed that one day we would be happy and excited to write about the implementation of a Quality Model in Sonar. Indeed the Quality Models that we knew at the time (most of them are based on ISO 9126 standard) are complex, expensive to implement, can be understood only by an elite of quality experts and are not fun at all. Displaying a global rating on an application is easy but insuring that this rating can be understood in less than 5 minutes by every stakeholder is much more difficult. Implementing one of those Quality Models in Sonar was a kind of non-sense, even if this feature was highly requested by big companies. Indeed they were in contradiction with the vision behind Sonar :

Managing the source code quality should be simple, should be cheap, should be accessible by all stakeholders (developer, architect, project manager, top manager, …), should be valuable and should be fun (without pleasure, perfection cannot be reached) !

Read the rest of this page »

Prior to Sonar 2.2, the home page was simply the list of projects under quality control. Beyond the fact that it did not add much value to the platform, it was unreadable with more than 100 projects and could not even load with more than 800 projects ! This is why we switched the default Sonar home page from an “All Projects” service to a “Filters” service in Sonar 2.2.

Read the rest of this page »

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.

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 :

Read the rest of this page »

When learning Object-oriented programming, two of the concepts are fairly difficult to understand and therefore to digest : classes must be loosely coupled and highly cohesive. In today’s post, I am going to explain why this is important and how Sonar can help you evaluating how cohesive are your classes.

A few weeks ago, I started a discussion on how to Fight Back Design Erosion by Breaking Cycles with Sonar in which I mentioned that good design should enable to replace any part of a system by a new piece of code with little pain. The first aspect to look at is really the “macro level”, i.e. packages, to ensure for instance that there are no cycles between packages. But to obtain modularity at any level of the design you also need to consider the “micro level”, i.e. the classes / methods, by keeping it loosely coupled and highly cohesive.

Read the rest of this page »

With version 2.0, Sonar now embarks the seventh and last axis of source code quality : Design & Architecture. The objective of this post is to start discussing what it can be used for and why it is so important.
To know if the design of your software is in a good shape, having a sense of observation and a good memory can most of the time do the trick. No real need to use a tool (whether it is UML diagrams, Sonar…) or to look at source code. If month after month, your software is able to evolve as quickly as the business requires and can handle the changes at a constant cost throughout time, then you can confidently conclude that the design of your application is in a good shape (and believe me, it is fairly unusual in the software development market !). If not, you should focus some attention on design as it is not going to get better over time and will become costly in the medium to long term.
To handle fearlessly upcoming changes, it is key that the software design has great modularity. That is to say, you can replace part of the system by a new piece of code with little pain. Reaching true modularity can only be achieved in a programming environment that has two main capabilities (two dimensions) : ability to assemble pieces of software and ability to recursively split a piece of software. However, these capabilities are necessary but not sufficient.

Read the rest of this page »