Things I Love About Drupal

So its been about six months since I've been working with Drupal and about two since I really immersed myself into learning just about everything there is to know. Its been a mostly positive experience, but there has been some negative. This post will cover the positive aspects. Watch out for my next post where I go into some of the negatives.

1. Fairly well thought out module architecture
All other CMS platforms I've used have had some fatal flaw that made modules more difficult to deal with than they had to be. Drupal modules are self contained and physically reside in one place (I'm looking at you Joomla). Interdependencies are easy to declare and enforce within the module manager. I especially enjoy the loose coupling afforded by the module_load_include function. This avoids both the mess created by require_once and the inefficiency of loading every single file for every request.

2. Active community
One of the big draws of using open source for commercial projects is the downward pressure it puts on project costs. The less custom development we have to do, the more resources there are for us to provide value added services to our clients. Instead of wasting our time implementing a feature, for example, we spend it on finding more effective ways to market the site via social networks. The activeness and involvement of the community is what makes the difference here. There are few things you'll want to do in Drupal that someone else hasn't already thought of and provided a module for.

3. Commercial sponsorship
In my years of software development, I've been exposed to countless open source projects. One thing you quickly realize is that for every great project, there are at least three horrible ones. I've discovered that the most reliable indicator of the project quality is the level of commercial sponsorship. When you think about this, it makes sense though. I've been a software engineer for a long time and my most valuable lessons have all been learned while under fire, trying to meet real business requirements. No book or course will ever teach you these things. With the commercial sponsorship comes the developers that have been through similar things. They know what kinds of problems occur in real world environments and how to mitigate them. They understand that an hour of design planning and modeling are better than 20 hours of coding. I'm not saying all amateur coders are bad, only that they lack the experience that takes them to the next level.

4. CCK and Views
These two modules, while not without their faults, are probably the most valuable in the entire Drupal ecosystem. It used to be that the only way to add new functionality to a CMS was to develop new content types and all of the associated views. For all but the most simple cases, this involved a senior developer spending tens of hours hand coding the functionality. Hours more were spent on QA to ensure bug-free operations. With CCK, Views, and a few hours of training, these tasks can all be done by a junior developer or even a designer. This reduces the number of senior staff required for a project and correspondingly reduces the number required to be on staff.

While not everything I love about it, this list is a pretty good representation. All but one of these directly reduce the cost of developing new systems. Nothing is perfect though and Drupal is not without its issues. Next time, I'll cover some of the things that keep it from realizing its full potential.