> Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that y

> Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. But that's exactly Joel's point. inside the scope of the abstraction, the following properties are true. The whole point is that outside the abstraction stuff breaks, and the kicker is that in many cases, the only practical way to know what is inside the abstraction and what is outside the abstraction is to know the details about the underlying abstraction, exactly what it was supposed to help with! Yes, cutting the network cable is a poor example, but there are many good ones. With C, you can do stupid bit manipulation in ways that will be non-portable across architectures. With ORMs, an easy example is the N+1 select problem. ORMs are typically very leaky, in the sense that to write good quality code, you have to know the details about how your ORM works, and they usually aren't a 100% replacement for knowing SQL. The more you have to know about how the level below you works, the more leaky the abstraction. I think Joel's could have made the point clearer if he had distinguished between how much typing the abstraction saves you, and how much knowledge it absolves you from knowing.