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.

Software intelligence has been defined as »offering software practitioners information to support their decision-making«. When researching software intelligence, I came across the CIA approach for gathering foreign intelligence and found that it has many commonalities with my understanding of software intelligence. Hence, I present CIA’s approach and what we can learn from it for gathering software intelligence in this blog post. Furthermore, I present a practice example of software intelligence.

Java 8 has brought us a bunch of new language features, among which are Lambda

Expressions and the Stream API. The intention of these features is to provide

us with a way of expressing frequently used functionality in a cleaner and more

concise way. While there are certainly many situations in which these features

excel, their usage does not necessarily guarantee that the code is cleaner and

easier to read compared to writing it the »old-style way«.

One such questionable situation came up during one of our

quality-control

projects with one of our customers. Once a month we meet with the developers to

discuss the recent improvements and setbacks in the quality of their code. Being

generally up to speed with Java and its features, it came at no…

C/C++ programs often use conditional compilation to implement variations of a program. While conditional compilation is extremely flexible and easy to use, it leads to code that is hard to maintain. Using examples from open-source systems, this post demonstrates why such code is often referred to as the »#ifdef Hell« and what can be done to keep conditional compilation in check.

As we all know, programmers spend a lot of their time reading code. The paper Concise and Consistent Naming shows that approximately 70% of a system’s source code is identifiers, i.e. names of procedures, methods, variables, constants, and so on. The paper concludes that identifiers should be chosen with care. In this post, I approach the topic of identifiers from a more technical perspective, and illustrate some basic things both programmers and tool vendors can easily stumble upon.

From the code audits and quality control of ABAP projects we do, we observe again and again that ABAP code tends to contain a relative high rate of duplication within the custom code. The data of our benchmark confirm this impression: From the ten projects with the highest rate of duplicated code, six projects are written in ABAP (but only 16% of all projects in the benchmark are ABAP projects). In this post I will discuss what are the reasons for the tendency to clones in ABAP.

Often, time pressure forces you to quickly write dirty code. You do not choose the most elegant solution. But at least the change is done and it works. You can always clean it up next time, right? Let me tell you: No, you won’t.

Why is that? Because the probability that you will change the code again is actually rather small. (Needless to say, next time you also will not have much more time at hand.) With our tool »Teamscale«, we studied how software systems evolve and how developers change their code. In particular, we examined how often a Java method is changed during its history. It turns out that most methods are only changed about two to three times on average. Two or three times? In a history of three, four, five, even up to 15 years? You might…

While there is no precise, commonly agreed-on definition of what

constitutes a software architecture, it is understood that a software

system’s architecture is defined by its decomposition into building

blocks and their inter-dependencies. For each pair of components, the

architecture defines if and in what way the two components interact

which each other. An architecture conformance analysis evaluates how

well the implemented architecture matches the specified

architecture. Identifying architecture violations using the

conformance analysis is a required step for the maintainability of the

code base. The release 1.5 of our tool Teamscale adds features that

allow the conformance analysis to be better integrated in the

development cycle of a…

At CQSE we perform peer reviews for almost every line of code that we write to achieve high-end quality control.

With the experience we gained (and still gain!) we also help customers to establish review processes or review portions of their code.

Besides questions regarding process and tooling there is one question that we get regularly asked:

»Is there a list of rules that you apply for reviewing code?«

The answer is always »No«—and this is not because we want to keep such knowledge secret.

With this blog post I will try to explain why such an exhaustive checklist simply does not exist.