Large, long-lived software systems often cope with the problem of technical debt caused by shortcuts that were taken to increase development speed that result in code that is difficult to maintain. A technical debt can be justifiable, e.g., for quickly getting a new product on the market. However, just like actual debts, if the debt is not repaid, one has to pay interest, which takes the form of additional time that developers need to understand and change complex code. Intuitively then, we could refactor the code to pay off the technical debt that has accumulated.
This also fits with the argumentation of Robert C. Martin in his book Clean Code in which he urges developers to take care of their code and start writing clean code as he claims that the structure of code has an impact on the development productivity.
Recently then, one of my MSc students (Erik Ammerlaan, @eammerlaan) set out to investigate whether refactoring actually increases the understandability of code. He performed his investigation in an industrial environment and involved 30 developers from one company (Exact). Those 30 developers are working in 11 different teams spread out over 2 countries.
In order to measure the understandability, he set up 5 experiments that required the participants to make small changes to the code. Starting the hypothesis that “If given the refactored code, developers finish the coding task earlier than if the original code were given.“, the 30 developers had to work with either the existing version of the code, or the refactored version.
Clean code: influencing understandability both positively and negatively
When the original and refactored code were shown side-by-side after each experiment, most developers appreciated the refactored code and preferred it over the original code. They recognized that having ‘clean code’ would make the codebase more understandable. Yet, this seem to contrast our results. In the 5 experiments, we observed that the productivity of developers can be influenced both positively and negatively by code that is refactored for understandability when performing small coding tasks. Depending on the task and the individual, so-called clean code does not immediately improve one’s understanding of code, if one is used to working with the old structures present in source code. As such, we can say that old programming (understanding) habits do die hard.
A matter of quality?
We noticed an important difference in the quality of the solutions implemented in original and refactored code, serving as a first indicator that good quality code prevents developers from writing sloppy code. This is in line with the broken windows theory, a criminological theory that can also be applied to refactoring: a dirty code base makes developers feel that they can get away with ‘quick and dirty’ code changes, while they might be less inclined to do so in a clean code base.
Our experiments showed that having refactored code in general provides no instant benefits with respect to understandability and developers need time to adjust. We fully acknowledge that in the longer term, refactoring benefits might become much more clear and are likely to go beyond understandability (e.g., extensibility, reusability, testability, …)
Erik Ammerlaan, Wim Veninga, Andy Zaidman. Old Habits Die Hard: Why Refactoring for Understandability Does Not Give Immediate Benefits.
Proceedings of the 22nd International Conference on Software Analysis, Evolution and Reengineering (SANER), pages xxx-xxx. IEEE, Montreal, Canada, March 2015.
[LINK TO PDF]