Sonar in Thoughtworks Technology Radar

by freddy mallet|

    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"

    Of course, SonarSource team was very proud of this but this is not the point here. Indeed, Sonar is a platform to manage quality among other platforms that have been around for a while : CAST Software, McCabe, Klocwork... So why adding now a QA tool to the radar and why choosing Sonar ? Is this because of its growing open source community : 5,000 downloads and 1,000 emails by month ? For its multi-technology capability in Java, C#, COBOL, PHP, PL/SQL, ABAP... ? Is it for is governance extensions: SQALE or Portfolio Management? Maybe, but I am pretty sure that an additional reason has led Thoughtworks experts to make this choice.

    From inception, Sonar was not developed as "just yet an other quality reporting tool" but as a mean to continuously manage and fight back technical debt. This might sound like a subtle semantic difference but this actually makes a big difference. SonarSource team has grown with Agile methodologies and with those methodologies, source code is always very much in the center of focus: it should be able to mutate constantly over time to embrace changes. This key capability to do refactoring at any point in time is so important that the Technical Debt metaphor was early introduced by Agile practitioners.

    After 4 years of development and 38 releases of Sonar we, at SonarSource, deeply know what "Change" means! In such evolving context, processes, planing, documentation, specifications, ... they all matter but what's about source code ? Some would like to consider source code as a black box without too much value whose development can be easily outsourced. With such an approach, the goal of a quality platform is just to report from time to time how well a blak box comply to some pre-defined quality standards. We do think this is a mistake !

    Source code should be considered as a white box that each stakeholder (developer, project manager, IT director, quality consultant, customer, ...) can look at any point of time to understand what happens, to initiate discussions and to make decisions. What ever is the quality of your processes, documentation or specifications, bad code will always lead to failure. Therefore when bad code is injected, it should be immediately detected, fought back and analysed to understand why this crappy code has been injected. Waiting several months to detect technical debt is a huge waste as per Lean principles.

    Adopting Sonar means much more than simply installing a tool to comply to some QA or security standards ... it means that quality of source code really matters and that the ability to daily manage your Technical Debt is key to sustain a continuous delivery approach and to embrace business changes: Continuous Inspection has entered the game !