Challenges in refactoring adoption

Real-life Challenges in Refactoring Adoption

Ganesh Samarthyam, Tushar Sharma, Girish Suryanarayana

CHALLENGES IN REFACTORING ADOPTION WWW.DESIGNSMELLS.COM

http://www.designsmells.com

Real-life Challenges in Refactoring AdoptionLast year one of us attended an interesting session in Agile India Conference - The

Power of Retrospection by Linda Rising. Linda persuasively presented on the importance of the reflection and emphasized the need to consciously reflect on our past experiences and learn from them.

This interesting idea led us to think about our experiences with refactoring design smells in the last few years. We realized that although refactoring is a well-known practice, adopting it in real-world projects throws up various challenges. In this article, we have tried to put together some of the challenges we have experienced.

Broadly, the challenges with refactoring can be categorized into two groups – management aspects and technical aspects.

Management aspects It is hard to convince managers about effort required for refactoring

In any development team, we find majorly three kinds of members based on their attitude towards refactoring:

• those who advocate refactoring and adopt refactoring as a regular practice • those who don't really like refactoring and want to “get the work done” – be

it fixing defects or adding new features• those who are sitting on the edge – they can swing either way depending on

the way they are persuadedIt is not that difficult for the first category members to convince the team members in

other two camps to adopt refactoring through technical argument. However, the



management puts business reasons before technical arguments and, therefore, presents altogether different perspective towards refactoring.

Many managers (who handles software development projects) we have met find refactoring to be a "needless rework" (this includes managers who advocate Agile methods!). In fact, we would like to talk about a discussion, where one manager expressed his frustration with refactoring by saying that “why developers need more time for refactoring? Why can’t they design correctly at the first attempt?” This argument shows the inadequate understanding of the manager on the core of the design: software design is a creative problem-solving activity – the best design evolves and cannot be created in the first attempt. Further, refactoring takes time and effort (and hence money), and the time spent is an investment towards the future. Some managers don't realize that refactoring is important for the "well-being" of the software product; instead they look out for immediate results. For this reason, managers especially those who are non-technical and those who pride themselves to be "result-oriented" tend to discourage their team spending effort doing "needless rework", i.e., refactoring! They use "if it ain't broken, don't fix it" as the reason to justify their approach. By "broken" they only tend to think “defects” (or “bugs”) and not “smells”. In our experience, such managers are hard nuts to crack and it’s not easy to change their outlook and convince them to adopt regular refactoring as a practice.

It is hard to quantify the effort for refactoring and benefits from refactoring

Managers love numbers - be it effort, time required, or savings. They are programmed to think in statistical terms such as ROI. For example, performing refactoring tasks requires effort and time - so managers want the effort and time to be quantified. Often, it is difficult to estimate the effort required to perform refactoring. Even simple refactorings such as "extract method" can sometimes result in regressions and can take considerable time to complete it. Similarly, the benefits of refactoring are also hard to quantify; advocates of metrics would say that you can use metric results to show the difference, but experience shows that the metric values might not capture the difference made by the performed refactoring. Further, showing number of fixed smells is also not completely justifiable since changes due to refactoring may lead to new smells if, not performed diligently.

Technical aspects

Assessing impact of changes during refactoring is hard



One of the toughest problems in performing refactorings in large-scale software is correctly predicting the impact of making a refactoring change. In large scale software, comprehending design is difficult and thus even simplest of refactorings can also lead to subtle bugs. In legacy software where the experienced developers who know in-and-out of the legacy code are no longer working with project, it is harder to understand the existing design, evaluate the potential impact of the change, and ensure that changes due to refactoring do not break the software. This is especially true when automated tests are not available as in the case of many legacy software systems.

Refactoring in the absence of unit tests – a chicken-egg problem

Refactoring in projects where unit tests are not available with adequate coverage is arguably the biggest technical deterrent of refactoring. You cannot write tests because the software is not testable and you need to refactor it. However, you cannot refactor it because there are no tests. Thus, absence of unit tests at the time of refactoring introduces chicken-egg problem.

Lack of tool support for non-trivial refactorings

When it comes to tool support for refactoring, we can classify such tools into broadly two categories – tools for refactoring candidate identification and tools for carrying out refactoring on an identified candidate.

The first category which analyzes source artifacts and reveals candidate spots (where to apply refactoring and which refactoring to apply) are very few and limited to research prototypes. In real world, this step is almost manual. Most of the efforts in refactoring tools community are concentrated towards the second category of the tools.

Most modern IDEs such as Eclipse and Microsoft Visual Studio have automated support to carry out refactoring once a candidate spot is selected by the user. Apart from these IDEs, there are many free and commercial tools available for refactoring. They make refactorings such as rename a source code entity (such as class, method, and variable), and extract method automated and easy with the click of a mouse. This gives a false impression to developers (not having experience with refactoring) that refactoring is automated and easy. That is true as far as trivial and simple refactorings are concerned. However, complicated refactorings are very difficult to achieve using tools and are still carried out manually. Let us consider a simple example of “extract class” refactoring; design smell detection tools such as Designite[1] can detect smells such as “multifaceted abstraction”[2]. However, extracting a class reliably is inherently difficult and requires



extensive manual intervention – most tools (to carry out identified refactoring) are still experimenting with algorithms and mechanisms to achieve it and they are “not-there-yet”. If you are not convinced, consider another example of “split layer” refactoring for the architectural smell “splittable layer”. What is a “layer” itself is something that the tools cannot reliably detect without annotations or some kind of specification from the designer. For the same reason, tools also cannot reliably and automatically perform this “split layer” refactoring.

Working in branches and globally diversified teams

Another practical challenge in refactoring adoption is working in separate branches where each team works on a separate work-package and merges the newer version with the main branch. Refactoring becomes inherently difficult when one refactoring requires change in two or more work packages. Merging different versions with conflicting changes make the exercise even more painful. Further, communicating the intended changes across globally diversified teams is another non-trivial challenge.

Summary:Refactoring is a practice that touches the core of software development and is an

essential software engineering practice for project teams to adopt. However, it would be naïve to think that taking up refactoring in large, complex, or distributed projects is easy. In this "from-the-trenches” article, we presented a few management and technical challenges in adopting refactoring in real-world projects. With this article, we hope to spur discussion that could help solve some of the burning problems in adopting refactoring as a regular practice.

References:[1] Designite – A Software design quality assessment tool. Available at http://

www.designite-tools.com[2] “Refactoring for Software Design Smells: Managing Technical Debt”, Girish

Suryanarayana, Ganesh Samarthyam, Tushar Sharma, ISBN - 978-0128013977, Morgan Kaufmann/Elsevier, 2014.

About the Authors: Ganesh Samarthyam ([email protected]) is an Independent Consultant and Corporate Trainer based in Bangalore.


mailto:[email protected]


Tushar Sharma ([email protected]) is a Technical Expert at Research and Technology Centre, Siemens Technologies and Services Pvt. Ltd., Bangalore.

Girish Suryanarayana ([email protected]) is a Senior Research Scientist at Research and Technology Centre, Siemens Technologies and Services Pvt. Ltd., Bangalore.



