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