Yes, in sum, but bad ones increase it, and it's not always immediately obvious to everyone that an abstraction is bad. A lot of that comes from experience.
> The minute I have any duplicated logic it gets combined as much as possible. I hate duplicating anything. Some duplication is impossible to avoid and I hate that too. I hate specifying the same logic in 2 places (say client-side and server-side for web validation). I will do anything possible to avoid that.
Good for you Glenn Coco! Work in any scaled software organization and you'll see that combining logic too early is full of hazard.
> I almost always build things out as a library ... This is always more work initially but has never failed to be right choice.
Maybe to you. I wonder if someone who's ever tried to use your library down the line ever thought "this was abstracted in a really suboptimal way but I have to live with it." Even if they did, I don't think you'd know. I've been that person too many times. People have got to stop building shitty libraries when they're not necessary and only serve to obfuscate the logic.
You argument just boils down to bad programmers writing bad code. It has nothing to do with abstraction or not. You'd be just as unhappy with an entire project that's just one grant 20,000 line file.
That's why I think the whole rant about abstraction is pointing fingers in the wrong place. 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. If you have experience, use abstraction to accelerate your development.
> Work in any scaled software organization and you'll see that combining logic too early is full of hazard.
Don't combine logic and you need twice as many programmers to do the work. That front-end guy to do the JavaScript for the validation, the backend guy to do the server validation, the project manager to ensure they're both always the same. I started this rant by saying if you don't abstract, you'll always be slow. And I stand by that; many projects with dozens of programmers are just manually performing work that could be abstracted away at the start.
> 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.
I'm anything but green. And I have, of course, made all these mistakes over my career. But if you're capable of running in 5th gear, don't take advice that says stay in 1st until you've finished the product.
Yes, in sum, but bad ones increase it, and it's not always immediately obvious to everyone that an abstraction is bad. A lot of that comes from experience.
> The minute I have any duplicated logic it gets combined as much as possible. I hate duplicating anything. Some duplication is impossible to avoid and I hate that too. I hate specifying the same logic in 2 places (say client-side and server-side for web validation). I will do anything possible to avoid that.
Good for you Glenn Coco! Work in any scaled software organization and you'll see that combining logic too early is full of hazard.
> I almost always build things out as a library ... This is always more work initially but has never failed to be right choice.
Maybe to you. I wonder if someone who's ever tried to use your library down the line ever thought "this was abstracted in a really suboptimal way but I have to live with it." Even if they did, I don't think you'd know. I've been that person too many times. People have got to stop building shitty libraries when they're not necessary and only serve to obfuscate the logic.