This post spurred an e-mail exchange with Giles. If I get his conclusions right, he’s ranting about the imminent en masse immigartion of framework coders over to Rails. In his opinion, a problem with the Rails culture. In my opinion, an inevitable side effect of being widespread.
You can tell a framework reached its tipping point when it’s talked about by skilled developers, but they’re outnumbered by framework coders.
Framework coders. You’ve seen them before. You walk by their desk and admire the hefty collection of development books stack on their shelves. They cover just about every topic worth of attention, from SQL to XML, from building Web pages to RIA, from language to protocols. Yet one thing tells them apart. Each time you walk by their desk, you notice these books are stacked nicely on the shelve. There’s only one book on their desk lying flat open to some random page. The Framework Book.
Framework coders are top to bottom problem solvers. When they have a problem to solve, they attack it by starting from the top of the stack. That framework book that’s open flat on their desk. Some framework start there before attacking their shelve for deeper answers. Some framework coders go so far as to place an embargo on all but The Framework Book.
In some respects, framework coders are just like every one else. We all have an infinite capacity for learning and retaining information. Where they differ is in the way they make up for that humane deficiency.
Let me tell you a secret. When I first started working with Ruby, all that meta-programming stuff just flew by me. I couldn’t understand exactly how class << self works, or how to use it properly. I didn’t even notice method_missing until way later. And to this day, I’m still confused on the difference between include and extend and how they affect constants.
So when it came time to speed things up and invent a little DSL, I had to pay the Pickaxe book a second read. And a third read. And some frequent visits since then. And that’s not the only example. I still refer to the SQL docs, the HTTP spec, lookup the finer points of HTML. I can only remember so much.
Of course, if I was a framework coder, none of that would happen. My first read through the Pickaxe book would be the last one. The week intensive learning of SQL would have been my last experience with it. What I learned once would carry me through the rest of my career, and I would never been the wiser.
Framework coders are efficient developers. You can’t say they’re not. They optimize their time by getting the code to just work. A framework coder would be content writing this:
Order.find(:all, :condition=>"closed").each { |order| order.destroy }
Efficient coding, one statement to remove not just the orders, but cascade and eliminate all the related dependencies from the database. It’s also a very wasteful use of CPU and I/O, performing N statements (deletes) over M tables (relations). But to know that you need to understand the resulting SQL and how databases work. And it’s not in The Framework Book.
Framework coders are bound by the framework. Truth be told, none of that would be a problem if the framework implemented an efficient cascading delete method. But frameworks are never perfect. The moment they get to do one thing for you, you’re already moving to bigger and more complex applications. A framework is never good enough, you always need more than it provides.
It’s no wonder framework coders flock towards frameworks that promise the one efficiency they care about most: writing less code. And it’s no surprise Rails is a major attraction for framework coders that bring with them their lack of skills and bad practices. Just like any other framework before it, just like the framework that saved them from developing those skills, that promoted those bad practices.
But there’s one point where I disagree with Giles. No framework will ever develop skills in those who refuse to learn and apply them. And no framework will promote the right choices in those who refuse to understand the consequences of their actions.
Framework coders do not understand the affects of their code. A good framework can give you the tools necessary to write efficient SQL, to use SQL wisely, to produce clean HTML. But that same framework will also let you write disk thrashing SQL, worse than binary XML, and GeoCity quality HTML. Frameworks do not distinguish between good and bad.
To choose one or the other, you need to understand the result of the choices you’re about to make. You need to describe the SQL, inspect the XML, qualify the HTML. You need to play judge to the results of your actions, you need to understand the bottom of the stack. It’s a dark place that framework coders refuse the enter. They just write code and hope for the best.
Framework coders are forever bound by the framework, forever using it to random effect. Frameworks come and go, but the unskills of the framework coder endures. Being critical of framework coders, teaches us nothing new about the framework, the language or the platform. All that matters is whether or not the framework helps you manifest the skills you already have, and plan to keep on developing.
Ewout ter Haar
Assaf
toolmantim
Nate Kohari
fromvega
Giles Bowkett
Franck
toretore
Bill de hOra