How (Not) To Control Quality
Every developer knows the feeling when you look at code and stunningly asks yourself:
"Who the hell wrote this code?"
Or when you are getting desperate because you wonder:
"Yesterday it still worked, didn't it"?
It is a common phenomenon in software engineering that lots of code is written under time pressure and, hence, turns into quick 'n' dirty written and badly tested code. Code that is very hard to understand and to maintain. In this article, we outline you how to get in control of deteriorating quality and what helps to actually improve (as well was what does not).
Why Many Fail To Improve
At some point, many companies realize when gradually decreasing quality becomes an issue. In an attempt to prevent this decay, they install common static analysis tools - tools, which reveal, for example, bad code smells or measure test coverage. Alas, this is not enough. It is like signing up for the nearest gym and never going there to exercise. Static analyses are very useful to reveal problems in your code. Nevertheless, it is challenging to apply them successfully and to actually improve.
For long-lived software, static analysis tools commonly reveal thousands of problems [1]. With respect to code quality, these comprise, for example, badly structured pieces of code or redundant implementations. With respect to test quality, these might be files with very little test coverage. Often, developers look at these findings once or twice, try to fix a few and, ultimately, give up. The number of problems in grown software systems is usually too large to be fixed at once because quality assurance budget is almost always limited. (Dedicated large clean-up sessions would not be a good idea anyway because introducing more bugs is far too likely.)
Many existing static analysis tools operate in batch mode, i.e. they often only run once during a (nightly) build. When a developer performs a change, they do not provide feedback till the next build which often takes quite a while. This feedback cycle is simply too long. Who wants to go back to a previous task that seemed already finished? In addition, many existing analysis tools provide feedback only on the entire system. However, developers need personal feedback. In the moment, they care only about the code they actually changed themselves. Often, instead, they are flooded with all findings from the system and has no easy means to filter the ones relevant to them.
Improving software quality requires more than just measuring some metrics. It requires software intelligence.
Further Reading:
Daniela Steidl & Sebastian Eder, In: Proceedings of the 22nd International Conference on Program Comprehension (ICPC). 2014