CivicActions

Working on Drupal core means that any change you contribute - even the most trivial tweak - is likely to go through multiple levels of review before being applied. Most contributors to core can expect delays of weeks, months, in some cases even years before a patch is accepted--if indeed it ever is accepted.

And even if a new feature you contribute to core goes in, you won't get to actually use it for months or years--the typical lag time until a new major version is ready for production use.

So it's no wonder many Drupal developers choose to work instead on contributed modules.

In contrib, if you're developing your own module, you've got a pretty free hand to do whatever you want. You can get a lot of functionality out there relatively quickly. And you won't have anyone breathing down your neck while you code. Want a new feature? Easy: code it up, press that metaphorical "commit" button, and you're set.

So end of story? Put in the occasional minor patch to core, but otherwise stick to the easy world of contrib?

Not quite. Because it turns out that the ease of contrib can also be its greatest pitfall.

You know the project issue status RTBC? "Reviewed and tested by the community"?

What a joke. I have to laugh every time I see that status on an issue on one of my modules.

Reviewed? Hardly. How often does anyone get anything like a meaningful review on a patch on one of their contrib modules? I've got about as many contrib modules as anyone--at any given time there's 40 or more modules that I've written and at least nominally maintain. And I can tell you, a well considered review is a very rare treat.

Tested? Not likely. Unless you call clicking around once or twice "testing". As for automated testing with the simpletest framework, well, really, who has time to write tests? Isn't coding enough work on its own?

And that's assuming there was an issue in the first place. Many contrib developers won't even bother opening one, but just go ahead and apply their changes directly. After all, we're the ones making the decisions. Why bother with the fuss of posting an issue if we're just going to commit the change anyway?

But it turns out that a free rein to post whatever you like with no peer review isn't always the Shangri-La it might at first seem.

There's the little detail of code quality.

That extensive code review that happens in core isn't just to make our lives difficult. Turns out that, surprise surprise, it's good for the code--and also for our own learning. Seldom are we going to get a solution right from the outset. It's the back and forth in the issue queue that can take a decent idea and make it shine. In particular, it can make sure the implementation is as soundly conceived as the desired functionality.

In most of contriblandia, functionality is king. Want feature X? Look no further! I'm all about feature X. And I can give you feature Y as well if you give me a few minutes. Presto!

And so it goes. Just how well feature X is implemented doesn't matter so much, does it? After all, who's going to know? Most of the people using the module will be looking for features, not some abstract coding standards. What do they care what's beneath the hood? As long as it "works", or at least mostly works, most of the time, they should be happy.

But does it work well? It may be a solution, but is it the right solution?

Does it take us forward? Is it something others can build off of or learn from? Even if it's sketchy and incomplete, is it at least reaching in a promising direction?

Does it reinvent areas of functionality that are already available elsewhere?

And if it's frankly the wrong solution, is it really worth writing, however much people may be demanding that coveted feature X?

For my part, I'm starting to develop a simple habit of thought to guide me through these questions. It could be summarized in a single question.

What would chx do?

Károly Négyesi, better known in the Drupal world as chx, is a tireless and endlessly creative contributor to Drupal core. There aren't many areas of core left that he hasn't helped shape, refine, and improve. And if there's a single criterion evident in all of Károly's work, it's that, if something's worth doing, it's worth doing well.

I know I'll never get much in the way of reviews for the contrib code I write. But that's no reason to be sloppy or cut corners. If I'm not going to get peer review, I have to be my own best critic.

Here are a few of the guidelines I'm trying to follow these days.

• Never apply a change just because it works. Don't be seduced by functionality. Focus first on the elegance of the implementation. If the implementation is right, the functionality will follow.
• Always post issues. Let others know what you're thinking. Invite critique. Hey, you never know, maybe someone will actually respond, stranger things have happened.
• Ruthlessly abstract. If it's a generic problem, make your solution generic enough to solve not only your own problem but anyone else's as well.
• By the same token, welcome the chance to use and enhance others' solutions. Introduce dependencies on API modules, and take the time to improve them if they don't fully meet your needs.

Part of the key is staying connected to core. As contrib developers, we have a lot to learn from and also to contribute to core development. Even if it can be frustratingly slow. Core issue queues and related discussions are places where we can connect, refine ideas, and create improvements. Improvements that we can bring back to our own work in contrib.

In short: whether in contrib or core, code as if chx, or catch, or webchick, or any of a select but growing group of high-level Drupal developers were reviewing every line you write.

A scary thought? Not really. Not nearly as scary as the thought of hundreds of modules being developed with little concept of code quality, elegance, or security.

And with that cheerful image, I think I'll return to the bug queue on my modules. Something tells me I've got a lot of them to get through before I should say too much more about elegance, quality, or testing.