  The aims of this paper are: 1) to identify "worst smells", i.e., bad smells
that never have a good reason to exist, 2) to determine the frequency,
change-proneness, and severity associated with worst smells, and 3) to identify
the "worst reasons", i.e., the reasons for introducing these worst smells in
the first place. To achieve these aims we ran a survey with 71 developers. We
learned that 80 out of 314 catalogued code smells are "worst"; that is,
developers agreed that these 80 smells should never exist in any code base. We
then checked the frequency and change-proneness of these worst smells on 27
large Apache open-source projects. Our results show insignificant differences,
in both frequency and change proneness, between worst and non-worst smells.
That is to say, these smells are just as damaging as other smells, but there is
never any justifiable reason to introduce them. Finally, in follow-up phone
interviews with five developers we confirmed that these smells are indeed
worst, and the interviewees proposed seven reasons for why they may be
introduced in the first place. By explicitly identifying these seven reasons,
project stakeholders can, through quality gates or reviews, ensure that such
smells are never accepted in a code base, thus improving quality without
compromising other goals such as agility or time to market.
