Refactoring
The benefits of refactoring code are theoretical in nature. Refactoring is effort spent on code that does nothing, business-wise. The theoretical benefits are more strategic than tactical; one trades 5 hours of work now for the hope of saving more than 5 hours of work later. The strategy employed is to make debugging, updates, and maintenance easier to handle. The short-term loss of 5 hours is worth it in the long run, as theoretically endless hours can be saved later on.
Refactoring has a special problem in products that have yet to be released. When a product is not in production, it is not producing any value. Spending time to refactor it delays the time to deployment, and thus results in a loss of capital. Instead, the correct tactical decision might be to employ the code to production in its current state. After it's deployed, spend some time on refactoring it while it is generating value. This results in less cap-ex and more op-ex, sure, but that is only true if one is not being honest about the time spent refactoring prior to deployment. That is also op-ex - it's just easier to hide the fact.
The shifting of refactoring to before deployment is not a gain in cap-ex; it is still using op-ex to maintain, or refactor, the code, but it is not gaining any capital value. Instead, it is delaying the capital until after the operational expense is complete.
One might argue that refactoring is akin to QA. That might be true, but large-scale refactors before deployments have always cost me 10x more time than QA, and unlike QA, no bugs are found, which means no real value was added from the extra time spent on the project.
So what's the solution?
The only correct solution is, obviously, to code perfectly all the time. Never make mistakes. Never write code that even looks like it could be refactored. This is the only true and proper way to code.
It seems that, once again, gamers are right - "git gud" wins again.
Comments:
Leave a Comment
Submit