Don’t!
“Rehacktor” is a portmanteau of “refactor” and “hack.”
I consider rechacktoring to be a bad thing as opposed to this definition that has a happy ending:
The act of reaching a level of hackedness so great that the resultant code is elegant and sophisticated.1Found on Twitter a long time ago, no longer available.
Something a bit more towards what it means to me—a Twitter search of “rehacktoring” will get some results along the lines of:
refactoring without tests
Even without automated tests at the very least you should manual test each change because they are supposed to be behavior preserving changes.
Otherwise it’s not really refactoring, is it?
I suppose if you didn’t take small enough steps, e.g. attempting a whole bunch of changes all at once, you might end up with a ridiculous state of the code which is worse than its pre-refactoring state or just left in a broken state. Kind of like creating a huge mess of stuff on the floor in an act of reorganization and then never actually putting things back. In that sense, “rehacktoring” could be a retroactive term to describe an abandoned refactoring.
My Definition
I propose another meaning which subsumes the previous definition:
Any refactoring effort which is a mini death march.
In other words, a refactoring effort with a high chance of failure due to schedule, resources, etc.
If you’re not familiar with the term death march2Yourdon, E. (2004). Death March. 2nd ed. Prentice Hall.:
A death march project is one for which an unbiased, objective risk assessment (which includes…technical risks, personnel risks, legal risks, political risks, etc.) determines that the likelihood of failure is ≥ 50 percent.
I think a common trigger of rehacktoring is managers/clients demanding refactoring of crappy code that is critical to a deployed application.
Another is refactoring that is squeezed in by the developer but it’s not at the level / quality it should be because the developer was told to just fix / add features to some old crappy code but not officially allowed to refactor at all (and in some of those cases the whole thing should just be rewritten from the ground up).
Choices
But refactoring is not the only answer. Some legitimate alternatives include, but are not limited to:
- Don’t refactor. Spend time on other/new functionality.
- Rewrite the class/module/application from scratch.
- Stretch the refactoring out to a longer time frame, so that everyone involved is still spending most of their effort on new functionality that users care about.
The proposal to rewrite a module or application from scratch will scare those of weaker constitution. But it does work in many circumstances. Keep in mind that the first crack at doing something new might be the necessary learning phase to do it right the second time.
A manager, a client, a stakeholder—maybe your own traditions—might convince you that refactoring is quicker and/or lower risk than redoing it.
But that is not always the case, especially if you are more motivated to make something new rather than tinker with something old.
And I have seen the rewrite approach work in the wild. I’ve done it myself and probably should have done it more often in my career. I first saw this as an intern at an applied AI company, where one intern had written a working version 1 for a contract, and then I came in and wrote a completely new version 2.
On the other hand, the organization/client might not know there’s a real need for refactoring so that the future changes don’t keep taking longer and longer as the whole architecture crumbles under its own weight. In which case you the developer may have to speak up and say we need to spend some time refactoring. As long as you don’t crunch it into rehacktoring.
Conclusion
Rehacktoring is almost always the wrong thing to do. It is especially the wrong thing to do if it causes psychological depression in the programmer. After all, who wants to waste their life changing already-working code from bad to semi-bad?
Based on observations (albeit not very scientific), I suspect that programmers are particularly ill-suited to refactoring code that they did not originally write—unless the refactor is a focused complete rewrite of a particular cohesive chunk (a module, a class, whatever). They have no emotional connection to the old code. And that makes the alternate solutions listed above all the more appealing for the “soft” aspect of a team.
