It happens everywhere, not just OO. It's just human nature.

I worked on C code where there were 8 layers of calls where each function was f() {return next_layer_f();} . The thing is sometimes layers serve a function and sometimes they don't. Then there's an always present pressure to look "professional" and so tons of layers and lots of details/checklists. The 4 lines of code that actually does everything you need doesn't cut it. And what will you do the rest of your day?

The funny/sad thing is it doesn't matter how hard you try to fight human nature it doesn't seem to work. I love how the Go developers thought `go fmt` will end the formatting nitpicks. Guess what, it doesn't. We just found other things to nitpick. Or "Agile" or whatnot. Python says "A Foolish Consistency is the Hobgoblin of Little Minds" ... Well, try that on your co-worker in your next Python code review ;) Functional programming doesn't help either. In very small teams/companies sometimes the stars align and magic happens but it's really hard.

EDIT: Also nothing to do with the article ;) though maybe we can dream up some connection to the human brain.

I used to be balls deep into OOP. I was in the rabbit hole. For me it was _the_ way programs had to be written. Whenever I started a new project, it would start out as a bunch of interfaces and abstract classes (with the god abstract class which everything extended from present and accounted for). At the time there was also the transition from PHP 4 to PHP 5 which unlocked a treasure trove of new OOP features and obviously every one of those features had to be used. However when things went wrong they would often turn into a nightmare, spending hours chasing down obscure bugs with endless print_r's to follow state changes. Over time I became better at managing this, keeping the amount of abstractions lower and just general better OOP design, but I was still afraid whenever things would go south, it meant hours of debugging, as was often the case. At one point or another I started asking questions about OOP design, the nature and origin of it and searched the internet for answers. Along the way I started realizing that many of the problems I was having are intrinsic to OOP. Whenever I would search for solutions to the complexity of OOP the answer would always be: you're doing it wrong.

Along the way I transitioned to OOP-less programming (I'm calling it OOP-less because I don't want to start a fight over "functional" vs "procedural" vs "..." etc...), not with the intention to do away with OOP but just to play with it. I rewrote some earlier, simple programs and what became rapidly obvious was how easy the code was to debug. The datastructures I had written prior were way too complex with too many levels and useless wrappers to make everything fit into the OOP paradigm. I rapidly became annoyed with the complexity of OOP and realized, I was in a rabbit hole and I had dug in _deep_. Even now when I'm writing bigger programs OOP-less I still find them much easier to debug. I'm still afraid debugging sessions can get rough but as time passes by this seems like more of a PTSD effect from my 15 year long OOP stint.

By now I've mostly done away with OOP programs but it's still annoying to have to interface with OOP designed libraries. I also changed my coding style camelCase to snake_case and the latter is much more legible to me but as a lot of libraries use camelCase or PascalCase it doesn't make the code look pretty.

So yes long story short, I share your assignment of blame. Complexity just seems to be the nature of the beast.

That’s a bit too extreme to me (and already covered by unit tests). Code reviews are good mostly for asking questions, not dictating changes.

What about performance? E.g. you don't want to implement an O(n) algorithm if an O(log(n)) equivalent exists, and merely testing inputs and outputs won't reveal that.