How do you know when to NOT refactor?
Michael Crenshaw
Posted on July 2, 2019
What Sparked the Question
I recently leafed through The Power of TED*," a book-length parable about destructive cycles of human psychology in relationships.
At first I was annoyed by the abstractions. The "Dreaded Drama Triangle" made up of Victim, Persecutor, and Rescuer roles just seemed too neat and tidy to actually describe reality. It seemed the author was under the delusion that they'd pushed aside some curtain and glimpsed Reality Proper.
But then I realized the abstractions are just abstractions - useful heuristics to help people ask and answer the right questions. "Am I thinking of myself as a victim, and how might that impact my relationships? Do I recognize this kind of cycle in my life?"
(Aside: recognition of victim-hood can be useful. From what I can tell, the book thoughtfully avoids judgment of people who recognize "persecution" and instead focus on how to break harmful cycles of behavior. If people choose to wield the book's ideas judgmentally, that's obviously bad.)
The Question
Someone recently remarked to me, "A developer's first reaction to anyone else's code is 'This is rubbage, let's redo it all.'"
Though hyperbolic, the remark hit home. I refactor by default, and I don't have enough tools to recognize when I should leave less-than-perfect code alone.
So I wonder: How do you determine when to not refactor? What questions do you ask yourself or others? What kind of "gut feelings" do you encounter?
I'm also interested in hard-and-fast rules, but I suspect many readers will have more approximate tools at hand.
Posted on July 2, 2019
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
November 30, 2024