3 ms·

Let me give an example bad abstraction that isn't due to littered conditionals, but still very bad. One time company A had a database, and code that loaded per

by yafbum 3y ago

Let me give an example bad abstraction that isn't due to littered conditionals, but still very bad. One time company A had a database, and code that loaded persisted object state from them. Some of the objects could be soft deleted. Rather than check various objects for soft deletion, the team decided to check all objects for soft deletion, regardless of their type, by querying a table where objects had to be listed if they were still live (not soft deleted). Fast forward a few years, everybody follows this pattern, and there is massive hotspotting of that central "object lifetime" table that has basically two columns (object_id, is_deleted) that becomes a latency bottleneck because absolutely everything is joining on it all the time. Truth is, it made it convenient to code with this, because you never had two ways of checking whether an object was live, and by construction you could never make the mistake of operating on a soft deleted object or forgetting to implement lifecycle deletion. But man was that a poor abstraction. It was probably redundant with database functionality. It gave soft deletion capabilities even to things that didn't need soft deletion. It had a significant latency cost. But everybody adding a new object type just picked it because it was the way the company has decided it would do soft deletion.

harrisonjackson 3y ago
> Fast forward a few years Sounds like it was just what was needed at the time and worked better/longer than most abstractions.
- RandallBrown 3y ago
  > Sounds like it was just what was needed at the time The problem I've seen often in codebases is that as an abstraction or pattern grows more unwieldy, they don't take the time to update it. They often don't get revisited until they're so bad that they can't be ignored. Handling a something with a switch or if/else is fine if there's only 2 or 3 options, but people will often just keep piling on. When it's 10 things, changing it becomes much more work so people will continue to add to it. Then when it breaks at 20 things, someone will come in and say "Why did we write it this way in the first place? It doesn't make any sense!" I'm often torn between pragmatically writing the simplest code possible and being proactive about abstracting early to prevent an eventual breakdown of the pattern.
  - edgyquant 3y ago
    Why is a switch bad? Python uses a giant switch statement to run it’s opcodes
  - Pannoniae 3y ago
    How does a switch break at 20 items? Any respectable compiler or interpreter should handle that fine. If it was 32k cases, I could imagine why it would raise an error. But 20? Seriously? Often, writing more cases into a switch statement is way easier and less boiler-plate-y than abstracting it out to subclasses or a dictionary or whatever.
mannykannot 3y ago
I feel you are describing an implementation that was once fine but is no longer satisfactory, rather than an abstraction, which perhaps could have been made easier to fix with a bit more abstraction: a function to do the soft deletion if possible, with a better-performing (albeit probably more complex) way of determining whether soft deletion was an option.

by yafbum 3y ago

harrisonjackson 3y ago

> Fast forward a few years Sounds like it was just what was needed at the time and worked better/longer than most abstractions.

RandallBrown 3y ago
> Sounds like it was just what was needed at the time The problem I've seen often in codebases is that as an abstraction or pattern grows more unwieldy, they don't take the time to update it. They often don't get revisited until they're so bad that they can't be ignored. Handling a something with a switch or if/else is fine if there's only 2 or 3 options, but people will often just keep piling on. When it's 10 things, changing it becomes much more work so people will continue to add to it. Then when it breaks at 20 things, someone will come in and say "Why did we write it this way in the first place? It doesn't make any sense!" I'm often torn between pragmatically writing the simplest code possible and being proactive about abstracting early to prevent an eventual breakdown of the pattern.
- edgyquant 3y ago
  Why is a switch bad? Python uses a giant switch statement to run it’s opcodes
- Pannoniae 3y ago
  How does a switch break at 20 items? Any respectable compiler or interpreter should handle that fine. If it was 32k cases, I could imagine why it would raise an error. But 20? Seriously? Often, writing more cases into a switch statement is way easier and less boiler-plate-y than abstracting it out to subclasses or a dictionary or whatever.

mannykannot 3y ago

I feel you are describing an implementation that was once fine but is no longer satisfactory, rather than an abstraction, which perhaps could have been made easier to fix with a bit more abstraction: a function to do the soft deletion if possible, with a better-performing (albeit probably more complex) way of determining whether soft deletion was an option.