DRY? How about DRC: Don't Repeat the (Drupal) Community

After much (much) searching, I eventually did find the perfect module, Menu Trails.

However, in the midst of my search when I was ready to give up, I asked a colleague whether he had seen this kind of functionality in a module. He suggested Taxonomy Menu and when I said 'No, not quite what I'm trying to do,' he recommended making my own module. Rolling your own module is what this colleague frequently advocates.

Though this colleague has more Drupal experience, I still hesitated to take his recommendation on this because...

Rolling Your Own Module is for Suckers (Most of the Time)

—or—

Don't Repeat the (Drupal) Community

My general stance on creating custom modules for my work at the University is 'don't do it!' For the most part, our sites are fairly conventional... and since they are conventional, that means that someone has probably already come along and made the module with the functionality I need.

Don't get me wrong, I definitely see a point to all of us getting our hands dirty, contributing and improving modules (either through requests in the issue queue, submitting patches, or directly maintaining a module). However, sometimes when this DIY ethic is extended, it actually makes developers lazier and busier at the same time... instead of putting in the initial research into existing modules, it seems easier to just roll your own. But then, what is it they say about rolling your own?

Rolling your own module is kind of like rolling your own CMS, except worse in the fact that Drupal changes around you, regardless of what's going on in your sites and in your life. And when Drupal moves from v.6 to v.7 (and v.7 to v.8... and v.8 to v.9), if no one else has graciously offered to maintain your version of module X, you will be the one on the hook to port that module to the new version.

Not only is it more work for you, the developer, in the long run (or more work for your successor when you leave)... it also hurts the Drupal project.

This is a more controversial opinion as it may seem. As Jough says in his post to the thread about duplicate AWS modules, "There are two schools of thought regarding module suites such as what we're proposing. One says to keep each module small and Unix-like and have each one do a little thing, and the other (to which I think we both subscribe) says to group like things and make installation and maintenance simpler."

However, it seems like more and more of the core Drupal team are advocating the second school of thought over the first. There is, in fact, an entire group dedicated to pointing out where developers have duplicated each other's work. And, as DMan of the Agaric Collective says in his open letter in the duplicate modules hall of shame, "I think we should be encouraging these developers to merge efforts or voluntarily retire their modules in favor of more consistant solutions."

So instead of advocating rolling your own modules next time a colleague comes with a simple seeming problem, let us instead join forces and work towards a better, cleaner Drupal.