3 ms·

Okay Mr. English, trivial may be defined as unimportant / trifling but if you're gonna label something like that then you have you consider why you're calling i

Okay Mr. English, trivial may be defined as unimportant / trifling but if you're gonna label something like that then you have you consider why you're calling it unimportant. Still seems you're saying it's cheap, easy, and undoable. It's not. Abstraction building is _consequential_. > If you don't do that first "one go" how do get around to right abstraction? Right back at you: how do you get the data about how to build your abstraction without first living without one to understand what parts of the system should be abstracted? Starting with the abstraction and assuming you can fix it later is a luxury for overstaffed teams and people working on systems that nobody actually uses. You do realize, abstractions incur mental load on your users? Have you ever tried to use internal tools built ostensibly for your use case, only to find that it's taking more time and effort than if you lived without one? It's happened to me so many times, and the consequence of adopting a shitty abstraction has burned me so many times personally that I'm gravely aware of the downsides. Consider a streaming data tool that stupidly allowed users to put arbitrary data in a string field, which became abused for purposes it shouldn't have been used for -- now it's critical to the company and would take a YEAR of dev resources to retire, all the while being an endless source of headache and P0 SRE escalations. Consider an ML evaluation tool that requires you to understand how a bunch of leaky abstractions nest together. When you finally figure out how it works and it does 1 thing for you (generate P/R curves), it becomes extremely difficult to modify or debug without again understanding these horrible abstractions. Once you've spent a full quarter adopting it, you wish your team had just written something custom-but-maintainble instead of trying to get shoehorned into a tool that clearly wasn't thinking about you, and whose owners have left the company leaving you to absorb the cost. > But doing no abstraction is just as painful -- you just pay for it differently. It's less painful in the long run: doing no abstraction to start is often the right path. People often overrate the benefits of abstraction and underrate the clarity of repetition, especially when the repetition is trivial.

wvenable 3y ago
> how do you get the data about how to build your abstraction without first living without one to understand what parts of the system should be abstracted? 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 abstractions reduce mental load. I wouldn't be able to manage 20+ different applications if they didn't share a huge amount of common internal framework and have as a little duplication of logic as possible. I'm actually pretty militant about ensuring every abstraction is a programmer benefit and will remove layers if they serve no purpose. I almost always build things out as a library. If we are consuming an external service, I will make that it's own library/framework to be consumed by the project it interacts with. Even if it's only ever used by one project. This is always more work initially but has never failed to be right choice.
- kajecounterhack 3y ago
  > Good abstractions reduce mental load. 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.
  - wvenable 3y ago
    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.
    - kajecounterhack 3y ago

wvenable 3y ago

> how do you get the data about how to build your abstraction without first living without one to understand what parts of the system should be abstracted? 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 abstractions reduce mental load. I wouldn't be able to manage 20+ different applications if they didn't share a huge amount of common internal framework and have as a little duplication of logic as possible. I'm actually pretty militant about ensuring every abstraction is a programmer benefit and will remove layers if they serve no purpose. I almost always build things out as a library. If we are consuming an external service, I will make that it's own library/framework to be consumed by the project it interacts with. Even if it's only ever used by one project. This is always more work initially but has never failed to be right choice.

kajecounterhack 3y ago
> Good abstractions reduce mental load. 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.
- wvenable 3y ago
  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.
  - kajecounterhack 3y ago