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.

In many domains software is a highly critical part of the products, especially in automotive and avionics systems, in medical equipment, and in military systems—software failures may cause severe damage to machines or even cost human lives.

Thus, it is broadly accepted that software quality is the key to developing safe systems. Most people out there have deep trust in the quality of the software controlling the cars they drive, the planes they fly with, and the equipment that is keeping them alive during medical surgery. To be honest, most of this software works really well. However, when looking behind the curtains, I sometimes wonder why.

Safety critical systems need to be certified and thus undergo rigorous qualification processes. There are…