Well, in that case, why do it now instead of waiting until “the future”?
If it’s needed in the future, the cost is not more than it is now. If it isn’t needed in the future, then he’s wasted his time. If something similar is needed, but it needs to be refactored in a different way, they are going to have to refactor it
There is no special case “trap”. Business requirements necessitated changes.
> Well, in that case, why do it now instead of waiting until “the future”? If it’s needed in the future, the cost is not more than it is now.
They're familiar with the code and its gotchas when it was written. In "the future" most of that context will be gone (people forget stuff, and change companies/teams/roles).
Better to get rid of the gotchas before you get burned.
> If it isn’t needed in the future, then he’s wasted his time.
The new version was still more readable to newcomers, and resizing stuff is pretty core functionality for a drawing program.
> If something similar is needed, but it needs to be refactored in a different way, they are going to have to refactor it
A second pass of refactoring tends to be easier than a big ball of mud. And in the worst case, they can always inline it and start over from the same state.
> There is no special case “trap”. Business requirements necessitated changes.
When requirements change you can either start adding special cases or rethink how it fits into the bigger picture. That matters in every layer, but it's especially important in the UI layer.
Unless you want to end up with an unusable Apple-style hodgepodge. In that case, go wild, I guess.
Yes, it made future modifications easier and discouraged adding special-case behaviour.
And after reverting the change they did apparently fall into that trap.