Yes great point! I even invoked that 2 days ago with respect to Kubernetes: the new abstractions over the OS leak, and they don’t compose with the old ones.
I think that term has reached the common parlance, so I almost forget it comes from Joel. But I do remember reading that article for the first time, and there were arguments about it!
Performance and security are typically the things that leak – they’re crosscutting concerns and don’t live in a particular part of the codebase. (Also related to O(n^2) bugs which tend to happen when you call “black box” functions in a loop without realizing they’re linear)
I will add this to the appendix at least, thanks :)
It’s probably just “right place at the right time,” but the first time I saw the Law of Leaky Abstractions article, I was still something of a beginner software dev, and was in that spot between “can write code that mostly works” and “can write something with a good API”.
I think about that article constantly, even today.
Performance and security are typically the things that leak
I’d say you’re lucky if it’s only performance and security that are leaking through the abstractions you’re working with. xD
Yup I read that article pretty much at the time I graduated from university and started working professionally with 100K+ line codebases.
We were definitely taught about the power of abstraction in school, and that is kind of the way my mind leaned. But instantly I had a name for the problems that (often premature) abstraction caused, and so did everyone else, because I remember seeing that phrase around a lot back then! And it’s still survived to the point that we don’t necessarily associate it with Joel.
I agree that many abstractions are “wrong” and you don’t even get to performance or security. But even if you get it “right” you still have those problems :)
The Unix way is more to keep things transparently simple than abstract them. Unix has some solid abstractions with processes and the file system, but they leak on purpose, like ioctl(), etc. Some things arguably were never fully abstracted (signals)
The “no rewrites” article didn’t age that well IMO. There’s a core of truth to it, but the way it’s interpreted now is oversimplified. I prefer John Millikan’s formulation: No Haunted Forests!
I really like this take on that adagium. The author discusses 6 examples of big rewrites, some of which went really well. As it turns out, there is more than one way to go about it.
Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity via Amazon.
Thanks, I fixed the link!
I don’t know… any “best of Joel Spolsky” list that doesn’t have The Law of Leaky Abstractions in it is suspect, IMO!
Yes great point! I even invoked that 2 days ago with respect to Kubernetes: the new abstractions over the OS leak, and they don’t compose with the old ones.
https://news.ycombinator.com/item?id=27910897
I think that term has reached the common parlance, so I almost forget it comes from Joel. But I do remember reading that article for the first time, and there were arguments about it!
Performance and security are typically the things that leak – they’re crosscutting concerns and don’t live in a particular part of the codebase. (Also related to O(n^2) bugs which tend to happen when you call “black box” functions in a loop without realizing they’re linear)
I will add this to the appendix at least, thanks :)
It’s probably just “right place at the right time,” but the first time I saw the Law of Leaky Abstractions article, I was still something of a beginner software dev, and was in that spot between “can write code that mostly works” and “can write something with a good API”.
I think about that article constantly, even today.
I’d say you’re lucky if it’s only performance and security that are leaking through the abstractions you’re working with. xD
Yup I read that article pretty much at the time I graduated from university and started working professionally with 100K+ line codebases.
We were definitely taught about the power of abstraction in school, and that is kind of the way my mind leaned. But instantly I had a name for the problems that (often premature) abstraction caused, and so did everyone else, because I remember seeing that phrase around a lot back then! And it’s still survived to the point that we don’t necessarily associate it with Joel.
I agree that many abstractions are “wrong” and you don’t even get to performance or security. But even if you get it “right” you still have those problems :)
The Unix way is more to keep things transparently simple than abstract them. Unix has some solid abstractions with processes and the file system, but they leak on purpose, like ioctl(), etc. Some things arguably were never fully abstracted (signals)
The “no rewrites” article didn’t age that well IMO. There’s a core of truth to it, but the way it’s interpreted now is oversimplified. I prefer John Millikan’s formulation: No Haunted Forests!
I really like this take on that adagium. The author discusses 6 examples of big rewrites, some of which went really well. As it turns out, there is more than one way to go about it.