Wrong abstraction hurts way more than no abstraction.

Of course “it depends” — all abstractions are constantly wrong in a way (there are no correct models only useful ones) and we iteratively try to make them “less wrong” over time. What I am refering to is being “over confident” and going all out on “abstracting away” at the times when we really “don’t know” which tends to happen during “big bang” refactoring sprees.

Jumping from a 1000 lines long controller action embedding business logic, persistence etc. to 30 files / classes in a single refactoring pass can be really dangerous and hard to revert. Small increments are the only way to go.

No abstraction means “no constraints” and “no hard opinions”. Adding constraints and moving to a more opinionated piece of software tends to be a lot more natural and easier than fixing a wrong abstraction with dozens of wrong constraints and invalid concepts that have been festering for years becoming more and more distorted.

Of course I haven’t always been of this opinion. I’ve been in both camps (also in the big bang refactoring camp) and only then these kinds of things become obvious.

Refactor early and often. If for some reason you haven’t been doing that — You can’t fix it over night !