When Refactoring Becomes Perfectionism
Perfectionism. It happens to the best of us. There’s an eye-opening short video on YouTube. It helped me see when a solution is good enough.
My name is Till Carlos, and in my agency I lead team of engineers. I document the learnings while we build software products.
And today I want to look at a problem many engineers face. I call it the refactoring-perfectionism fallacy.
Where it started
There’s this short video. Check it out:
Summary, Primeagen: Don’t Make This Mistake:
- They start with a solution here
- Then the use it at another point, and generalize it
- Then they use it in a third point, and now it breaks.
At this point they have the choice to
- Hack it and build edge cases into it (thus making it ugly)
- Refactor it and make it work well in all three cases.
Option 2 is almost always the wrong choice.
But engineers LOVE to go there.
It always takes longer than we think
Because the third place to use something is underestimated.
- Three points of contact is WAY more than just two.
- You might never need it beyond these three cases.
- You go from an if-else to a case condition
It might be worse: you might think this is a great example for using a Factory patteren which spits out configuration PO-whatever-Os.
Example from my code: This is a possible solution - but I won’t got here.
What to do instead
Instead of falling into the refactoring trap, consider these alternatives:
- Add an edge case: Sometimes, a simple hack is all you need.
- Duplicate the code: In moderation, code duplication isn’t always evil.
- Ship it: Focus on delivering value rather than achieving code perfection.
Remember, the goal is to create functional, maintainable software – not to write the most elegant code in the world.
The next time you’re tempted to refactor for that third use case, pause and ask yourself: Is this really necessary, or am I falling into the perfectionism trap?
