THINKDROP

Open Source Consulting

Adopting the Drupal Culture

We are Drupal architects and engineers that help organizations that are adopting Drupal. We believe that a dev shop transitioning to Drupal needs more than technical training, but also help with development and management strategy, site and data architecture, and server infrastructure.

As Drupal's popularity grows by leaps and bounds, web companies of all kinds are forced to adopt it. Sales teams find it incredibly easy to sell Drupal, because of all the things it offers, and all "for free". The problem is, Drupal is more than a piece of software. It is also more than the community. It is an entire culture

Drupal is really a culture. That culture is the code, plus the community, the leaders, the social network. It is also how we work: the behaviors, the methods, the madness of being a Drupal developer. Learned over years, these work habits, the Drupal idiosyncrasies, the RSS feeds you read, knowing where to get help, IRC etiquette, the ability to interpret a module from source, the ability to find patches and understand the module release process...

All of this is the Drupal Culture. Individuals may try to adopt the Drupal culture, but if their organization doesn't, they will never fully adapt. If your organization wishes to use the Drupal software but not adopt the Drupal culture, then there is a good chance the projects and teams will fail.

Being familiar with the entire culture of Drupal is what makes a good Drupal developer. If you are from another culture, being forced into the Drupal culture can intimidating, scary, frustrating, and can result in feelings of absolute despair. This is a real problem. We have all seen people quit, I have seen companies lose their entire engineering staff in the middle of projects. We have all seen budgets and deadlines explode and disappear.

I truly believe that most of the struggles of major Drupal projects result in focusing too much on the code and not enough on the culture of being a good Drupal development team.

Before ThinkDrop, as a freelancer, I was hired and dropped into huge companies where everyone was learning Drupal the hard way. Many times, I was the only one left on the project who really knew Drupal, even at a technical level. I found myself having to train everyone, not just on how to piece together PHP, but on the way to think like someone from the Drupal culture: from developers to managers, designer, and stakeholders.

The main problem is re-training. Expert web designers and developers, forced to learn Drupal, are forced to become novices once again. Drupal can actually destroy good web development teams as they are often forced to transition. Just like being involuntarily immersed in a new culture, if you force an expert in another field to learn Drupal, without support and time given for exploration and learning, that expert will feel inferior and underused.

It is a very hard thing to, after years of being at the top of your game, to admit, "I don't know what I am doing". It happens all the time when people have to switch technologies.

This can often spiral out of control, affecting managers and stakeholders, because you cannot manage expectations or make estimates on a technology you do not know. Developers need to feel they are safe in their jobs to say "We don't know." or "We need help."

You can't treat a Drupal project like a traditional web project. You can't use the same strategies, tools, timelines, or technologies as most web people are used to using. Drupal is more than a CMS or a platform or even a language, Drupal is a culture, and if you don't know that culture you will have a hard time fitting in. This is more important for the organization than it is for the individual developer.

As a community, we have to do more to allow experts in other fields to transition to becoming Drupal experts. Our documentation should not be geared only towards newbies, but towards experienced programmers and designers from anywhere, as well as business owners.

A company that wants to use Drupal, must adopt some of its culture to succeed.

Comments

Thanks for this nice article Jon.

Two questions.

1) Do you think that's really different from any other large platform? Certainly developing C code for Linux vs. Windows is going to be a major culture shock either direction. I don't even know what a "traditional web project" is. :-)

2) With the embrace of more conventional libraries (Symfony) and styles (OOP) in Drupal 8, do you see that culture shock getting any easier?

Great questions!

While transitioning from one programming language to another is always a challenge, I think the differences beyond the code are what we need to appreciate, because they take more getting used to.

Drupal has always been ahead of the curve, on many levels. I think there are similar struggles when switching programming languages, but I have seen the challenges of people adopting Drupal under pressure (meaning, at their job, usually with a big client waiting for results. This just happens to be my experience).

What makes the Drupal Culture stand out above the rest is the nature of the Drupal codebase itself (modularity, themability), the tools built to facilitate development (drupal.org, issue queues, free module hosting and release system, the IRC bot, the Project* modules, automated testing), and the philosophy (and the actualization) of a strong community (Centralized module development, cheap DrupalCons, Camps, and meetups globally, a supportive association).

All of these things combine to form a more tightly knit community, a stronger core & contrib development team, and an entire economy of Drupal-only businesses. You simply don't see that with many software projects, and if you do, its nowhere near the scale we have achieved. We use it every day, so its easy to forget what life was like without all of these tools.

No matter where you come from, there is a lot to learn about how to use the Drupal community properly, how to look for solutions to problems you have with a broken module, how to figure out what's wrong, how to appropriately and politely ask for help and work with module authors... I consider all of that a part of the Drupal Culture.

My background is mostly in helping design people and agencies move up from HTML & CSS with maybe some experience in "dynamic, database driven" websites. My perspective is that a "traditional web project" is mostly design work, then HTML & CSS, and the more technical parts are usually an afterthought. More and more big design "web" and "interactive" agencies and people are starting Drupal projects before they have a team that has adopted the Drupal culture, and they find themselves seriously behind because they started the process using traditional strategies, without realized how great Drupal's potential is.

It's like when the front-end team puts the Google Analytics <script&rt; tag in page.tpl.php instead of using the module. They just don't know yet how much better life can be in Drupal.

Last year sometime I was talking to a new lead in the .NET department of a company that also has a pretty strong (and separate) Drupal team. I brought up some module that totally handles some feature idea he had. He asked how much it cost.

When you are just getting starting, learning the "Drupal" code, the community, the methods, and strategies all at once is tough enough. Force people who are great designers or programmers to switch to Drupal, without everyone learning about the entire culture of Drupal can be self-destructive.

And for 2)

Adding Symfony libraries and patterns will reduce the code shock for users familiar with Symfony.

I think building a relationship with the Symfony culture will improve the culture shock situation by being the motivating force behind finally fixing our poor documentation and online training materials. We will be seeing a great influx of good programmers who will hopefully not be shy in pointing out where something may not be clear.

The chaotic nature of the Drupal handbook system is a big barrier to entry for new users of any level of experience.

Add new comment

By submitting this form, you accept the Mollom privacy policy.