My colleague Martin already explained our journey to Git in his blog post. I would like to shed light on our motivation for that change and the experiences we made from a more methodological point of view. Furthermore, I would like to point out that we did not only exchange a versioning system but also changed our development process in a severe manner.

There are a number of code checking tools online that assist development teams in writing good code e.g. ESLint and FxCop. However, some situations may require that certain kind of code checks are not available in existing tools be used. Teamscale solves this problem through its Custom Check Framework. Additionally, Teamscale can perform the checks for code histories and help manage the findings resulting from the checks.

The Custom Check Framework makes it possible to write code checks that can spot problem areas in code, thus enabling Teamscale promote writing of high quality software and encouraging adherence to best coding practices. Compared with other kinds of analyses Teamscale runs, custom checking is achieved through a simpler

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…

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…

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.

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.

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.

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.

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.