Asking people what they do to improve the quality of their software product, one of the most frequent answers is something like »Oh, we have installed [Checkstyle|FindBugs|ConQAT|Sonar|…] and it runs as part of our continuous integration process«. However, when looking for indications of any quality improvements, we are mostly unable to find any. The reason is simple:

Tools do not improve quality.

There seems to be the widespread misconception that just running a particular tool improves the quality of a software product. But in the end, tools can only measure specific properties of the product. If we feed them a certain amount of context information they may be able to perform some basic assessment as well. But what they cannot do—for sure—is to improve the quality. Disappointing as it may me, this still requires human intervention.

It’s us, developers and maintainers that can improve the quality of our software product. Needless to say that tools play an important part in the improvement process. They help us to identify the parts of our system that require our attention and they can provide hints to what a good solution to a particular problem would be. But deciding which option is truly the best is still left to us. We’ll never be able to feed our tools all the context information that is needed to make this decision.

Acknowledging that tools have only a supporting role also influences the decision which tools to chose. We observe that the selection of tools is often driven by their popularity or ease of access. The better way would be to first decide which quality improvement is desired and after that select the tools that can provide the required information. To achieve an actual quality improvement, it is us who have to regularly take action and not a continuously running tool.