The term technical debt is often used to explain the nature of

software quality and quality decay: the option to decide for reduced

quality (taking debt) in exchange for more features or faster

time-to-market, the fact that some quality issues will hit you hard

later on (interest), or the problem that accumulation of too many

quality issues might make further development of a software system

impossible (just as too much debt might break a company). Still, we

try to avoid the actual term technical debt, both in our own tools and

when dealing with our customers. Our main reason is that the metaphor

is often overdone and its users tend to see too many parallels to its

financial counterpart.

In a recent software quality audit, our static analysis tool Teamscale found that the comment completeness was nearly perfect, but our manual inspection found that the majority of them was generated automatically and therefore of limited use.

This blog post sketches software quality tasks which should be performed by software tools, software quality tasks which should be performed by human experts and software quality tasks which should be performed jointly.

One side-effect that I have observed from performing code reviews for years is that the code after review is mostly way shorter then it was before.

Reducing the size of code will increase maintainability as we have less code to read and comprehend in the future.

This stresses one of the primary goals of code reviews: Producing clean and concise code that is easy to understand.

In this post, I show which are the steps to configure Teamscale for

such an assessment.

This is illustrated using three open-source projects,

FindBugs, Google Error Prone and

Microsoft StyleCop.

First, I use the Teamscale architecture editor and specify for which

third-party libraries monitoring dependencies might be desired.

Then, the architecture perspective shows the static analysis results

and allows quick inspection of dependencies to third-party libraries.

Analysis tools for your source code, like Teamscale and others, produce a list of findings—or issues—identified in your code. When you go over the list of findings, you will probably encounter some individual findings you will not fully agree with. These issues might be not valid, not a problem or not worth to fix for you. For these cases, professional quality analysis tools offer blacklisting features. Blacklisting allows you to hide individual findings. The question »What should be put on the blacklist?« will be answered quite differently, depending who you ask. Developers may tend to »everything I cannot fix should be on the blacklist«. A QA manager might answer something like »only false positives may be put on the blacklist«.

The Software Maintainability Index (MI) is a single-value indicator for the maintainability of a software system.

It was proposed by Oman and Hagemeister in the early nineties.

The Maintainability Index is computed by combining four traditional metrics: It is a weighted composition of the average Halstead Volume per module, the Cyclomatic Complexity, the number of lines of code (LOC) and the comment ratio of the system.

Anyone writing code knows that famous sentence: »I’ll clean that up later«.

We have all heard it. We have all uttered it.

And, as my colleague Daniela already remarked: No you won’t!

Most likely, you’ll forget about that long method you wanted to shorten later. Or that clone you think can be removed. Or that null pointer finding you’re sure to run into once your code

goes into production. But there’s no time right now! So you leave it as is and turn to more pressing matters. And the quality problems stay—forgotten.

It is a challenge to keep track of these issues is a challenge. You want them to be visible to your entire team—they’ll just gather dust in your own personal ToDo list. But you don’t want to

clutter your team’s issue tracker with every…

Have you ever run into a »new« or »trending« programming language (Rust, nim, Kotlin, etc.), promoting all sorts of great »new« abstraction mechanisms (traits, mixins, multiple-inheritance, monads, lambdas, macros, you name it), thinking: »I could finally get rid of all this copy-pasted or boilerplate code we have in our codebase!«?

I discussed whether newer/trendier languages will lead to less copy-pasted code (or even better code quality in general) with a few colleagues over a few beers recently. Based on our experience as consultants for software quality and Teamscale developers, we quickly came to the conclusion: No, they will not.

Let me explain and give a few examples.

Teams, not individuals, build most software systems. The organization of these teams thus strongly impacts the software they build.

This is old news. For example, Conway’s law illustrates that the architectural decomposition of a system into components happens along communication structures [1]. Naggapan’s study on bug data from Windows Vista shows that organizational structure is a significant predictor for fault proneness [2].

These empirical results resonate with my own experience. Often, the problems our static code analyses reveal in a code base are symptoms of underlying organizational problems. The larger the organizational problems, the bigger their impact on code quality.

Unfortunately, on this level of abstraction, this insight is pretty…

These days, it seems that a modern programming language is required to not use semicolons at all, or at least make them optional. While this might be a good trend from the perspective of a keyboard vendor (less stress on the single semicolon key), from a code quality perspective, this does not look like progress at all.