> You argument just boils down to bad programmers writing bad code. Good programmers can write bad abstractions as well, because good abstractions require suff

> You argument just boils down to bad programmers writing bad code. Good programmers can write bad abstractions as well, because good abstractions require sufficient understanding of what you're trying to abstract and we have blind spots (the unknown unknown). Thus the caution. > It has nothing to do with abstraction or not. "Bad code" is one thing, "bad abstraction" is a very specific subset of that problem. > Everyone either wants to find the silver bullet that will produce code perfectly the first time or find some concept to blame when it isn't. I think you're missing the point. Bad abstractions, especially when depended on by many users, are 10x bugs. Nobody's saying "make all code procedural and never abstract anything" -- however it's very valid to say "problems caused by bad abstractions are super bad so let's be extra careful." I mentioned strategies for being extra careful earlier: let more experienced folks do the design, defer the abstraction until you have more information, etc. There's also levels to everything. Of course there's no repercussions for how you structured the classes in your internal facing webapp. Nobody cares about your codebase except you. If you're building a foundational building block of a complex system however (e.g. the message bus for a self driving car) you had better make the best approximation of the right answer from the get go, because that system isn't going to be re-built for many years. > Don't combine logic and you need twice as many programmers to do the work. This doesn't ring true. Duplicated logic doesn't always mean double work. > I started this rant by saying if you don't abstract, you'll always be slow. Yes and my point is: if you think abstracting is always a net win, you're probably green and haven't seen the myriad cases where it bites you.