In the beginning of the summer we conducted a survey about the management and the control of technical debt. In this article we are going to analyze the results and see how development teams fight source code quality issues.
The two first questions were to learn a bit more about the interviewees : what is the size of the development team? Which technologies are used in their projects? The shops between 6 and 10 people are the most present, with 29%. Close behind are small shops with less than 5 people. Teams between 11 and 100 represent 33%. Finally, 11% of people who answered come from big teams with more than 100 developers.
After this introduction, we are now going into the real stuff. We asked which tools people use to control code quality…
Open Source leads Static Code Analysis discipline
As we can see on the following chart, more than a quarter do not use any tools. The open-source tools are the most used: Sonar (39%), Checkstyle (34%), Findbugs (33%), PMD(29%). Vendor tools, like Cast, Coverity, or Klockwork are used by only 15% of the interviewees. It is true that open-source tools consist in a good first quality layer. They have proven to be useful and to efficiently detect some quality issues. However, a more in-depth control and reduction of technical debt should probably involved vendors tools. They will enable more precise and more evolved analysis.
If you’re a regular reader of our blog, you already know that Scertify enables to leverage these open-source tools by bringing them together to the developer:
- both within IDEs and Continuous Integration environments
- with high-value and advanced in-house rules (hibernate, Owasp, …).
Code Complexity: Technical Debt origins
The next question was about the impact of various code metric on technical debt. Participants had to rate various metrics from 1 (important impact) to 6 (no impact). Code complexity is seen as the main element, with an average rating of 2.44, closely followed by unit tests coverage, with an average of 3.19. This two are tightly related, since it is really difficult to get a good code coverage on highly complex code. Regarding compliance to programming rules, the bigger the team is, the higher its impact is seen as important. We see huge differences in ratings, ranging from 1 to 6. An explanation can be that, for small teams, it is still all-right to be less strict on programming standards. However, for big teams, the need of ensuring consistency across all part of an application is higher.
Next, we asked the participants how they control their developments’ quality. Two thirds of them use controls integrated to their process, whether it is through the build system in continuous integration or directly in the developer’s environment (like Eclipse, NetBeans, Visual Studio…). On the other hand, 19% use external tools. The benefit of integrated solutions, such as Scertify, over external ones are that are much more user-friendly and efficiently leverage developers’ skill with their usual environment. Finally, 5% of the people use manual code reviews to detect quality issues. Such reviews are always valuable for complex part of an application. However, they can often be more efficient if they are used in coordination with automatic analysis.
Shared rule respositoy vs. Project-specific code controls
For those using automatic analysis tools it was interesting to learn how they manage their rules repository. Such repository contains all the programming rules that have to be respected in the companies’ project. We distinguish three kind of management, that correspond to different maturity level. On the first level, we have teams where developers choose individually which rules they want to check with the tools. This is a good starting point, however for big teams it makes it hard to ensure a good consistency of quality across all developments. 25% of the interviewees use this method.
The next step is to use a centralized repository, the same for all applications and all developers. Such centralization is made easy with tools like Scertify. It allows to have the same quality checks for all projects. 26% use this method. However, some projects may require specific rules, so the last step is to use a centralized repository, with customization for specific projects. This is the most mature level and 49% use it.
Developers are looking for architecture & framework rules
Then, we asked people what kind of rules they are lacking in their analysis tools. As we can see, the most in-demand topic is architecture’s quality. 79% of interviewees would like to have rules to check their architecture. Specific Java frameworks, like Hibernate, Spring and Struts, are also quite in-demand, with respectively 48%, 59% and 32%. Finally, 30% of people have security related concerns and would like rules to prevent their applications against OWASP flaws and other security issues (from the Javasec specification).
Half of development teams allocate 11-30% to reduce Technical Debt
To conclude, we asked how much of development time people allocate to the detect and correct quality issues. As we can see, 38% of people allocate 11 to 20% of time, which is often considered as a good practice. There is also a significant amount of people who allocate less than 10%. Finally, it is interesting to notice that 10% of teams spend more than 40% of their time on ensuring good good code quality. To save time and be more efficient on quality control and improvement, teams can leverage powerful features of analysis tools. For example, Scertify enables to get rid of code defect on-the-fly in developer’s workspace as soon as they appear. It also provides automatic refactoring features that can be used to quickly and efficiently get rid of many coding defects.
To sum up, we have seen that code quality is an important concern for many development teams. Though not all teams have the same level of maturity in their management of quality and technical debt, efficient solutions exist to help them in their daily effort to provide better, safer, more robust software.