The Rule of Three: “When you’ve written the same code for the third time, that’s when you should stop and refactor it into an abstraction.”
I think it's from Martin Fowler's book Refactoring. (It's been a while).
The gist of it is that with one or two cases you might create the wrong abstraction. When you have three, you can abstract away the right bits without creating a monstrosity of optional parameters and booleans.
> The Rule of Three: “When you’ve written the same code for the third time, that’s when you should stop and refactor it into an abstraction.”
Small but very important change: "[...] that's when you should stop and consider refactor it into an abstraction". Sometimes it's needed, sometimes it's not, dogmatic following of that rule lacks the required nuance for real-life programming.
I don’t believe it’s wise to add another iteration to working code just for the sake of aesthetics.
There will come a point where you will have to write a fourth implementation and at that point you really should be considering abstraction and reuse of your three earlier known good implementations.
There’s also an argument for abstraction instead of having three different people write three different implementations simultaneously. It lets you stub it out to unblock multiple teams, and centralize learning/iteration. Still imperfect and not always the solution, but worth considering in a move-fast environment.
I think it's from Martin Fowler's book Refactoring. (It's been a while).
The gist of it is that with one or two cases you might create the wrong abstraction. When you have three, you can abstract away the right bits without creating a monstrosity of optional parameters and booleans.