Three Results, Many Definitions
Reviewed by Greg Wilson / 2011-10-22
Keywords: Code Ownership, Metrics
The joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering took place September 5-9 in Hungary. A lot of interesting work was presented; In today's post we'd like to step back and look at something that many papers had in common. The three we will use as examples are reviewed below.
Beck2011 Fabian Beck and Stephan Diehl: "On the congruence of modularity and code coupling". Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering - SIGSOFT/FSE '11, 10.1145/2025113.2025162.
Software systems are modularized to make their inherent complexity manageable. While there exists a set of well-known principles that may guide software engineers to design the modules of a software system, we do not know which principles are followed in practice. In a study based on 16 open source projects, we look at different kinds of coupling concepts between source code entities, including structural dependencies, fan-out similarity, evolutionary coupling, code ownership, code clones, and semantic similarity. The congruence between these coupling concepts and the modularization of the system hints at the modularity principles used in practice. Furthermore, the results provide insights on how to support developers to modularize software systems.
More simply, the authors compared measures of coupling (the degree of connectivity between classes) and modularity (how those classes are packaged together). One conclusion is that different ways of measuring coupling really do measure different things: only a few correlate with each other. Another is that the relationship between coupling and modularity is roughly the same across a spectrum of package types (data, event handling, graphics, I/O, etc.).
Giger2011 Emanuel Giger, Martin Pinzger, and Harald Gall: "Using the gini coefficient for bug prediction in eclipse". Proceedings of the 12th international workshop and the 7th annual ERCIM workshop on Principles on software evolution and software evolution - IWPSE-EVOL '11, 10.1145/2024445.2024455.
The Gini coefficient is a prominent measure to quantify the inequality of a distribution. It is often used in the field of economy to describe how goods, e.g., wealth or farmland, are distributed among people. We use the Gini coefficient to measure code ownership by investigating how changes made to source code are distributed among the developer population. The results of our study with data from the Eclipse platform show that less bugs can be expected if a large share of all changes are accumulated, i.e., carried out, by relatively few developers.
The Gini coefficient is a simple, intuitively-appealing measure of (in)equality that can be applied in many different contexts. (I once required students in a software engineering class to explain why we should or shouldn't use it to divide marks between team members based on lines of code committed.) This paper uses it to measure code ownership, then compares it to bug rates, and finds that modules with clear "owners" have fewer bugs.
Marinescu2011 Cristina Marinescu: "Are the classes that use exceptions defect prone?". Proceedings of the 12th international workshop and the 7th annual ERCIM workshop on Principles on software evolution and software evolution - IWPSE-EVOL '11, 10.1145/2024445.2024456.
Exception handling is a mechanism that highlights exceptional functionality of software systems. Currently many empirical studies point out that sometimes developers neglect exceptional functionality, minimizing its importance. In this paper we investigate if the design entities (classes) that use exceptions are more defect prone than the other classes. The results, based on analyzing three releases of Eclipse, show that indeed the classes that use exceptions are more defect prone than the other classes. Based on our results, developers are advertised to pay more attention to the way they handle exceptions.
Are some language features more fragile than others? In this paper, Marinescu looks at the correlation between use of exceptions and bug rates on a class-by-class basis, and answers the question with a qualified "yes".
These papers are all interesting in their own right, but what they and others have in common is equally interesting. In each, the authors have had to invent ways of measuring things, or borrow (and explain) one of several alternative ways. It's as if every physicist had to decide that momentum was an interesting concept, define exactly what they meant by it (since other scientists might be using slightly different definitions), and then explain to readers how they went about measuring it just to ensure there was no ambiguity. It takes a lot of time, effort, and mental energy, but it will continue to be necessary until we have stronger theories of software engineering on which to base our measures, and more experience to tell which measures are most useful. As we said in our American Scientist article, this is all part of how a new scientific field goes about defining itself. It's also a lot of fun…