Drupal's Golden Handcuffs

I worked with Drupal full time for a little over two years. I spent much of that time clicking around in config screens, and when I did have to get my hands dirty with some custom code, I usually felt like I was just stumbling around in the shadow of the behemoth that is Drupal's API. I thought, "Surely this isn't what web development's supposed to be."

Turns out I was right. On recommendation from a developer friend, I started experimenting with a bit Rails, tried a couple of "proper" PHP frameworks, and then discovered Python and its excellent web development ecosystem. That's when it really started to click for me—all these pieces that Drupal had so kindly obscured from me started falling in to place. Rather than trying to push around a monolith, I learned how to keep things lightweight and use only the pieces I needed. And importantly, I was actually writing code. Sweet, readable, maintainable, version-controllable code. None of this "serialize a hugely long options page and dump it all in the DB" stuff. (On a side note, learning git was another big catalyst for my move away from Drupal. D6 always felt like a pain to track in a VCS, especially when I was collaborating with another developer—though the situation may be improving.)

I should point out: I think a big part of my frustration was the fact that many of the sites I was building didn't need something as big as Drupal. I've since found WordPress to be a better fit for most of the "easy" stuff, or even static HTML/CSS if it makes sense for the project. When I'm building something more complex, well, there rarely seems to be any reason for me to use Drupal anymore.

The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites.

The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years is that Drupal's pluggability still makes it the most powerful tool for what most people use it for -- deploying websites.

I have often surveyed the landscape and thought, "why not just build this in another tool like Rails or Django" and I always come back to it in much the same way the author of this article does -- while those are much more beautiful development frameworks, they just don't have the mojo that Drupal does.

This is likely best illustrated by example. This may or may not be based on a true story ;) Let's say I develop a custom application to interact with my company's backend database products which, let's say, are for events management. Now I pass that custom application off to the site builders who will actually customize that application for each of our hundreds of clients.

(1) The client wants a Google map of all their events

(2) The client wants the Events displayed on a calendar

(3) The client wants Events to filter by Event type

(4) The client wants a tag cloud or something else totally unrelated to the Events system

Built in Rails (Total additional developer time to add these features: 400+ hours)

(1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component to convert the locations into actual location data (lat/long) and display it on a map. We need to interact with the Google Maps API and write the code that will communicate with them via an API key and handle everything.

(2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct, handle a bunch of special cases (what if there are too many events to display on a single day, some months have 4 rows of weeks, some have 5, etc.)

(3) Developer has to add a form element to take that event type and modify a query to enact that filtering and load the results on a new page. Not a ton of dev time, but dev time nonetheless.

(4) Cross fingers that there is a Ruby Gem for this. Otherwise damn, custom development.

Built in Drupal (Total additional developer time to add these features: 0 hours)

(1) We never heard back from the site builders because they installed the Drupal modules Views, GMap, Location, and were able to create the map themselves from our custom Event data and clicking on the right buttons

(2) Again, the developers never heard back from the site builders because they installed the Drupal modules Views, Calendar and were able to show those events on a calendar.

(3) No developer time because the site builder went into the Views settings and added an Exposed Filter

(4) Site builders install the cloud tag module or the random feature X module, custom developer time rarely needed.

Now let's scale it up, instead of 1 client you have 500 and each want slightly different things. One wants to filter by Event type, one wants to filter reverse chronologically by date. One wants a calendar with a month view, one wants a week view. One has a ton of events and wants a day view. With Drupal, these are all just settings on existing, already built modules. With Rails/Django/Node.js/etc. these all require more dev time. Now of course things could be designed intelligently and parameterized to limit some of the DRY, but there is still dev time required to implement all these different permutations or up front complicated system design to create an architecture that can be configured as richly as a Drupal module developed over years by a community.

I work in Drupal professionally, but play in Rails, Django, Node.js, even Meteor every chance I get because they're so fun and beautiful but at the end of the day I still think Drupal is the right tool for our job in spite of its long list of flaws including its base language, the always horrifying PHP. But it freaking works.

tl;dr This article rang more true than I could have imagined it would. Thanks mcrittenden!

Features and things like http://drupal.org/project/drush_make is what makes a lot of the drupal distributions (http://drupal.org/project/distributions) that keep popping up because sourced controlled, feature driven development is now possible in drupal.

Also the testing part has been improving, and although very few of the contrib modules have tests most of core has automatic testing in place for when you submit a patch as you can see in the issue queues (http://drupal.org/node/466576).

In the long run you can expect those extra hours contributing to the project to really pay off, because you gain a deeper understanding of where things go, because you meet people that can help you, because people see your contributions and you make connections and a lot of other goodies.