This comment confuses me. If you're going to use Drupal as a framework and ignore the rest, then why not just use Django or Rails, both of which are cleaner and more sophisticated frameworks?

I don't think it's fair to look down on people who use Drupal as it's meant to be used.

I don't think it is fair to throw all Drupal developers into a bucket that has them rarely writing code and mostly just clicking around. We have a Drupal Role for people that only do what you describe. We call it Site Admin. They get access to all the clicky parts but don't do any actual programming. I'm never bored with Drupal. Frustrated yes... but never bored.

Drupal developer with 4+ years of working with it under my belt.

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!

At the risk of giving offense, I have to say some of your comments seem to be written in ignorance of Rails. This whole bit is surprising to me:

"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 ...

(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...

(3) Developer has to add a form element to take that event type...

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

The thing about a programming language that allows for meta-programming is how easy it makes it to stitch together the code you need from components. Ruby is very good in this regard, and also any Lisp would be good in this regard, and my new favorite is Clojure, which is exceedingly excellent in this regard.

I had worked with Rails in 2006, then taken a break from it, then came back to it. I just worked on a very big Rails project in 2011. One thing that surprised me was how little code I had to write. All of the functionality that we needed was in a gem, and we only had to write a few lines of code to customize the operation of each gem. Need to integrate events with a map? There is a gem for that. Need to add slugs to all articles and have them become the id that appears in the URL? There is for a gem for that. I would write maybe 10 or 20 lines of code for each gem, telling it how to interact with our application.

To be productive at Rails, you have to know what gems are out there. You need to keep up with the gems, because they really are central to the productivity boost you can get from Rails. There is a gem for almost any bit of functionality you need, you only have to know which gems are good. If you find yourself writing large amounts of custom code in Rails, then either you are truly tackling a novel problem that no one has ever dealt with before, or you are simply unaware of the gem that you should be using.

Your comments comparing Rails and Drupal surprises me. I feel like you are writing without realizing how Rails development is done.

> Your comments comparing Rails and Drupal surprises me. I feel like you are writing without realizing how Rails development is done.

First, no offense taken.

Next, I do have a fair amount of experience developing in Rails (it's my go-to hobby framework and I MUCH prefer developing in it to Drupal as I thought I imparted in my original comment) and yes, there are gems that get you most of the way there with some of the tasks I described, but our site builders (read: non-developers) are unfamiliar with the command line, could not generally install gems without intervention from developers and, if necessary, could not extend them without developer intervention. That is what I'm trying to describe.

With Drupal, people who interact only with a web browser can install rich components from a library of modules developed by others with integration with the Content Types (basically the equivalent of Rails Models in Drupal) with zero development.

Looking back at my original comment, arguably my time estimates for development were exaggerated to some extent and could be shortened with the use of gems, but the fact remains there is, at current, no way for users, through only a web browser, to enable that kind of rich functionality in Rails. That was the point I was trying to get across.

You don't have to write much code but you still have to write code. This makes it a non-starter for a particular class of user.

"To be productive at Rails, you have to know what gems are out there. You need to keep up with the gems, because they really are central to the productivity boost you can get from Rails. There is a gem for almost any bit of functionality you need, you only have to know which gems are good. If you find yourself writing large amounts of custom code in Rails, then either you are truly tackling a novel problem that no one has ever dealt with before, or you are simply unaware of the gem that you should be using."

This made me smile:

:%s/Rails/Drupal/g

:%s/gem/module/g

"To be productive at Drupal, you have to know what modules are out there. You need to keep up with the modules, because they really are central to the productivity boost you can get from Drupal. There is a module for almost any bit of functionality you need, you only have to know which modules are good. If you find yourself writing large amounts of custom code in Drupal, then either you are truly tackling a novel problem that no one has ever dealt with before, or you are simply unaware of the module that you should be using."

  > If you find yourself writing large amounts of custom 
  > code in Rails, then either you are truly tackling a 
  > novel problem that no one has ever dealt with before,
  > or you are simply unaware of the gem that you should
  > be using.

Sounds like Perl - or any other mature language, though I have never seen one with that many libraries for anything I could think about.

The language that has the libraries I need is always the one I end up using.

The problem with this approach is later on when the user wants things which don't fit in with the Drupal system, modifications can be a real pain, and the site can become more and more brittle over time. Let's take another real-world example:

1. The client wants a google map of all their content 2. The client wants the content displayed elsewhere too 3. The client wants to filter the content by type 4. The client wants a tag cloud 5. The client gets what they want quickly by using drupal and is happy. ... 99. The client wants to change the google maps module to act slightly differently, but this turns out to be very difficult, and their developer takes days to make very simple changes. 100. The client is complaining that their website is slow because it loads over 200 drupal modules, but they need them all. 101. Some code is the db, and some on disk, which makes it very difficult to trace execution. 102. The client can no longer update their drupal as half of their modules are no longer maintained, and they're at the mercy of the module developers to do so, this causes problems using new modules which expect a newer drupal. 103. New developers can't get up to speed because the code-base is so convoluted and the database contains over 200 tables with a byzantine structure caused by drupal's over-abstraction of content types - the client runs through a series of several drupal developers and bleeds money with no significant changes to their site and lots of bugs left unfixed. ... 200. The client gives up and starts again with a site rewrite using another framework, and curses the day they were introduced to drupal.

The up-front development cost may sometimes be lower with drupal (though for many sites I would dispute that, most frameworks make it a matter of minutes or at most hours work to add a tag cloud for example, or add a map, with the advantage that you don't have to use a module to do it), but unless you are very careful and stick with one developer, the huge technical debt you're taking on by using it doesn't justify that. The fact that the developers ever thought it was a good idea to store code and views in the db is a huge red flag, and is a huge temptation to some developers and/or clients to produce a huge complicated, unmaintainable mess. Even if you try to control this it doesn't ledn itself easily to separation of concerns.

I'm sure it's quite possible to produce clean websites with drupal and keep them under control long term, but it's not the pattern of the sites I've seen, and I don't think it really gives you so much more in the longer term over developing in simpler frameworks which don't try to prescribe as closely how the content is structured.

The same can be applied to Rails (let's compare to it) too: 1) You're at the mercy of the gem developers and Rails changes versions faster than Drupal, breaking backwards compability. 2) Number of gems also does have an influence on Rails app performance, at least on an app's startup time.

I started writing a response to this, but then it became its own blog post:

http://news.ycombinator.com/item?id=4607052

What would you recommend an experienced developer coming into Drupal do to land in group A?

Group A is guarded by a learning curve like the Swiss Alps. The only way to get past that is to get as much exposure as possible. There are already some excellent suggestions here so I won't rehash those, some other things you might consider:

Idle in #drupal and #drupal-support. Whenever an interesting question gets asked, go figure it out if you don't know the answer already.

Try tackling a few issues in the novice queues for D8. Not only will you get the kind of low-level exposure to how core really works that so many "Drupal developers" lack, you'll also get some nice bragging rights when your name's listed with the rest of the contributors.

The next time you encounter a limitation with a module you're using, in addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that cleanly extends the module to do what you want. Open an issue in the module's issue queue and submit your patch. Code review can be tough to take but stick with your issue until your patch is either accepted or the module maintainer closes the issue (won't fix, whatever).

Try landing a gig with Acquia or some other big Drupal shop. You'll get to work with (and learn from) some of the top talent in the community and you'll get the kind of exposure you can't get experimenting in your spare time.

If you're serious about going pro with Drupal development drop me a line. I may be able to help and would be happy to introduce you to others in the community.

I had a lot of difficulty finding good learning resources for developers. Most are aimed at non-programmers. I had quite a few questions answered on http://drupal.stackexchange.com/, which is a good starting point.

- Write a module with at least some UI to scratch an itch. - Then figure out how to contribute it to the community as a release on drupal.org.

Both parts of that process are equally valuable.

Try learning Drupal from a person first. A meetup or a Drupal camp are very good. A video is the fallback: Try NodeOne:

http://nodeone.se/sv/learning-library

or drupalize.me:

http://drupalize.me

Yes, and amen. All people who are afraid to write code need to stop using drupal.

There's a difference between beinf afraid to write code and avoiding reinventing the wheel. If there's a Drupal module that gives you what you need, why would you not use it?

A lot of the smaller drupal modules are unmaintained, buggy, or just plain don't work. Drupal advocates like to brag about the thousands of developers and modules in the ecosystem, but the truth is only the core modules and the most widely used contributed modules are production-worthy.

That, and even core-ish modules are maintained in a manner that's just plain unprofessional (I'm looking at you, Ubercart / Drupal Commerce): "Hey, there's a new version of Drupal Core! Let's drop development of (and support for) the current version of Ubercart that people are actually using and start writing a completely new cart system from scratch!"

it all depends. Example, if you want to assign a role to a new user when he signs up you can install http://drupal.org/project/autoassignrole module which does about 10 more things or just write one hook_user function.

If you install a module for every piece of functionality soon you'll end up with a huge codebase and the hell the author is describing.

You are responding to the author ;).

That said, I wholeheartedly agree.

Did Drupal dev for 2 years, and my biggest takeaway was: Don't go around installing custom modules for one dinky feature. Wrap it up in your own custom module.

Less dependency hell to deal with, and not only that, you'll have a much easier time debugging code you wrote yourself.