This post is split into two parts of understanding the question of when to refactor, the business question and the technical question.<\/p>\n
Business Question<\/strong><\/p>\n The first question with refactoring, as with any business decision, is “Should we do this at all?”<\/p>\n While software written “the right way” feels good to read, it doesn’t necessarily always fit business objectives. An application that is long lived, undergoes frequent updates, or provides critical business functionality is in need of much more refactoring than code that is to be soon thrown away, never changed, or provides little business value. In refactoring, the long lived application saves development time during maintenance. The frequently updated application saves time adapting to the market. Finally, the critical business application improves reliability. But in each of these cases there are costs, in development time as well as complexity of the solution and end user outcomes.<\/p>\n When evaluating these factors remember that we should be aware of bias that leads us to underestimate each of them. Code can live a very long time, often longer than your length of employment at the same company, frequently longer than the company itself, and sometimes longer than a lifetime. There a number of antiquated systems running in programming languages not taught in schools anymore, that generate enormous wealth for corporations.<\/p>\n In conjunction with our ineptitude in judging the lifespan of an application, we often misjudge how it will change and how often. This can swing either way however, so it is often good practice to refactor a little more flexibility into an application with each change, rather than trying to augur all the ways it will change on the first attempt. This way the areas which most frequently change will naturally accrue the most flexibility, while keeping those areas which do not change that much simpler.<\/p>\n The final factor of business value is misaligned by the availability heuristic<\/a>. As a programmer we are often disconnected from the users of our work, which make us unaware of the value that same work is actually providing. While a strict definition of refactoring might entail no changes to the functionality of a system, in reality small tweaks to configurability and usage occur as we try to increase flexibility and reduce complexity of a system during refactoring.<\/p>\n However, a feature that seems useless or overly complex to us, may be saving days worth of work or generating large amounts of value for a few users. A more direct line of communication to the users of an app should let you discover more clearly what functionality might be more important to the business. That direct line of communication could take the form of face to face conversations or feedback surveys. However, as a developer you have unique opportunity to also incorporate telemetry, audit, and log capture into your application as well. When possible back your expectations regarding refactoring needs with hard data on what features users are accessing and how much they are using it, and what changes when they do.<\/p>\n Technical Question<\/strong><\/p>\n Now, given an example where we are reasonably certain that the work will pay for itself in future development savings, here are 10 common situations where you should be thinking about refactoring:<\/p>\n\n