Resources

Software Quality Blog


We love software quality and publish a blog post every other week to keep you up to date on our newest insights!

RSS

This piece contains some lessons learned about my experience optimizing our git hook performance. The information here is certainly not new but I haven’t found it aggregated and explained in one single place yet.

We recently switched our main code repository from SVN to Git and with that came many challenges and improvements to our software development process. One option that Git offers are so-called hooks. These are small programs or scripts that are run before or after a commit, when pushing to a repository and at other times. They may write to the console during these Git processes (making the output look like it came from Git) and even abort them, e.g. if the user is trying to use Git in a way you don’t want them to.

Directly after the migration to Git, we had several recurring problems that we addressed with these commit hooks. In this post, I’ll summarize a few of the

Read more...


It’s not that normal pressure wouldn’t be enough. Your next release is already delayed. There are numerous bugs that still need to be fixed. Your customers are getting impatient. And here comes your manager, telling you that CQSE will perform a code and architecture audit on your system. You might very well think »What the hell…«. Yes, we know. And believe us, you are not alone. No development team on earth has free time to spend, in particular not on an audit that seems more scary than useful. But the audit sounds worse than it actually is. That’s why this blog post is supposed to take away some of your fears and clarify what is, in fact, ahead of you (and what is not). And believe it or not, you and your team can actually benefit from the audit, too.

Read more...


If you are developing a legacy code base with tests, you might still be stuck with JUnit 3—up until recently, I was in the same boat. However, we decided to take the plunge and migrate to JUnit 4. It was well worth it! If you want to know why and how we did it, read on…

Read more...


Since this post relates to a paper in German, it is written in German, too.

Wir freuen uns, dass unser Paper zur Test-Gap-Analyse auf dem QS-Tag 2016 mit dem Best Paper Award ausgezeichnet wurde. Das Paper ist hier als Download verfügbar.

Read more...


Big software systems which have grown over many years likely contain feature implementations which are not used (anymore). While unused code can be identified by profiling the system in production, unused features are more difficult to identify. This blog post describes three ways of identifying unused features in ABAP systems which we have developed recently.

Read more...


Am 27. Oktober 2016 fand der erste CQSE Software Intelligence Workshop statt. Hauptbestandteil des Workshops waren Vorträge mit Erfahrungsberichten zu Themen wie Test-Gap-Analyse und Quality Control durch unsere Kunden und Kollegen. Wir möchten uns bei den etwa 100 Teilnehmern herzlich für die wertvollen Diskussionsbeiträge bedanken.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Nils Göde
  • Konferenz: XP Days 2016
  • Datum: Montag, 21. November 2016, 12:00 - 12:30 Uhr
  • Ort: Handwerkskammer Hamburg

Read more...


Coordinates

  • Speaker: Elmar Jürgens
  • Venue: GOTO Berlin
  • Date: Tuesday, 15th of November 2016, 15:00 - 15:50 Uhr
  • Location: bcc, Berlin Alexanderplatz

Read more...


Our Journey to Git

Posted on 11/09/2016 by Martin Pöhlmann

2016 marks the year we switched our development repositories from Subversion to Git. As I was responsible for large parts of this migration, I want to share some technical aspects of this journey with focus on the biggest obstacles we had to master: Combining multiple Subversion repositories into one Git repository, shrinking the repository size, dealing with Subversion externals and resulting changes in our development process.

Read more...


CQSE uses Teamscale for code quality control for our customers and our own code. The spectrum of programming languages that we support is large, including C#, ABAP, Java, JavaScript and Matlab.

In this post, I give an overview of establishing a code quality control process for a Matlab codebase, like we did for one of our customers. Some of the code examples are taken from three popular open-source applications listed at the Matlab Central webpage: export_fig, T-MATS and CNN-for-Image-Retrieval.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Elmar Jürgens
  • Konferenz: QS-Tag 2016
  • Datum: Donnerstag, 03. November 2016, 11:35 - 12:20 Uhr
  • Ort: Sheraton Carlton Nürnberg

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

Read more...


In a recent blog post, I wrote about Test Gap analysis—our analysis that identifies changed code that was never tested before a release. Often, these areas—the so called test gaps—are way more error prone than the rest of the system, which is why test managers try to test them most thoroughly.

Test Gap analysis provides test managers with an overview of remaining test gaps during the test phase. In practice, our code quality software Teamscale identifies changed but untested methods in the source code and displays the results on a treemap.

However, in many projects testers are non-coders or do not know the source code,

Read more...


Teamscale computes a number of metrics for each analyzed project (lines of codes, clone coverage, comment completeness, …) and supports uploading further metrics from external systems (e.g. from the build server). The computed metrics are updated with every commit and provide an overview over the state of a software project. As it is sometimes hard to tell what is good and what is bad, the next Teamscale version will be equipped with a new powerful feature that provides an assessment of metric values based on (built-in or custom) threshold configurations. It will help the user interpret the values.

Read more...


A year ago we released the first version of our web-based architecture editor. It was lacking one major feature: saving architectures directly into Teamscale from the browser. This will change with the upcoming release 2.1:

In this post I will outline how to create a new architecture for an existing system, demonstrating the usage and usefulness of real-time architecture analysis.

Read more...


During the last years, we have deeply integrated analyses for ABAP in Teamscale (and formerly in ConQAT). These analyses are used by SAP customers to keep the quality of their custom code high. However, since SAP is introducing many new programming technologies, more and more SAP users are confronted with new languages besides ABAP. One of these is SAP HANA SQLScript, which is used to develop high-performance stored procedures for the SAP HANA in-memory database. Unfortunately, SAP did not provide any static code analysis for SQLScript (in contrast to SAP Code Inspector for ABAP). Moreover, there are no precise guidelines how to develop good SQLScript code so far. In this post I’ll present our initial thoughts on assessing the code quality of SQLScript.

Read more...


Teamscale comes equipped with its own task manager. As most development teams already use an issue tracker (such as Jira or Redmine), a common question is how Teamscale tasks relate to tickets in the issue tracker and whether one should replace the other. Not surprisingly, this is not a simple yes/no answer.

Read more...


A Growing User Base

In the early days of Teamscale when the number of users was still moderate, we used a rather ad hoc way of providing support to our customers. In most cases, support requests were directly handled by the Teamscale product development team. This worked perfectly fine at that time. Customers and evaluators got the most qualified help possible and the development team in turn received unfiltered feedback from Teamscale users.

Fortunately, the user base of Teamscale grew significantly over the past years and, as expected, we were facing an increased number of support requests with a broad variety of topics ranging from general questions regarding installation, configuration, and usage to feature requests and bug reports.

As a consequence, the work load on the product development team grew, occupying resources for further evolution of Teamscale as a product. We felt it was about time to rethink the way we do

Read more...


For me, one of the most appealing quality improvement actions still is the deletion of code. That means, not just any code, but the code that is of no more use. Obviously, this refers to dead code—code that is not reachable at all and will therefore never be executed. This includes unused variables and fields as well as methods that are never called and commented-out code (Teamscale can tell you where these are). However, this is only part of the truth. More importantly, it refers to all the experimental code, the one-time migration code, the code of the previous version, the code of the supplementary tool that no-one used anymore and so on. In most systems we see, this accounts for a notable part of the total code volume. Beyond that, it might be worth looking at all the tiny features you thought were cool, took you a long time to implement, but no-one really uses in practice. Maybe it’s time to let go and remove them (I know this sounds awkward since common sense is that you can only add features). Andreas’ post might help you to get started.

Read more...


When talking to customers about improving the quality of their code, one question that always comes up is where to start. And, as always in the software industry, the answer is »It depends«. We have already covered this topic on this blog in the past (e.g., here, here). This time, I would like to add another dimension to the question, namely the actual usage of code in production.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Dennis Pagano
  • Konferenz: DWX 2016
  • Datum: Montag, 20. Juni 2016, 17:00 - 18:00 Uhr
  • Ort: Nürnberg Convention Center NCC Ost, Raum Oslo

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

Read more...


In our code audits we primarily focus on issues that affect the maintainability of the code, e.g., code duplication caused by copy&paste programming. When presenting the audit results, a common reaction by the development team is: »Yes, you’re right. This is ugly. However, it is not a problem for us because we will never change this code!« My reaction: »Great. Compile the code to a binary library and delete the source.« This always provokes second thoughts. Not only because source code also serves as documentation that would be lost but also because the team suddenly doubts its own assessment of the stability of the code. So far, not a single development team followed my suggestion.

With examples of real-world systems this post discusses the multitude of reasons for code to change and explains why the assumption that code won’t change can be dangerous.

Read more...


Contacting customer support with a technical issue can feel like you are in a quiz show, with the support agent going through a list of standard questions. As you don’t know these questions, providing the information bit by bit can get very tedious.

You: Hello, customer support. The FooBar server is not running as expected. I’m getting errors when updating user information.

Customer Support: Hi, pleased to help you. Which version of the server are you running?

You: Version 17.5.33

Customer Support: Great. Maybe this is a configuration issue. Can you send me the configuration file?

Read more...


Many companies employ sophisticated testing processes, but still bugs find their way into production. Often they hide among the subset of changes that were not tested. Actually, we found that untested changes are five times more error prone than the rest of the system.

To avoid that untested changes go into production, we came up with Test Gap analysis—an automated way of identifying changed code that was never executed before a release. We call these areas test gaps. Knowing them allows test managers to make a conscious decision, which test gaps have to be tested before shipping and which ones are of low risk and can be left untested.

A short while ago, we introduced Test Gap analysis into our code quality software Teamscale. In

Read more...


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.

Read more...


In a recent software quality audit, our static analysis tool Teamscale found that the comment completeness ratio of the application under study was 96%. But when examining these comments manually, we found that the majority of them was generated automatically and therefore of limited use. This example illustrates that a combination of software tool and human expertise is necessary to get a holistic picture of and ensure software quality. To argue for this position in more detail, 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.

Read more...


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.

Read more...


At CQSE, we use Teamscale and static analysis for assessment of technology suitability:

  • Get insights about the relevant third-party libraries used in a codebase.
  • Inspect code patterns corresponding to various third-party libraries.
  • Assess ease of migration away from third-party libraries that are not suitable.
  • Assist with refactoring code and avoid uses of deprecated third-party library.

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.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

Read more...


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«.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Dennis Pagano
  • Konferenz: OOP 2016
  • Datum: Donnerstag, 4. Februar 2016, 11:00 - 11:45 Uhr
  • Ort: ICM - Internationales Congress Center, München, Track 7.2

Read more...


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 [1]. 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.

Read more...


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 single finding either—some might just be too small to even be worth mentioning in your sprint planning session. Your quality engineer might want to have an overview over

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Uwe Proft und Elmar Jürgens
  • Konferenz: SWQD 2016
  • Datum: Dienstag, 19. Januar 2016, 13:45 - 14:30 Uhr
  • Ort: Austria Trend Hotel Savoyen, Wien, Track B

Read more...


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.

Read more...


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 useless, since it is too abstract to be operationalized in a project context. To make it applicable, I want to boil it down to a single aspect in this article: reuse. From my experience, it is one of the code characteristics that reveals most about collaboration between teams.

Read more...


Save the Semicolon

Posted on 12/09/2015 by Dr. Benjamin Hummel

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.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

Read more...


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.

Read more...


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 surprise, that the developers starting using the new features right away. During the latest meeting, one piece of code stimulated a lot of discussion about whether the usage of the new Java 8 features makes the code more readable or not.

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Elmar Jürgens
  • Konferenz: W-JAX 2015
  • Datum: Donnerstag, 5. November 2015, 16:30 - 17:15 Uhr
  • Ort: Sheraton Carlton Nürnberg, Raum Burggrafensaal

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Elmar Jürgens
  • Konferenz: W-JAX 2015
  • Datum: Mittwoch, 4. November 2015, 10:45 - 11:45 Uhr
  • Ort: The Westin Grand München, Raum Barcelona

Read more...


Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

  • Sprecher: Elmar Jürgens
  • Konferenz: W-JAX 2015
  • Datum: Dienstag, 3. November 2015, 18:00 - 19:00 Uhr
  • Ort: The Westin Grand München, Raum Garmisch

Read more...


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.

Read more...


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.

Read more...


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.

Read more...


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 wonder how this can be true.

Read more...


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 project. This article describes the basic concepts needed to understand the editing of architecture and conformance analysis as performed by Teamscale.

Read more...


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.

Read more...


Who doesn’t love metrics? They measure your progress in achieving a goal. They can help you objectively answer important questions. They help you understand complex situations or problems.

However, there are some caveats: it’s easy to pile on a ton of metrics and be drowned in information. Selecting the relevant ones is important. Some metrics may also be hard to interpret when you see merely the raw data. Only with the right visualization will you reap its full benefits and gain an intuitive understanding of your problem.

Read more...


In this post I discuss the history of software quality analysis approaches and tools that focus on ensuring internal quality (maintainability, comprehensibility etc.). I will distinguish different generations of architectures of quality analysis tools and the quality assurance mindset behind them. This categorizations allows of course no clear cut. Furthermore, as managing partner of CQSE as a tool provider my point of view is certainly biased. So please regard this post as a very personal view onto the evolution of software quality analysis methods. Thus, the three generations I distinguish represent our own learning curve as a company (since 2009) and as researchers (since 2005 at TU Munich) in this area.

When we started developing Teamscale I was often asked by customers, former colleagues and friends why we are developing a new software quality analysis tool as several already existed (including our own tool ConQAT or the even more

Read more...


We have had countless discussions about code clones with the teams responsible for their maintenance. These teams generally accept that some of the clones in their software are the product of copy & paste. In many cases this is obvious, since the clones share some quirks that can only be plausibly explained by copy & paste (e.g. identical typos in comments).

One hypothesis that comes up time and again, however, is that some or many of the clones were not created by copy & paste, but instead were written independently and then evolved into the same form.

Convergent Evolution

This hypothesis reminds me of convergent evolution, where environmental factors drive independent evolution of similar traits in species whose ancestors do not show those traits. For example, both pill bugs and pill millipede have evolved similar defenses, and consequently look similar, but belong to different branches of

Read more...


Every software system has been built by copy & paste at least to some degree. Some of this redundancy is caused by technical limitations in the languages and tools. Some is caused by time pressure, where duplicating and modifying an existing piece of code is faster than developing suitable abstractions. Some is also caused by the laziness of the developers or missing awareness of possible long-term consequences. While these duplications often work fine when they are created, they typically cause additional maintenance overhead during software evolution, as duplicates have to be changed consistently. But the real risk of these duplications is in inconsistent changes, as this frequently leads to actual bugs in the system.

Read more...


If you are controlling software quality in a continuous manner, the absolute values of the quality measures at a specific point in time are often not the most important thing. What matters more, is the direction in which you are going. While there may be short-term decreases in quality over time, e.g. due to larger refactorings, the general trend should be towards improvement. An effective way to determine this trend is a Delta Analysis.

A Delta Analysis compares two snapshots of the code base and determines how the changes in the time frame affected the software quality. To do this correctly, a tool has to be able to differentiate between old and new quality deficits (we call them findings). Many existing tools have major limitations in their tracking of findings. For instance, renaming a class or moving a method from one class to another will usually result in all findings being reported as

Read more...


Almost every long-living software system has accumulated an abundance of quality deficits over time. It’s not only impossible to remove all findings, I also do not recommend to do that. You may very well argue to not remove any legacy finding by saying »It has worked all the time« or »It wasn’t me who introduced the problem«. But then—on the other hand—you should make sure that you don’t introduce any new problems. To check this, you need a tool that can reliably differentiate between legacy findings and findings that have been recently introduced. This has to work also if directories of files are renamed, code is moved between files and findings change their appearance in the code. Making the distinction between legacy and recent findings is one of the many strengths of Teamscale.

Read more...


As my colleague Fabian explained a few weeks ago, a combination of change detection and execution logging can substantially increase transparency regarding which recent changes of a software system have actually been covered by the testing process. I will not repeat all the details of the Test Gap Analysis approach here, but instead just summarize the core idea: Untested new or changed code is much more likely to contain bugs than other parts of a software system. Therefore it makes sense to use information about code changes and code execution during testing in order to identify those changed but untested areas.

Several times we heard from customers that they like the idea, but they are not sure about its applicability in their specific project. In the majority of these cases the argument was that the project mainly deals with generated artifacts rather

Read more...


Code quality audits aim to assess the quality of a system’s source code and identify weak points in it. Two areas of the quality audits that have been discussed in the previous posts by my colleagues are the redundancy caused by copy/paste and the anomalies that go undetected unless static analysis tools like FindBugs are used periodically to check the source code for defects. In the following, I will outline a small experiment meant to see whether the findings of the static analysis tool FindBugs reside in code blocks that have been copied over in other parts of a system’s source code. To illustrate this experiment, I will use a »Big Data« open-source project, namely Apache Hadoop. It is worth mentioning that, related to its code quality, Apache Hadoop was in the spotlight of the 2014 Report on open-source software quality from our colleagues at Coverity.

Read more...


Continuous Integration (CI) is one of the dominating terms when talking about software engineering methods with developers. The initial idea behind continuous integration was merging the changes performed on developers’ working copies several times a day, in order to prevent integration problems. By keeping the changes since the last integration small, new integration problems are much easier to analyze and to solve and thus the »integration hell« becomes less scary.

Read more...


When you say »software test«, most people will immediately have a mental picture of automated unit tests, continuous integration, fancy mutation testing tools etc. But in reality a large portion of testing activities is still manual, i.e., someone clicking through the UI, entering values, hitting buttons and comparing on-screen results with an Excel sheet. Such tests are sometimes exploratory (i.e., the tester performs some random actions in the UI and reports any bugs he may or may not encounter on the way) and sometimes they are structured (i.e., someone writes a natural-language document with step-by-step instructions for the tester).

In our long-running research cooperation with TU München and our partner HEJF GbR, we have encountered large regression test suites (i.e., hundreds of test cases) in many different companies that were built this way. Usually some test management tool is used to store these test descriptions and monitor the

Read more...


While there are numerous excellent articles, blog posts and books about the correct handling of character encodings in software systems, many systems still get it wrong because their architects and developers never understood what this is all about. I suspect that is due to the fact that many systems work more or less correctly even if you don’t care about character encodings. Moreover, character encodings in general and Unicode in particular is a topic of overwhelming complexity (if you want to fully understand it). The combination of these two facts—it mostly works even if I don’t care and really understanding the thing is hard—allows laziness to set in; resulting in software systems that handle text correctly under the most trivial circumstances only. This blog post aims to remedy this by focusing on the single most important rule for developers while abstracting away everything that is not required to understand this rule.

Read more...


Most of the posts in this blog focus on measuring and improving the quality of software systems. When talking about software quality most of us think about the quality of its source code. However, with the recent trend to continuously deliver new releases the quality of build scripts and thus maintenance costs are becoming increasingly important. From auditing the build systems of our customers we know that coping with clones in build scripts significantly increases maintenance costs and hampers implementation of new build features. This post summarizes how we compared 3,872 systems to interpret cloning in build scripts and examine how it can be avoided.

Read more...


Nils summarized the benefits of short methods in his post from November: These are easier to comprehend, do better document the code (by the method name), are better to reuse and simplify testing as well as debugging or profiling. As the examples were in Java, one may intend that this will work for modern languages—but not in general, and maybe not for a language like ABAP. In this post I’ll focus if short procedures (e.g., methods, function modules, or form routines) have the same relevance for ABAP or if longer procedures are to legitimate or can not be avoided.

Read more...


In this blog post I will show you how to start with IntelliJ IDEA plugin development. Since there is not a lot of documentation about plugin development for IntelliJ IDEA, I’ll be explaining how to create a simple plugin and execute code after a project was opened using the StartupActivity class.

Read more...


This post is about student internships at CQSE. If you are studying computer science and are looking for a job specifically designed to help you get the most out of your studies, read on.

Read more...


Have you ever used static analysis tools? Then you probably know how they tend to flood you with so many analysis results (findings), that you don’t know where to even start reading and resolving them. Instead of turning these tools off again, read on for some strategies for dealing with the findings flood.

Read more...


As you probably know, you should keep the methods (functions, procedures, …) in your code short and have each of them do only one thing. While hardly anyone opposes this rule, we still find a large number of long methods in the code bases we analyze. I believe this is because many developers are not aware of all the benefits that short methods have. The common argument is that short methods are somehow »easier to understand«. But that seems not convincing enough to keep methods short in practice. In this post I describe the advantages of short methods, which are:

  • Comprehension
  • Documentation
  • Reuse
  • Testing
  • Profiling

Read more...


Almost everybody agrees that having a consistent setup for compiler errors, warnings and the code formatter across all team members is crucial. However, many development projects still fail to achieve this. Surprisingly, the main reason for this seems to be that most developers are not aware that this can be easily enforced with Eclipse and use cumbersome »How to setup your workspace« descriptions in the developer wiki instead. In most cases these descriptions are outdated or generally ignored. As this is an issue that I have repeatedly discussed with our customers (and recently at the BITKOM Workshop in Frankfurt) I explain how enforcing a consistent setup for compiler errors, warnings and the code formatter works with Eclipse.

Read more...


Testing is an integral part of a software product’s life-cycle. Some people prefer executing their tests continuously while they develop, others have a separate testing phase before each release. The goal, however, is always the same: finding bugs. The more, the better.

Unfortunately, the time available for testing and for writing new tests is limited. At some point, you have to get on with development, ship your software and be confident it contains no serious flaws. Often, more tests exist than can be run in the available time span. This is especially true if your tests are executed manually, as is the case for many of our customers. Then the question becomes: which tests do I select to find the most bugs before the release?

Research has shown that untested changes are 5 times more likely (“Did We Test Our Changes?”, Eder et. al., 2013) to

Read more...


One of the services we offer is called TestGap Analysis. It helps you identify changes in your code that have not been covered by your tests since the last release. I have been working on TestGap for the last few months and never had to worry about performance problems. Analyzing a code base of over 30,000 classes took about 15 minutes, which is what you’d expect for a complex analysis. Last week, though, we tried executing it on a new project (> 60,000 classes) and after the analysis had run for 2 hours with no end in sight, we had to face the facts: we had a performance problem.

Read more...


The recent blog post ‘Improving Software Quality’ by my colleague Martin showed how we can improve software quality besides just installing tools: We believe that a continuous quality control process is necessary to have a long-term, measurable impact. However, does this quality control actually have an long-term impact in practice? Or are feature and change requests still receiving more priorities than cleaning up code that was written in a hurry and under time pressure? With our long-term partner Munich Re, we gathered enough data to show in a large-scale industry case study that quality control can improve the code quality even while the system is still under active development. Our results were accepted to be published as a conference paper at the International Conference on Software Maintenance and Evolution (ICSME).

Read more...


Teamscale is our tool for continuous software quality control. It provides feedback about quality problems in real-time, allowing you to keep your software free of technical debt. To give you a better idea, how certain core features of Teamscale work in practice, we created a couple of short video clips that demonstrate Teamscale in action.

Read more...


In the previous part we introduced the notion of code clones and discussed, whether and under which circumstances cloning in your code base can be a problem for development and maintenance. In this post, I will introduce ways and tools to deal with code clones in your code base. After reading this, you should be able to select and apply a detection tool to inspect the clones in your own code base.

Read more...


One well known principle in software engineering states don’t repeat yourself, also known as the DRY principle. A very obvious violation of DRY is the application of copy/paste to create duplicates of large portions of source code within the same code base. These duplicate pieces of code, also known as code clones, have been subject to lots of research in the last two decades. In this two-part post I want to summarize those parts of the current knowledge that I find most relevant to the practitioner, especially the impact of clones on software development and how to deal with them in terms of tools and processes.

Read more...


It is interesting to see the various organizational settings where software development takes place. Having a look at the different kinds of companies we have been working with in the last years reveals the many different settings: Completely internal development, internal development in a mix of internal and external developers, external development with internal project management/architects, completely outsourced development only providing a set of requirements to the supplier. Furthermore, throughout the lifecycle of a system, these settings are often changed: systems are handed over from an external initial development to internal maintenance or vice versa. Thus, a pure and stable development team developing and maintaining a system is rather an exception than the usual case.

Read more...


Teamscale is our tool for continuous software quality control. It provides feedback about quality problems in near real-time, allowing you to keep your software free of technical debt.

Today we are proud to announce our public demo, allowing you to try and explore Teamscale easily.

To get started, go to our Teamscale Demo registration page and register a user for the live demo. You will get an e-mail containing your new password and a login link. Follow the link to login and explore Teamscale.

Read more...


All common programming languages have features that help you to organize and structure your code. A prominent example are methods and functions. Still, these features are often not used to the extent that they should be. For example, it is good practice to keep your methods short and comprehensible with a single clear functionality for each method. I won’t argue whether 3, 10, or 20 lines is the perferct size of a method, but 100 lines and more is definitely not. Nevertheless such long methods frequently occur in most systems.

The interesting observation is that the corresponding developers are almost always aware of the lack of comprehensibility of such long methods. But instead of splitting it into multiple smaller methods, the common solution is to use comments to subdivide the long method into its logical parts.

Read more...


In nearly every audience we present our analysis and quality management tools to, there is at least one person asking whether we also measure Cyclomatic Complexity. After all, almost every existing software quality tool calculates this metric and so it is very well known. Much to their surprise, our answer is usually no and I want to explain our rationale in this post.

Read more...


How many of you know the feeling, when an incoming change request forces you to dig into code you never wanted to dig into? And how many of you have drawn the conclusion while reading the code: »I don’t get what’s going on.« With the immediate follow-up question: »Who the hell has written this code?«

As we all probably have experienced, software systems evolve over time and without effective counter measurements, their quality gradually decays, making it hard to understand and to maintain the system. With this blog post, we provide a useful way to start preventing further decay of a grown software system by cleaning up the code.

Read more...


As quality consultants, we mainly work together with our customers, but we are also actively involved in current research. In this post, we summarize our paper »Incremental Origin Analysis of Source Code Files« that was recently accepted for publication at the MSR—the Working Conference on Mining Software Repositories (from 31.5. to 1.6.14 in Hyderabad, India).

I guess most of you have heard about it—and many of you use it on a daily basis: The version control system.

Read more...


In many domains software is a highly critical part of the products, especially in automotive and avionics systems, in medical equipment, and in military systems—software failures may cause severe damage to machines or even cost human lives. Thus, it is broadly accepted that software quality is the key to developing safe systems. Most people out there have deep trust in the quality of the software controlling the cars they drive, the planes they fly with, and the equipment that is keeping them alive during medical surgery. To be honest, most of this software works really well. However, when looking behind the curtains, I sometimes wonder why.

Safety critical systems need to be certified and thus undergo rigorous qualification processes. There are different kinds of standards, defining quality and safety regulations for different kinds of applications. Having a closer look reveals that most of these standards state that certain kinds of activities must be performed—usually

Read more...


Many consider manual code reviews to be the premium solution to quality control, as they can locate and eliminate all kinds of issues ranging from functional bugs over security deficits to maintainability problems and have many other benefits as a side-effect. When installing code reviews in your development project, there are a couple of flavours to choose from. This post highlights one of these variation points, namely the granularity of the artifact being reviewed.

Read more...


This is the second part of our quality audit of the Android core component’s source code. In my previous post we have looked at the structure of the code. In this post we will analyze the redundancy found in the code. Redundant code fragments—so-called clones— cause a variety of problems. The system is larger than it needs to be, defects are duplicated, changes have to be done multiple times, and individual copies may be overlooked when a bug is fixed (this is not a myth since many clone-related bugs have already been found in production software). Consequently, it is advisable to keep the redundancy as low as possible.

Read more...


On Friday, February 21st Apple published an update for iOS that fixed a serious security issue. What makes this issue interesting, is not only its severity but also the fact that the issue can be nicely pinned down two a single line of code. Conveniently, this code is open-source and available for analysis! In this post I’ll explain why this major security issue is, after all, the result of a number of quality issues, which are often undervalued as minor flaws.

Read more...


A fundamental challenge when introducing reviews is that reviewing code is hard. This post summarizes our practices to nevertheless make life for a reviewer as easy as possible.

Read more...


Code quality audits are a fundamental part of our daily work as software quality consultants. The objective of such an audit is to assess the quality of a system’s source code and identify trends based on the code’s evolution. That makes an audit an important prerequisite for ongoing quality control and improvement. Understandably, we are not able to publish the results of the audits that we do for our customers. That makes it sometimes hard for us to explain what such an audit looks like. Instead of lengthy descriptions, we decided to analyze the code quality of an open-source system and use this as a showcase to illustrate what our quality audits look like.

There are different categories of quality aspects that we analyze in our code audits. This is the first of a series of posts—each of which will deal with a single category. This first post introduces the system and focuses on its code structure.

Read more...


Reviews point out problems in somebody’s work. Unfortunately, both giving and receiving criticism can be hard. To successfully introduce reviews, we must overcome this resistance. Since finding (and later removing) problems is the primary goal of reviews, this challenge is inherent—no review process can avoid it. We can, however, make receiving review results much easier. This post describes two simple but effective practices we use in our code reviews.

Read more...


As the post ‘Tools Do Not Improve Quality’ by my colleague Nils already destroyed the naive dream of simply installing a tool and get all maintenance nightmare healed over night, I would like to address a follow-up question in this post: If tools are not sufficient, how can we improve quality then?

Several years ago when we still were blue-eyed researchers on software quality, we started out developing different kinds of quality analyses in the context of our tool ConQAT. We worked hard on eliminating false positives and achieved highly precise analyses at the end. We thought developers will love adressing each issue these tools emit. When we presented analysis results to developers, they usually agreed on the relevance of the deficits we identified. Thus, we integrated our tools into every nightly build we could find at our partners. However,

Read more...


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.

Read more...


The primary purpose of automated tests is to reveal regression bugs. But how can we tell how well a test suite does this? Code coverage measurement is often used to assess tests in practice. But what does it really tell? We analyzed a set of open-source projects to find out and came up with a clear answer. This post summarizes our findings.

Read more...


Let’s be honest. Who could possibly better judge the quality of our code than ourselves? We wrote this code. We are the experts. We might need some tools to do our assessment, but there is a growing number of freely available tools that help us to identify quality deficits in our product. So why should we invest in a professional code quality audit done by an independent organization? Let me give you a few reasons why I think a professional audit is a worthwhile investment.

Read more...


Quality control has many facets, but if there is one factor that distinguishes good from high-end quality control, it is the systematic use of manual code reviews. While a lot can be achieved by tool-supported analyses and improvements, manual reviews have some unique benefits.

Read more...


At least not all of them at once. The awareness of quality deficits (these include bugs, lack of understandability, missing documentation, a lack of tests, and so on) seems to follow a sinus-curve like shape.

In those phases with the highest awareness, project managers and their developer teams often decide to dedicate a larger block of time exclusively to cleaning up the system and putting everything else on hold. All too often, the ambitious objective is to remove all quality deficits—in many cases without even specifying what a relevant quality deficit is.

Don’t do this!

Read more...


During our daily work as consultants for software quality, as auditors of different kinds of software systems and in our role as quality engineers in software engineering projects, we have the opportunity to see a large variety of software development organizations. We encounter a huge amount of different systems from different domains, written in different languages and using various technologies. But most importantly, we talk to many many people that face the challenge of developing and maintaining software day by day. As a result, we receive a big treasure of experiences, insights, anecdotes and war stories on how to (and how better not to) develop software.

Read more...