This post starts our blog, which is designed for sharing our experience with quality in C# and Java development projects. This experience comes from members of our R&D team and from what we have accumulated each day on our Cockpit platform from the millions of lines of code that have been analyzed in our customers’ projects.
We created Cockpit after having found that no tool controlled Java or C# development quality as simply and pragmatically as we wanted. The is a huge potential for improvement in the field of development technical quality. Generally speaking, there are two major categories of tools on the market:
- Analysis agents, often OpenSource for Java environments, that typically specialize in a certain type of detection (metrics, style, bad practices, duplicated code, etc.) for a particular language.
- Products, almost always commercial products, that combine the different measurement types and handle several languages in very different ways (object, procedural, query languages, etc.).
The first are directed mainly at technical profiles: developers, architects, technical project managers, etc. Their implementation may or may not be complex, but the effort tends to include the following steps: setting the rules and thresholds, integration into an automated process, training and raising awareness among development, definition and monitoring of an improvement plan for correcting problems, configuration maintenance, and updates to the tool. I will go into detail on all of these in a future post.
As for the commercial products, the two obstacles we have identified and have confirmed with our customers are the cost and complexity of using them. Products of this type usually have a very high licensing cost (well over €10,000), plus the possible installation, configuration, updating, advisement, and support fees. Few projects have the necessary budgets for this. The cost can often be explained by the rich features offers to the user or by how flexibly it can be set up. But these characteristics also make using the product more complex.
In both cases, many implementation attempts have failed for various reasons:
- Developers could not have enough control over the indicators.
- They felt as if they were flooded with alerts.
- The information provided is too technical. It does not provide an understandable view of quality for the project managers and managers who are not involved in the project management.
- Everyone has difficulty measuring the return on investment for this quality process.
In these conditions, monitoring quality seems more like a constraint than an way to help improve the project.
This may seem extreme, but many are surely satisfied with the tools they have adopted and consider them to be effective. Yet it seems common, which is why we came up with a different approach to quality, one that can truly be perceived as positive by everyone involved with the project, not just by a single theoretical gauge:
- Monitoring quality must be simple. This is why we have chosen a SaaS model, where the user installs nothing on their own infrastructure and can start their first analysis within a few hours. This monitoring should be included in the company’s development process (agile, V cycle, continuous integration, etc.).
- Monitoring quality must be pragmatic. Quality requirements must be adapted to the needs and context of the project. Not all projects have the same quality requirements, and overquality is costly. It is better to work toward a realistic objective that the team can achieve, perhaps by refining requirements along the way.
- The various people involved with the project must share the same view of the status of quality. For this, the information should be presented differently depending on the person viewing it, such as a project director or a developer, but it should express the same results. Using an external third-party service also makes it easier to adopt this common view.
- Quality rules should be up to date and adapted to the current status of the application. Development technologies change (languages, frameworks, etc.), and rules should follow suit. Having a statistical database that is updated daily from the analyzed project code seems to us to be a key point in guaranteeing an updated and relevant rule repository.
That introduces our approach. We have been working on our technology for three years. We have been able to validate our approach, validate its use by our customers, and now we can share our results with you. The next few posts will be more concrete, dealing more directly with this feedback.
