It seems that many people are afraid of the word refactor. I think in many cases, if someone admits they need to refactor, it means they either didn’t do their job right. They either missed requirements, wrote inefficient or buggy code, etc. Alternatively, there is something fundamentally wrong with the product or system. The fact of the matter is that sometimes there are big problems and a major refactor/rewrite is required. I think that is rarely the case, but if embraced by all and done judicially, the outcome can be significantly better and the major refactor avoided.
It doesn’t matter if it is a feature, deployment script or architectural decision, at some point, everyone must admit they are not clairvoyant and cannot predict every way end-users or systems will behave. Therefore, there will be missed/new requirements and unforeseen problems. As such, I very much embrace the philosophy of build for what you know now and adapt as you go. Typically, that means the output is simpler, it got done faster and enhancements and bugs are easier to address. That philosophy also means you are constantly in a state of refactoring, or said differently, incorporating new learnings, making individual methods more efficient, improving the readability of the code, filling in missing tests, etc.
Now, just because we have embraced refactoring and we have noble intentions of, in general, leaving the code better than we find it, that doesn’t give us the license to go crazy and start rewriting everything we see. I think there are right and wrong times to refactor.
First and foremost, don’t let those yucky bits of code distract you from your real purpose which is to deliver business value by building those new systems, features and fixing bugs. So instead of just jumping right into refactoring, quickly note the yuck as a TODO in the code, story or in your notepad so you don’t forget about it, but also stay on task. That said, bad code that is directly in your way is fair game and I even think that bad code near the edges of your task are also fair game.
Secondly, follow good engineering practices. Make changes in small, bite size chunks, test and deploy your changes often and communicate them with the team. In the end, you will end up with a better product, happier end-users and engineers which should all translate into a more successful business.
If you are one of those clairvoyants, then email me and let’s talk over a beer because I have lots of questions. Otherwise, if you are a mere mortal like myself, then embrace the “R” word and seek out companies and teams that also embrace it. At the end of the day or after a few releases, it is pretty impressive to reflect back on how adaptable the team and code can be while solving real problems very quickly.