When you work in a very large and complex codebase you encounter a few things that this author doesn’t seem to consider or thinks are very minor: 1. Refactorin

When you work in a very large and complex codebase you encounter a few things that this author doesn’t seem to consider or thinks are very minor: 1. Refactoring something introduces non-negligible risk. Consider a class with many fields and multiple mutexes it uses to control concurrent access to those fields. Even just consolidating those mutexes introduces the hard-to-conclusively-find-in-testing risks of introducing a deadlocks and livelocks. And that’s like the base case of refactoring the class: anything involving splitting the class up, moving data fields up or down the stack, changing the way member functions (which acquire locks) call each together is even more complicated and risky. It is just not worth refactoring this thing unless you have a very very good reason. 2. A function or object often has a many-to-many relationship in what it touches: it is called or accessed from multiple places and it calls and accesses many things. Non-trivial improvements to abstractions typically involve changes at both ends: which may be “as simple” as updating all the call sites to take a new argument or handle a different kind of error (hopefully all your call sites are structured so error handling is compatible with their abstraction!) or as complex as completely refactoring multiple levels up and down the stack to reflect better-abstracted semantics. No you shouldn’t lazily copy-paste around such problems when they are straightforward enough. But it can so so much less work (and again, less risk of breaking things) to use composition + wrappers, or inheritance, or to copy some little chunk to code than to do things the “right” way. 3. Let’s face it, your cool new abstraction sounds right in your head, but in a complex system it may just be playing abstraction whackamole once all the bugs and edge cases you’re not initially considering get addressed. It may be impossible to fully understand the entire system from beginning to end, without which it’s hard to be confident you’re actually improving things before embarking on your epic partial rewrite, or at the very least know you’re not changing semantics around some arbitrarily-drawn box. But if you’re not even changing the semantics, see point 1.