Recommended Reading: "The Law of Leaky Abstractions" by Joel Spolsky

If you've written any software before, you're likely familiar with the concept of abstraction. It's what allows us to avoid thinking about the literal electrons flowing through semiconductors, but there's a cost outlined in Joel Spolsky's "The Law of Leaky Abstractions." I hope you'll take a moment with me to learn about it! Article Summary I know I usually kick each of these articles off with how I found them, but I've actually known about this piece for a while. It's a regular fixture in a software course I teach about abstraction (more on that later). Ultimately, my best guess is that this was either recommended to me, or I found it organically while looking for thoughts on the concept of abstraction. In other words, let's just get into the summary! Joel's article is pretty short. The whole premise is this idea that abstractions don't completely strip away what's underneath. He does this by centering most of the piece around the concept of TCP, a reliable network protocol that wraps the unreliable IP. TCP promises that you will get your complete data in order, but it can't actually promise that. As Joel says, if you cut the network cable, TCP can't do anything about that. Joel dubs this (i.e., the idea that abstractions sometimes fail) the "Law of Leaky Abstractions." And in addition to demonstrating this through TCP, he shares several examples, such as: Iterating over a 2D array by rows vs. columns Running logically equivalent SQL queries Using remote files as if they're local Concatenating string literals in C++ Driving a car in the rain All of these examples are meant to show how the underlying implementation details "leak." The punchline being that abstractions don't completely simplify our lives as much as we would like. And from an education perspective, Joel argues that abstraction makes it very hard to teach students because if anything leaks, the student "will not have the vaguest idea what happened or how to debug it and recover from it." In other words, as software becomes more abstract, it becomes harder for people to become proficient. Why I Like This Article You know, I used to really like this article because it pushes back on this idea that abstraction is inherently good. In fact, in my software development class, I am expected to teach students about abstraction, and it's generally framed as a universal positive. I often push back on this material by sharing Joel's article. However, having read the piece again to craft the previous summary, I see Joel's argument in a new light. After all, the piece is 24 years old. I was literally an 8-year-old when it was published. Yet, it seems to fit right in with the kinds of arguments I've been making for a while. Either when I've ranted that IDEs do too much for beginners or when I've ranted that LLMs shouldn't have a place in education. We're talking about abstractions that have robbed new developers of being able to actually understand the tools they're using and the systems they're building. Because of this, there are several nuggets near the end of the piece that speak to me on a spiritual level, such as: "[...] if the programmer doesn’t understand what ASP.NET was abstracting away, they simply won’t have any clue what is wrong." "The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.”" "So the abstractions save us time working, but they don’t save us time learning." "And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder." "And while these great tools, like modern OO forms-based languages, let us get a lot of work done incredibly quickly, suddenly one day we need to figure out a problem where the abstraction leaked, and it takes 2 weeks." "And when you need to hire a programmer to do mostly VB programming, it’s not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks." So, while I initially meant to write about how much this piece does for me in the classroom, I'm realizing now that the magic of the piece is in its prophecy. For me, the article completely explains my personal journey as a developer. After all, I've skipped over so many opportunities to learn something new, such as when I tried to build a library application for my wife. There is/was just too much I didn't understand, and it didn't matter how many framework tutorials I followed. Now, I'm realizing it's because I didn't have the prerequisite skills. Those frameworks duped me into a false sense of understanding until I got stuck. I suspect this kind of thing must happen a lot to newer developers. I was lucky enough to pick up code in 2012, ten years after Joel wrote this piece, when tools were less forgiving—though they were heavily abstracted even then. Imagine what it must be like to learn how to code with LLM code completion turned on by default. This kind of stuff scares me in the age of slop because now anyone can produce a prototype of anything without really understanding anything. Sure, maybe the leaky abstraction issue is gone because you can simply prompt your way out of a hole, but isn't that just massively kicking the can down the road? If no one understands what they're doing, how is that sustainable? We're talking about evaporating expertise in a generation. Food for thought, I guess. Any Recommendations As you can probably see from this series growing, I've gotten into reading lately. I feel like social media and short-form content have totally fried my brain, so I'm trying to slow down by reading. Plus, I like being a good role model for my kids, so I might as well practice what I preach. As a result, if you found this article interesting and you want to see me react to something else, feel free to share something for me to read. In the meantime, I'll share a few more pieces with you. At this point in time, I think this series is still pretty short, but you might get some value out of my following recommendations: Recommended Reading: “Tech Bullshit Explained: Uncle Bob” by Melissa McEwen Recommended Reading: “Some Final Thoughts on the SAT and ACT” by Jon Boeckenstedt Recommended Reading: "To teach in the time of ChatGPT is to know pain" by Scott K. Johnson Likewise, your support goes a long way to keeping this site up, so please head over to my ways to grow the site. Otherwise, see you next time.