Gemma Lynn / @ellotheth
you read a
have you used
has more in common with
Drawing general conclusions from empirical studies in software engineering is difficult because any process depends to a large degree on a potentially large number of relevant context variables. For this reason, we cannot assume a priori that the results of a study generalize beyond the specific environment in which it was conducted.
You (probably) won't find universal truths in empirical software engineering research.
Instead, look for environments similar to your own.
|Method||The Nitty Gritty|
|Results||The Raw Facts|
Test-driven development (TDD)
Little empirical evidence supports or
refutes the utility of this practice
Defect density of the four products
decreased between 40% and 90%
The teams experienced a 15–35% increase
in initial development time
One team at IBM and three teams at Microsoft,
TDD or TDD-inspired practice.
Each team operated in very different contexts. If their results using TDD line up, we can draw conclusions about TDD as a practice.
Any indication that TDD impacts software quality.
|Team||Defect density reduction||Time increase|
Developers using TDD might have been more
motivated to produce higher quality code.
The projects developed using TDD might have
been easier to develop.
Comparisons made via case studies can never be
perfect due to the complex contexts of both the
TDD seems to be applicable in various domains
and can significantly reduce the defect density
of developed software without significant
productivity reduction of the development team.
Future releases of these products, as they
continue using TDD, will also experience low
defect densities due to the use of these test
The impact of program identifier style on
The underlying hypothesis is that identifier
style affects the speed and accuracy of
comprehending source code.
Experienced software developers appear to be
less affected by identifier style; however,
beginners benefit from the use of camel casing
Program identifier names are at the core of
program comprehension....The two dominant
identifier styles are camel case and underscore.
Research in cognitive psychology suggests that
the use of underscores should increase
readability and hence improve comprehension.
If a particular style significantly increases
the speed of code comprehension, use of this
style would have a tremendous impact.
Groups of college students, both programmers and non-programmers, were presented with reading tasks in 5 studies.
Eye tracking, response times, and responses to SAT-style reading comprehension questions.
Subjects produce more accurate results using
camel-case identifiers but at a cost [to] time
Expert programmers exhibit little difference in
accuracy between the two styles and that,
through training, any difference could most
likely be mitigated.
Style appears to impact readability in simple
tasks not in the context of reading programs.
While in a natural-language context underscores
provide better readability, in a software
context, camel casing seems to provide better
The accumulated evidence leads to the
conclusion that camel case is the better
choice, especially for beginning programmers.
Reading natural language and source code appear
to be quite different.
The relationship between cloning and defect
Clones are generally considered bad programming
practice in software engineering folklore.
Our findings do not support the claim that
clones are really a "bad smell".
Maintenance and evolution might comprise up
to 80% of the overall cost and effort.
Martin Fowler et al. suggest that code
duplication or cloning one of the major
indicators of poor maintainability.
Another body of research presents evidence that
clones improve productivity.
Do clones contribute a very small proportion of
bugs, or the vast majority?
Researchers chose four major Open-Source Software
projects to analyze: Apache
httpd, Nautilus, Evolution, and
Most bugs contained hardly any cloned code.
Clones are not a major source of bugs.
The more copies, the lower the observed defect density.
File-scattered clones seem to have lower defect density.
Bugs with high clone ratio require smaller bug fixing changes.
Clones smell less bad than you thought they did.
Lots of researchers host their own papers independently:
Gemma Lynn / @ellotheth