Wednesday, September 28, 2016

Comments on "To what extent can maintenance problems be predicted by code smell detection? – An empirical study"

Article: To what extent can maintenance problems be predicted by code smell detection? – An empirical study

I highly recommend to all to read this article, it is big but have valuable details of great experiment. I doubt that smb could conduct smth similar as it is very costly.

Some valuable quotes from article:

Results: From the total set of problems, roughly 30% percent were related to files containing code smells. ......
Conclusions: The role of code smells on the overall system maintainability is relatively minor, thus complementary approaches are needed to achieve more comprehensive assessments of maintainability.
Moreover, to improve the explanatory power of code smells, interaction effects amongst collocated smells and coupled smells should be taken into account during analysis.

Is 30% of problems are minor ? 30% of problem that can be predicted on the moment of writing code in automatic mode without wasting time of other engineers. I doubt that it is minor.

Lets take a look deeply to report:

Twelve different code smells were detected in the systems via Borland Together and InCode.

Ancient systems , non of them is alive now !
Where is opensource stack of tools like: Checkstyle, PMD, FindBugs, SonarQube, IntelijIdea inspectionsnondexforbiddenapis, error-prone, ..... ?

We report on a multiple case study in which the problems and challenges faced by six developers working on four different Java systems were registered on a daily basis, for a period up to four weeks.
there is a substantial body of work that investigates if certain source code characteristics (i.e., a code smell) affect a given maintenance outcome (e.g., effort, changes, defects).

Selected model is pretty impressive and based on real code.

Individual progress meetings (20–30 min): were conducted daily, with each of the developers and the researcher present at the study to keep track of the progress, and register problems encountered during the project (ex. Dev: ‘‘It took me 3 h to understand this method. . .’’)

3h is too much for a method , if that is more than 20 min or even 5 min - it is problem and code smell.

Code smells automatically detected in the systems:
Data Class
Data Clumps
Duplicated code in conditional
Feature Envy
God (Large) Class
God (Long) Method
Misplaced Class
Refused Bequest
Shotgun Surgery
Temporary variable for various
Use interface instead of
Interface Segregation Principle
(ISP) Violation

it is strange why that minimal amount of code smells are detected only , look like list whole smells were not that big. Not clear why minor smells are ignored in investigation. In you have 5K minor problems in project , you have a lot of problems, and you will pay for that on daily basis. Minor problems stumble engineer for 2min, 5min .... but that time is valuable too! At the end of the day it could come up to 30min or even an hour.
Minors can not be ignored, as they can make engineer to tire and slightly demotivate and in general performance will be slightly lower.

In total, 137 different problems were identified from the differ-
ent maintenance projects. From the total, 64 problems (47%) were
associated to Java source code. The remaining 73 (53%) constituted
problems not directly related to code such as: lack of adequate
technical infrastructure, developer’s coding habits, external ser-
vices, runtime environment, and defects initially present in the

almost 50% of problems could be find automatically . And by the way, "developer’s coding habits" is also code smell.

From the total set of difficulties identified during maintenance,
less than half (43%) were related to Java code, and from those, only
58% clearly related to any of the twelve code smells used to analyze
the code. This means that even if we count those difficulties that
are due to combination of factors, roughly only 30% of the total
set of difficulties can be explained and potentially foreseen by code
smells. As a result, we conclude that the subset of aspects that are
covered by current code smell detection has a relatively low
The results from our study reminds us of the limitations of evaluations based purely on static analysis and suggest the need of more comprehensive quality models and techniques that can incorporate the analysis of diverse factors.

Even in average it is 30% for purely static analysis ..... is it low ? Just offer your manager 30% bust in productivity in development that could be archive by using free tools in CI or IDE integrations!
I doubt I would say "Do not bother about this."