You know what I dislike the most about doing client work? You see problems in the code, no bugs - things are working correctly, but the code itself is a problem. Finding code smells for example, and you know the best thing to do is refactor the code to save tons of time in the future. But some clients don’t get this and the ones that do get it will still say no to refactor work.
You tell the client you want to spend a couple of days to refactor the code but the client says “No”. To the client the code is working fine. Refactoring is going to cost more money and require more testing while providing little benefit to the end user. But the reality is ongoing maintenance cost for the code is going to cost more, which down the road could increase the cost to the end user, if refactoring does not occur. What is often overlooked is that maintenance costs can be lowered in the long term as a result of a refactoring investment.
Refactoring is something that should be embraced, not feared or viewed as an unnecessary cost. Refactoring improves the quality of the code and reduces code maintenance in the future and thus reduces cost.
A joy I have in writing my own software is being able to make the refactoring call myself. I don’t always say yes to refactoring but when the time is right I refactor the code. I don’t concern myself with the initial refactoring and testing costs because I know it will save me time and money in the long run.
So when is the time right? That’s a hard question to answer because the right time can be different for each shop and software package. For me a right time is when working on a new feature I find a number of code smells affecting the quality of the feature. Assuming a refactor will only affect a small portion of the entire system and it will take no more than a couple of days to refactor and test the changes, I make the yes call to refactor the code.
Do I worry about breaking existing functionality as a result of refactoring? Absolutely, especially when refactoring occurs in a critical area such as processing a credit card transaction. This is why it is so important to have automated scripts and unit tests in place. Automated regression testing definitely helps ease concerns.
So how do I convince the client it is time to refactor code? I wish there was a magic answer to the question that could be applied to all cases but there isn’t. Getting the client to okay a refactor takes having the client’s trust in your abilities and decisions.
One way to gain trust is to know when to recommend a refactor. You should make a point not to scream “fire” each time you find code smells. If each time you are asked to implement a new feature and you come back with “Before I can implement the feature I need to re-write all this other code,” your client’s trust in you will most definitely drop.
You also need to be able to show the client the long term value gained by refactoring. For instance, make the client aware of the various code smells and discuss the impact the repeated (or similar) code has to maintenance should a bug be found or a business requirement changes in the future. Also, remind the client that the need is fresh in your head but 6 months later it is going to take more time research the impact. Plus, the number of smells may have grown between the time the problem was first identified and the time code has to change, resulting in higher costs.
Lastly, be mindful of the business side. Many times developers only think of the technical aspects with no regard to the business side of things. Understand what is happening on the business side of a project will help when discussing a refactoring effort with a client. This can also help you understand why the answer is “No” and could help you identify a better “right time” to refactor.
Convincing a client it is time to refactor is no trivial task but it is possible.
Posted in uncategorized. Tagged in .