You are here

The first rule of coding for Drupal

Submitted by yelvington on January 9, 2010 - 10:19am

This is a message to prospective Drupal developers. I'm going to propose this as the First Rule of Coding for Drupal: We do not write code for Drupal.

I've been thinking about this for awhile, but what pushed me over the edge was Tom Davidson justifiably poking on the crew of exiles from a certain industry magazine, and his pointing to this Growthspur post that insists starting a local site "is easy and cheap (and don't let anyone tell you otherwise)."

Davidson and the Growthspur folks are 95% right. Start with easy and cheap. Get it done, and then (only then) face the hard and expensive. I'll discuss the other 5% down at the bottom of this post.

I've been using Drupal since 2005, beginning with a prototype for an experimental community site. Now it's at the core of the core of what we do at work: supporting our newspapers' efforts on the Web.

Over the years I've seen a parade of developers come through our organization, struggle with Drupal, learn about Drupal, and in many cases move on to work for consultancies on really huge projects like the White House website.

The consistent mistake that developers make is to plunge in with the intent of writing code.

We do not write code. That's a rule you should make with the expectation of breaking it, but with the intent of keeping it as much as you can.

If you're a developer with any fluency in PHP/MySQL/HTML/CSS, this is a hard rule to face. If you're new to Drupal and don't understand the vast landscape of contributed modules and themes (design packages), it's especially hard. You know your tools. You know how to get things done. So you reach for the comfortable and the familiar. Who minds if you're reinventing the wheel? It seems faster to just do it your way.

The hidden costs are huge. While you're reinventing the wheel, you're not moving on to the next problem. You're creating a stack of code that has to be maintained. You're writing bugs (everybody writes bugs) that have to be squashed. Even in something as "simple" as a site design, you could be creating hundreds, maybe thousands of lines of code that have to be painstakingly examined, upgraded and re-tested a year from now when the site moves to a new version of the core application. Are you documenting everything you do? What's the next guy going to think of your work?

There's another cost, though, and it's actually bigger. When you write bespoke tools, they tend to be built to do exactly what you're trying to accomplish.

That's not a good thing.

The Drupal module landscape has some amazing tools that are quite the opposite. CCK, Views, Imagecache, Nodequeue, Panels and several other contributed modules have become essential to tens of thousands of Drupal projects because they assume you're not really clear about what you're trying to do and you're likely to change your mind. Or your boss isn't clear, which is even more likely.

Real-world testing, iteration and course changes are far more likely to lead a business to success than ironclad central planning. If you're a developer, it might seem like "the boss doesn't know what he's doing." OK, that's one way to look at it. The truth is that none of us knows; we have some guesses, and we're trying to find out what we're doing. Working quickly, configuring off-the-shelf tools, is an important way to get there.

So you learn to use the application, rather than writing code. You recycle other people's work. You negotiate with your bosses and make compromises along the way in the interest of getting real-world results, and real-world learnings, quickly. And two things happen that are central to your work as a developer:

  1. You discover where the really hard 5% really is, rather than mistakenly thinking the majority of the project is coding. You will find something that really needs to be coded from scratch, and you'll be able to focus on it.
  2. From working with the generalized tools, you learn defensive design patterns -- ways to anticipate changes, to implement your bespoke code so it can be reconfigured on the fly without additional coding, and accommodate unexpected course changes.

Everything I'm saying here will come as no surprise to longtime Drupalistas. If you Google "Drupal hall of shame," the top result is a "Similar Module Review" discussion group focused on reviewing potential cases of reinventing the wheel. If you'd like to become a Hall of Famer, start out by staying out of the Hall of Shame. When you eventually apply for a CVS account to release your modules on Drupal.org and become a rising star in the Drupal firmament, you're going to face a brutal review of your application. Be prepared to explain why your work is unique.

I've been working recently on a Drupal project for a European media company -- currently on hold -- that refreshed my point or view on all of this. I can code, and in fact have a couple of modules I've released on drupal.org, but I'm not a programmer and expect to outsource some parts of the project. As I worked, I was struck by how quickly Drupal has evolved as a "no coding" platform. Things that seemed just out of reach a year ago are now point/click/configure. It's been said (by Dries? I can't find the reference) that Drupal isn't finished until it can wash your socks. Sock-washing is still in that hard 5% layer, but a lot of what you need to do is already done for you.

Comments

I agree, the Drupal development is breathtaking. I started a project - my very first, large Intranet development - in April last year, and many of my used modules have strongly evolved or have been published for the first time during that year. It also means, though, that checking out new and updated modules can be quite time-consuming, afais. We have a few custom developments, but most of our project is out of the box - okay, a rather large box by now, but still a box, and Views, CCK, OG and Panels definitely saved my life :)

Hi Steve. Was searching for a contact form but since this site doesn't have one (?) I'll put my message here in the comments. I've been thinking about this post for more than a month now. You definitely raise a valid point, but I do feel ambivalent about the suggestion that Drupal is great because it doesn't require coding. Drupal is not necessarily more maintainable just because it has so many contributed modules — I've had my fair share of grief because of great-looking modules that eventually lose their maintainers, forcing maintenance onto yourself anyway. And the opposite of the NIH-syndrome is that by using off-the-shelf components for just about anything, you're losing out on opportunities to provide something truly unique for your visitors. Even seemingly simple things like commenting or account registration provide opportunities to differentiate yourself from the competition. Building those things yourself forces you to think about even these mundane aspects of the site, and that's not a bad thing. Anyhow, to plug myself a bit, I've written some of my thoughts about Drupal down on my own blog. Maybe you'll find them interesting. Cheers, Stijn

Actually, Bèr, we may not disagree so much! The last rule in any chain should be "when necessary and appropriate, break these rules." At that point, the fact that Drupal is a development framework and not just an application can really pay off.

The problem is that many beginners don't bother to learn what's already available and instead reinvent the wheel badly. This is a major reason I think we should begin with an assumption that we do not write code and exhaust that avenue before proceeding to write any code. I'm all in favor of reinventing the wheel when the result is a significantly better wheel, but not when it's just another round thing.

This problem shows up at the top level but also in code that's written by beginners. Many who are prematurely diving into coding don't bother to learn the API. They reimplement drupal_http_request(), badly. They create tables when all they really need is variable_set()/variable_get(). They directly query MySQL using familiar interfaces. And so on. Just getting newcomers to use the forms API can be a struggle!

And it's also important to learn to participate -- to offer patches to existing modules when they fall short, to release your own projects and to pay attention to the resulting issue queue. Drupal's incredible growth in the last couple of years has brought us a wave of new talent, but often it's not providing the benefits to everyone that it could.

Correct: re-use whenever appropirate. But not at all costs. Not every listing must be build with a view: never forget the option to write a menu-callback, database query and simple template function. Often less then 20 minutes work, and easy to maintain (because these simple modules are dead easy to upgrade, for one). But for sure: if all you need is a blog-listing, by all means: use views. Or if all you need is a few blocks in complex pages, choose between context/spaces and panels. And if you just need a few additional fields on a simple blogentry: CCK is your friend. The only thing I see, is that, while building with these tools for a while, people seem to develop blind spots for the ease, and simplicity of a single small module. Only this morning I helped a Drupaleer, who had 80(!) modules to achieve some simple tasks. By writing his own template and by writing two small modules, he will bring this down to less then 10 modules. In total.