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.

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.

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.

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.

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…

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.

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

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.

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.

Who could possibly better judge the quality of our code than ourselves? We wrote this code. We are the experts. So why should we invest in a professional code quality audit? Let me give you a few reasons why it is a worthwhile investment.