Leaky abstractions

I'm really not one to get deep into computer science as a topic of frequent discussion. Experience, practice and mentoring tend to teach you all of the computer science that matters for the purpose of building supportable and maintainable software.

But I always liked the term "leaky abstraction," because it sounds more like a personal problem than a computer science thing. In basic terms, it refers to the idea that abstractions that are intended to hide away complexity often have cracks in them that do require you to know something about the underlying implementation. That makes them a whole lot less useful. I would also argue that a lot of abstractions just replace one kind of complexity with another.

The example I never stop running into involves ORM (object-relational mapping) frameworks. I think I've now encountered four of them in the last four years as part of various projects. They all have their pros and cons, and they're all excellent for the purpose of rapidly banging out something functional. They also get to be a pain in the ass as soon as you need to do something complex with them. If you have to examine the underlying SQL, and then mess with the framework to produce the "right" SQL, what's the point?

I think I've reached a zen place, however, where I'm willing to accept that all abstractions are leaky to some degree, and that's OK. Now I know to use the abstraction to my advantage as much as I can, and let it go and do things the "hard" way if it's going to be easier than beating the abstraction into submission.