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…

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.

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.

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.

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…

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.

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.

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.