Mitarbeiter

Dr. Nils Göde


… unterstützt Sie dabei die Qualität Ihrer Software zu analysieren und zu verbessern. Vor diesem Hintergrund habe ich bereits eine Reihe großer Systeme in einer Vielzahl unterschiedlicher Projekte analysiert. Ich habe an der Universität Bremen und der Bond University in Australien Informatik studiert und bin ein Experte für Software-Qualität. Meine Promotion im Bereich Software Engineering habe ich an der Universität Bremen durchgeführt.

  • +49 space::176 space::10452662
  • goede@invalid::cqse.eu
  • @NilsGoede

Blog Posts


Many static analysis tools excel at analyzing code that is written in popular programming languages like Java and C# for which there are tons of freely available resources like code examples and documentation. There is a substantial common understanding of coding best practices, frequent pitfalls and recurring code smells. In addition, existing libraries to parse and analyze code written in these programming languages make it easy to support these in a static analysis tool. So does Teamscale.

However, there is a large number of programming languages like Structured Text and Magik that are less popular but, nonetheless, highly relevant for certain domains. Maintenance of code written in these languages faces the same challenges as maintenance of code written in more popular languages. Hence, continuous quality improvement of this code is just as important as for other languages. Unfortunately, most static analysis tools fail when it comes to analyzing these languages because they either do not support the language at all, or the feature set becomes very thin.

With Teamscale we aim to support these languages just as well as we support popular languages. That means Teamscale provides its core features like incremental analysis, findings tracking, time travel, baselines, delta analysis, blacklisting, metrics and clone detection, for all languages in the same way. This applies, for example, to Structured Text specified by IEC 61131-3.

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


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


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


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


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


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


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


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


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


Vorträge


Dennis Pagano, Nils Goede:

Beobachtest du noch oder verbesserst du schon? Kontinuierliche Qualitätsverbesserung in der Praxis.

Talk at Seacon 2017, 2017.

Nils Göde:

Quality Control in Action.

Talk at the 17th Workshop Software Reengineering and Evolution, 2015.

Nils Göde:

Qualität in Echtzeit mit Teamscale.

Talk at the 16th Workshop Software Reengineering, 2014.

Nils Göde:

Reengineering Required: Quality Deficits of Industrial Software.

Talk at the 15th Workshop Software Reengineering, 2013.

Nils Göde:

Delta Analysis.

Talk at the 14th Workshop Software Reengineering (WSR), 2012.

Nils Göde:

Qualität außer Kontrolle.

Talk at the GI Regionalgruppe Köln, 2012.

Nils Göde:

What Clone Coverage Can Tell.

Talk at the 6th International Workshop on Software Clones, 2012.

Nils Göde:

Code Clones: Friend or Foe?

Talk at the University of Saskatechewan, 2011.

Nils Göde:

Frequency and Risks of Changes to Clones.

Talk at the 33rd International Conference on Software Engineering (ICSE’11), 2011.

Nils Göde:

Not All That Glitters Is Gold.

Talk at the 13th Workshop Software Reengineering (WSR’11), 2011.

Nils Göde:

Oops!... I Changed It Again.

Talk at the 5th International Workshop on Software Clones (IWSC’11), 2011.

Nils Göde:

Clone Evolution Revisited.

Talk at the 12th Workshop Software Reengineering (WSR’10), 2010.

Nils Göde:

Clone Removal: Fact or Fiction?

Talk at the 4th International Workshop on Software Clones (IWSC’10), 2010.

Nils Göde:

Evolution of Type-1 Clones.

Talk at the 9th International Working Conference on Source Code Analysis and Manipulation (SCAM’09), 2009.

Nils Göde:

Incremental Clone Detection.

Talk at the 13th European Conference on Software Maintenance and Reengineering (CSMR’09), 2009.

Nils Göde:

Mapping Code Clones Using Incremental Clone Detection.

Talk at the 11th Workshop Software Reengineering, 2009.

Veröffentlichungen


Nils Göde:

Quality Control in Action.

Softwaretechnik-Trends, Vol. 35, 2015.

Daniela Steidl, Nils Göde:

Feature-based Detection of Bugs in Clones.

Proceedings of the 7th ICSE International Workshop on Software Clones (IWSC’13), 2013.

Jan Harder, Nils Göde:

Cloned code: stable code.

Journal of Software: Evolution and Process, 2012.

Nils Göde, Florian Deissenboeck:

Delta Analysis.

Softwaretechnik-Trends, Vol. 32, 2012.

Nils Göde, Benjamin Hummel, Elmar Juergens:

What Clone Coverage Can Tell.

Proceedings of the 6th International Workshop on Software Clones (IWSC’12), 2012.

Saman Bazrafshan, Rainer Koschke, Nils Göde:

Approximate Code Search in Program Histories.

Proceedings of the 18th Working Conference on Reverse Engineering (WCRE’11), 2011.

Nils Göde:

Clone Evolution.

Unsupported type: book, 2011.

Nils Göde, Jan Harder:

Clone Stability.

Proceedings of the 15th European Conference on Software Maintenance and Reengineering (CSMR’11), 2011.

Jan Harder, Nils Göde:

Efficiently Handling Clone Data: RCF and cyclone.

Proceedings of the 5th International Workshop on Software Clones (IWSC’11), 2011.

Nils Göde, Rainer Koschke:

Frequency and Risks of Changes to Clones.

Proceedings of the 33rd International Conference on Software Engineering (ICSE’11), 2011.

Nils Göde:

Not All That Glitters Is Gold.

Softwaretechnik-Trends, Vol. 31, 2011.

Nils Göde, Jan Harder:

Oops!... I Changed It Again.

Proceedings of the 5th International Workshop on Software Clones (IWSC’11), 2011.

Jan Harder, Nils Göde, Marcus Rausch:

Stability of COBOL Clones.

Softwaretechnik-Trends, Vol. 31, 2011.

Elmar Juergens, Nils Göde:

Achieving Accurate Clone Detection Results.

Proceedings of the 4th International Workshop on Software Clones (IWSC’10), 2010.

Nils Göde, Marcus Rausch:

Clone Evolution Revisited.

Softwaretechnik-Trends, Vol. 30, 2010.

Nils Göde:

Clone Removal: Fact or Fiction?

Proceedings of the 4th International Workshop on Software Clones (IWSC’10), 2010.

Jan Harder, Nils Göde:

Quo Vadis, Clone Management?

Proceedings of the 4th International Workshop on Software Clones (IWSC’10), 2010.

Nils Göde, Rainer Koschke:

Studying clone evolution using incremental clone detection.

Journal of Software Maintenance and Evolution: Research and Practice, Vol. 25, 2010.

Nils Göde:

Evolution of Type-1 Clones.

Proceedings of the 9th International Working Conference on Source Code Analysis and Manipulation (SCAM’09), 2009.

Nils Göde, Rainer Koschke:

Incremental Clone Detection.

Proceedings of the 13th European Conference on Software Maintenance and Reengineering (CSMR’09), 2009.

Jan Harder, Nils Göde:

Modeling Clone Evolution.

Proceedings of the 13th European Conference on Software Maintenance and Reengineering (CSMR’09), 2009.

Nils Göde:

Incremental Clone Detection.

Diploma Thesis. University of Bremen, 2008.

Forschungsaktivitäten