Who hasn’t been confronted with the famous “spaghetti code” characteristic that occurs so often in projects that have undergone years of development? Such types of code are typically hard to understand and maintain, and could scale-up to the system level, leading to a phenomenon we call “software entropy” or “code decay”.

Most of the work done by software developers is concerned with extending and enhancing existing systems rather than producing new systems (see [1,2,3]). Software entropy seriously hinders these activities, which can substantially increase the total project costs, thus it has become an important area of concern for many software architects and managers.

To address this issue, companies have increased their focus on evaluating and improving maintainability of the code base. For example, Microsoft’s Office division assigned 20% of its development effort to re-develop/modify the code basis of their products [4]. A typical way to evaluate maintainability is to use code metrics to measure characteristics of the system. However, the problem with metrics is that they are hard to interpret and they do not provide clear guidance for improving the quality (What does a Cyclomatic Complexity of 342 mean? What can I do to improve this number?).

With the increasing adoption of agile development methods, practices like refactoring [5] and the use of code smells [6] for source code analysis have become popular in pursuit of the holy grail of producing “beautiful code”. In general, these practices support software evolution and improve maintainability. However, not all refactorings pay-off in all situations and not all code smells are as “smelly” as one may think. Architects and developers still face the challenge of making redesign and refactoring decisions based on questions like: Which are the worst code-smells we need to get rid of? Which are the less risky refactorings? How can we do more “smart” and cost-effective refactoring? Are these notions built over code smells just a myth in order to achieve the beautiful code or do they really have practical consequences?

In this presentation, we provide a glimpse on the advances that have been booked by the software engineering research community for analyzing code smells and discuss some empirical results from studies on refactoring strategies. Our aim is to give developers and architects useful insights for prioritizing refactoring tasks and suggest different ways of combining source code analysis and human evaluation for supporting software evolution in their daily work.

[1] C. Jones. Estimating Software Costs. McGraw-Hill, 1998. [2] K. H. Bennett. An introduction to software maintenance. Information and Software Technology, 12(4):257–264, 1990 [3] T. M. Pigoski. Practical Software Maintenance – Best Practices for Managing Your Software Investment. Wiley, 1997 [4] M.A. Cusumano and R.W. Selby, Microsoft Secrets USA: The Free Press, 1995 [5] Opdyke, W.F., Refactoring Object-oriented Frameworks. 1992, University of Illinois. [6] Fowler, M. and Beck, K., "Bad Smells in Code," Refactoring: Improving the Design of Existing Code Addison-Wesley, 2000, pp. 75-88.