Ian’s point, which perhaps got obscured in my response is your whole team needs to be able to drill down past the abstractions. Because you’ll need to in order to reach your next scaling plateau. (which is sometimes growth and sometimes recovering from down time)

The danger of introducing excessive abstractions is it creates mental boundaries that have a cost to cross. Additionally the abstraction you build in to your app will be necessity be less battle tested then say a filesystem.

And I do dislike ORMs. I would love an object-ROW-mapper, but the attempts to write SQL/manage the relational model have always failed in the domains where I have experience.

I have, however, been programming for the greater part of my life. When I first read “So true! Abstractions kill.” (in regards to things like ORM), I pumped my fist in the air. Then I thought, wait… abstractions are our sharpest tool. Yes they can kill, but they can also create. Just like a chef’s knife, they are dangerous, but without them we’d still be flipping switches on the front of our analog computers.

The trick is to find the correct (or least-incorrect) abstractions that provide the best balance between computer inefficiency and coder efficiency. As computers have increased in speed and complexity, the slider has been moving more and more towards insulating the human operator, and allowing more and more expressiveness.

That’s where the rub lies. All abstractions, by their nature, are “leaky” (the map is not the territory, etc). And scale is where those leaks can (and usually do) become a problem. If you’ve made your abstraction so rigid that you can’t bypass it to get “closer to the metal”, you’re going to get hurt.

I don’t have a problem with “ORM”s per-se (at least how they’re implemented in popular frameworks – they’re not conceptually pure ORMs). What they do encourage is the encapsulation of business logic in a single place. What I do have a problem with is an ORM that doesn’t let you drop down directly to SQL when necessary. Careful violation of abstractions is key.

We can’t hold a lot in our heads at once. Anything that helps us “chunk down” the huge amounts of information we deal with will help us get stuff done faster. If you end up with a good system or a bad one is determined in large part by the architect of said system – if they had discipline and a strong vision, chances are good that you’ll be able to evolve it in a sane matter.

This is getting very far afield of your post… The “new” thing is the web scaling, the not-new thing is making it possible to communicate with yourself and others through code.

Programming is communicating with machines Coding is communicating with people