A paper published in IEEE Software on how the practitioners viewed the role and importance of refactoring, and how and when they refactored. The study was based on the interviews of 12 seasoned software architects and developers at nine Finnish companies.
The respondents considered refactoring to be valuable but had difficulty explaining and justifying it to management and customers and did not use measurements to quantify the need for or impact of refactoring. Refactoring often occurred in conjunction with the development of new features because it seemed to require a clear business need.
Author’s post-print version (pdf): Leppänen et al. 2015, “Refactoring-a Shot in the Dark?”
Leppänen, Marko; Mäkinen, Simo; Lahtinen, Samuel; Sievi-Korte, Outi; Tuovinen, Antti-Pekka; Männisto, Tomi, “Refactoring-a Shot in the Dark?,” in Software, IEEE, vol.32, no.6, pp.62-70, Nov.-Dec. 2015.
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7310989
It is interesting to note what perceptions of refactoring people in the study had. Refactoring was mostly seen as an activity that involved making large structural changes instead of specific refactorings found in refactoring catalogs.
Developers were lead to refactoring primarily because time didn’t permit to design and implement more robust solutions previously. By refactoring, developers hoped, among other qualities, to increase the understandability of code and make future code changes easier. Implicitly, weak program structures were seen to prevent further development in some cases. If people cannot make heads or tails of the code or the structure does not allow the required flexibility, it can thwart development.
There are dangers people associate with refactoring, too. Refactoring means changing existing code structures, sometimes extensively, and subsequently defects might get introduced into the code while refactoring. Besides fearing breaking code, developers thought that success is not guaranteed when doing refactoring because existing structures might be too large and complex to change, and refactoring efforts might need to abandoned. As an architect interviewed in the study fittingly put it, refactoring is an investment in the future which might or might not realize.