I have always been a fan of architecture diagrams: I simply like the elaborate drawings that show how the complex whole is divided into parts and how those parts are connected.

These blueprints are an essential foundation for any discussions and it is expected that they match the reality as closely as possible.

»Big design up front« has proven to be impractical in the software domain.

For any non-trivial project, the domain complexity is usually so high that completing the design before starting the implementation is simply inefficient. As a counter-movement, some proponents of »agile« software development go as far as proposing no upfront design and no documentation at all. I find both approaches alarming and impractical. In this blog post, I will try…

After several technical blog posts I think it’s time for something different: I really enjoyed yesterday’s work day

Why?

Because of the freedom I have to manage and arrange my work time at CQSE as I like. I’ll briefly recap the whole work day in this blog post, explaining to you what this exactly means.

Over the past years we’ve seen customers loading hundreds of projects into single Teamscale installations, used by many users. And while Teamscale can handle the analysis of dozens of projects on a single machine, this often means running the hardware at maximum capacity, even on very large machines.

With the release of version 4.1, Teamscale is now cloud ready. To keep up with increasing numbers of users and projects handled by single Teamscale instances, we’ve been hard at work on a horizontally scalable deployment for Teamscale. It is now possible to deploy Teamscale onto many machines, making use of extra resources to handle larger work loads.

In this blog post, I will present an architectural overview of how Teamscale can be deployed for such a…

With Teamscale 4.0, we finally released pre-commit analysis, a feature that we and many of our customers have been looking forward to for quite some time. In this post, I will give you a brief overview of the feature and explain, why we are so excited about it.

We are happy to host the first ABAP Code Retreat (ACR) in the Munich area. It will take place on Saturday, February 24th 2018. Registration is open now—to register, please visit the registration page.

This event is a great opportunity to experience a Code Retreat in ABAP and to expand your ABAP skills. Spend the day with ABAP colleagues, connect with your peers, learn from each other, share experiences and be inspired by the great community. Just bring your own laptop. We provide you with an ABAP stack and access to the system for the event. In addition, we offer lunch, snacks and soft drinks for free!

We are happy to host the first ABAP Code Retreat (ACR) in the Munich area. It will take place on Saturday, February 24th 2018. Registration is open now—to register, please visit the registration page.

This event is a great opportunity to experience a Code Retreat in ABAP and to expand your ABAP skills. Spend the day with ABAP colleagues, connect with your peers, learn from each other, share experiences and be inspired by the great community. Just bring your own laptop. We provide you with an ABAP stack and access to the system for the event. In addition, we offer lunch, snacks and soft drinks for free!

When giving presentations or demos about Teamscale, we often get asked whether we use Teamscale for developing Teamscale. The answer is a clear »Yes!«. In this blog post, I’d like to shed some light on why and how we use Teamscale at CQSE.

Regardless of whether it is called eat your own dogfood or drink your own champagne, we are convinced that using your own product is essential for making your product great. Consequently, dogfooding is an integral part of the Teamscale development process. Not only do we believe that Teamscale helps us to write better code, we also think that it is very insightful to get an unfiltered impression of the end user experience of our tooling on a daily basis.

In particular, we see three benefits. First of all, Teamscale…

Redundant source code fragments—code clones— are a major indication of low-quality code. Code clones require you to propagate your code changes to multiple locations always risking to overlook individual locations.

This does not only increase the time needed to change the code but also leads to incomplete and costly bugfixes. Because code clones are one of the top-rated bad smells, Teamscale has a sophisticated algorithm to locate and inform about redundant code fragments.

However, when discussing code clones with Teamscale users, we often hear that »this is not a clone because there is no senseful way to eliminate the redundancy« I wrote this post to dispel this misunderstanding.

Over the recent years, version control systems have started to consolidate.

While there were lots of proprietary systems in the past, the world now seems to agree that distributed systems such as Git are the way to go in most cases. At CQSE, we switched our own development infrastructure from SVN to Git in 2016.

In this post, I will outline some important lessons I learned from migrating several code bases from proprietary solutions to Git over the last years.

Over the years, we have set up Teamscale for many customers. During these times, we learned a lot about how to set it up, which other tools are useful and how to maintain a Teamscale instance over time. We worked with small as well as with large teams and infrastructure ranging from the PC under some guy’s desk to a multi-server installation in the cloud.

Throughout all of these ventures, we found some best practices that I’d like to share with you.