I think I can safely say that I speak for 95.6% of all frustrated Drupal professional out there when I tell new developers this:

STOP creating custom modules and proprietary solutions.

Just… stop it. For every proprietary project that goes and duplicates 96% of the work another proprietary project already created, there’s an open-source developer like me crying into her beer because of the horrible waste of human capital and interoperability this represents.

This isn’t just a Drupal problem, it’s an open-source problem, but I see it here because this is my world.

The problem? Programmers.

Don’t get me wrong: I work with programmers. I love programmers! But programmers love to program. That’s what they do. When you hire a programmer, nine times out of ten they do not carefully research possible solutions, find one that pretty-much-fits, implement it, and customize it using the tools the solution itself provides. That’s not what they trained to do in their university Computer Science classes! Nooo. They were trained to program. So they whip out their favourite text editor, they get up to their elbows in API, and they start writing code.

And then I get to spend a not-insignificant number of billable hours, after they’ve gone on their merry way, ripping out all that lovely hand-written custom module logic, exporting custom database tables, and re-implementing everything in basic out-of-the-box Drupal just so that a customer’s site can be upgraded and properly maintained.

I hate doing this. I really, really do.

One developer friend I work with joked “The client looked at the site and said ‘It looks exactly the same…’ and I was like ‘YES! ISN’T THAT AWESOME?’” The difference was invisible, but crucial: the first version (which she was hired to ‘maintain’) was hideously insecure and totally un-upgradable; the second version was done properly, and could be maintained going forward using standard Drupal tools and best-practices.

Unfortunately, clients do not care what goes on under the hood, they just want it to work, so this puts the new developer they hire to fix whatever goes wrong in a huge bind. Clients don’t really understand the fundamental difference between solutions — they just see line-items on an invoice, and they don’t get the open-source mentality of security-by-lots-of-eyes, or contributing-work-back-to-the-community. They just understand functionality. If it works, they pay.

This just encourages programmers who should really know better, and screws the people who have to clean up after them.

But all is not lost: clients are willing to listen. They don’t want to have to go back and re-do everything when they get hacked, or when they try to upgrade versions and find they can’t. But if we don’t educate them, they will naturally blame the software, not the developer. We can’t expect them to magically understand the amount of work that needs to go on just to make their site look and function identically to their old site because their programmer loved to program. They just get a bill, and blame Drupal.

Drupal doesn’t need this.

Now, sometimes, I realize, it’s necessary to implement proprietary stuff. Sometimes you’re working with weird, antiquated and cantankerous systems that just need a good smacking-down in the form of a custom module. Oh, yes, I have met those. But this is rare. I have seen so many custom implementations of modules already well-maintained on Drupal.org that I want to cry. My first question is always “Can you write a rule for that?” “Did you create an action?” “TRIGGERS!” “This is a CCK field, right?”

I once helped rip out an entire web store done with its own database tables; we were able to re-implement the whole thing using just CCK, Views and Ubercart. And I will never get those hours of my life back.

A more egregious example is this: one site I worked on had a lovely custom-LDAP module set up, to add users from the company’s LDAP directory and give them pre-defined Drupal roles. WAIT A MINUTE. THAT SOUNDS FAMILIAR.

Well, of course it does: there’s already an LDAP module! And it works out of the box. It’s not perfect (it needs some work on provisioning, for example, because of the way PHP pages results) but it is a Drupal-community-maintained module. If the developer had the time to create a whole new custom module, writing thousands (yes) of lines of code to do exactly the same thing as the LDAP module, why couldn’t she or he have just implemented the LDAP module and helped fix it up where it didn’t fit their needs — and contribute it back?

Well, he or she probably didn’t know about it, because they probably just cracked open a text editor and started coding.

In all cases where this happens, the open-source community loses the chance to have a great programmer working on a module or project that can use some TLC (not to talk smack about any particular module — all Drupal modules need TLC, all the time, and they all need people willing to test and patch, always! Because this is software we’re talking about.)

So, all new Drupal developers? DO NOT REINVENT THE WHEEL.

Feel free to add some sparkles, feel free to maybe put on a nice hub-cap or two, but stop making things that already almost exist. Search! Use some of those analytical skills to assess existing solutions! And, if you do create something and it seems useful, stop keeping it to yourself: this is a community, and we need your contributions. Try to generalize it, and then give it back. Use your amazing developer skills to do it the Drupal way.

The community will thank you, and so will I – the fewer sites I have to fix, the better.