In software engineering, relying on experience can render maintainability expertise into prejudice over time. For example, based on their own experience, some consider JavaScript as inelegant language and hence of lowest maintainability. Such prejudice should not guide decisions without prior empirical validation.
Many companies struggle with unexpectedly high maintenance costs for their software development which are often caused by insufficient code quality. Although companies often use static analyses tools, they do not derive consequences from the metric results and, hence, the code quality does not actually improve. We provide an experience report of the quality consulting company CQSE, and show how code quality can be improved in practice: we revise our former expectations on quality control from [1] and propose an enhanced continuous quality control process which requires the combination of metrics, manual action, and a close cooperation between quality engineers, developers, and managers. We show the applicability of our approach with a case study on 41 systems of Munich RE and demonstrate its impact. In our work with industry partners as well as with students in seminars we noticed that many people often stick to "aged" metrics when they want to evaluate the maintainability of software. They consider these metrics for this purpose without second thoughts, because the metrics are so present that almost every developer has at least heard the name and has some kind of knowledge about it. This smattering leads to an unreflected usage of theses metrics today without fully understanding them. To find suitable metrics for maintainability evaluation, we did a preliminary study, which indicated that still McCabe, Halstead and some kind of lines of code measurement dominate maintainability evaluation. We will discuss examples that question the ability of those metrics to reliably and automatically evaluate maintainability of software. Instead we will present metrics we consider more suitable to make solid statements about software maintainability. We conclude that our proposed metrics are better evaluators for maintainability because their impact on maintenance is clearer to interpret. Future work on metrics should carefully consider the use of "aged" metrics. It is often claimed that duplicated code, also known as softwareclones, occurs frequently. Different researchers have reported clonerates in the range of 19 and 28 , in extreme cases even 59 forparticular systems. It is not clear, however, whether those systemsare just outliers. In this paper, we analyze about 7,800 open-source projects written inC or C++, summing up to 240 MSLOC, and measure their clone rates. Weuse statistical analysis to estimate the means of clone rates in open-source projects. Based on our findings, we could not confirm the high clone ratesreported in previous studies as expected averages. Except for smallprojects including a few copied and modified files, we found ratherlow clone rates compared to previous studies. For instance, if aminimal clone length of 100 tokens (roughly 16 LOC) is requested, wefound an average rate of duplicated type-2 clones of about 12 . Fortype-1 clones of this length, we found an average clone rate of only1 .However, our results show also that cloning is common. We identifiedonly 20 of the projects to have no type-2 clone of at least 100tokens. And 44 of the projects have at least one type-1 clone of atleast 100 tokens. When large software systems evolve, the quality of source code is essential for successful maintenance. Controlling code quality continuously requires adequate tool support. Current quality analysis tools operate in batch-mode and run up to several hours for large systems, which hampers the integration of quality control into daily development. In this paper, we present the incremental quality analysis tool Teamscale, providing feedback to developers within seconds after a commit and thus enabling real-time software quality control. We evaluated the tool within a development team of a German insurance company. A video demonstrates our tool: http: www.youtube.com watch?v=nnuqplu75Cg.