Bad Abstractions

We all like abstractions. We use them every day to make sense of the world. Sometimes those abstractions can be useful, like saying “hey, if we have interchangeable parts, our factories are more efficient”. However, we have to be careful, as history is littered with bad abstractions and “just so” stories to explain the world that led to horrible things. Many other abstractions just lead to dead ends and mediocrity. In technology, everything sits on a pile of abstractions, whether you are talking about the application server level, or are writing assembler code to work directly with a processor. We either stand on the shoulders of giants or we don’t stand at all. And therein lies the problem. Because we all rather quickly recognize the value of abstraction, we all have a pretty strong bias towards building them. While this instinct can be useful, it really needs to be moderated to some degree by careful thought, as not every abstraction is reasonable, especially once you stack them together. We often hear about the perils of premature optimization and how wasteful and destructive it can be, but people often miss out on how abstraction is a subset of optimization. In this case, abstraction is an optimization of the time and attention it takes to get something done in code. If you’ve been around the block a few times, you probably have worked on at least one codebase where someone got a little “happy” with abstracting things. If you’ve been around the block a few times and don’t remember this problem, you may have been the source, btw.. Nevertheless, bad abstractions can double or triple the amount of time that is required for even simple tasks, and can also foster disagreements among staff members (especially if the person who wrote the abstraction is still there and still proud of it). Bad abstractions are like personality defects in that they also accumulate piles of other abstractions to deal with them. Good abstractions are required in software development. Literally none of this stuff would be possible without abstractions. We should all strive to create more abstractions that actually work. However, it can be tempting to create abstractions for things you don’t fully understand, things that are likely to change, or to simply create abstractions because “it’s better practice”. But you really need to reign back that impulse sometimes. An abstraction is like a character in a story, no matter how much you like it, it can ruin the whole thing if shouldn’t be there. Bad abstractions when left alone, will often accrete bad code around them, simply as a way to try to fix them. You need to be able to either catch yourself before you write a bad abstraction, or you need to be able to identify them after the fact and have the will to remove them. Episode Breakdown Abstracting for “What we’re gonna need” Predicting the future is harder than you think – if you were that good at it, you’d own the tech company rather than work there. Say you are building a tool for pulling content from twitter. Do you abstract immediately because you think you’ll do the same soon for Instagram, Tiktok, Facebook, Youtube, etc.? This would be a premature abstraction. Those sites have different kinds of content, different kinds of rules around the content, and fairly disparate APIs. And you don’t even know if you are going to need it in the first place. If you start out with an abstraction, you make your twitter integration harder, and you either spend a lot of time in design, or your design has to be reworked when you add one of the others. Abstracting for similar things that have a high chance of later divergence This one comes down to predicting the future as well. However, this time, you have two disparate,