The Pitfalls of Relying on One Drupal Developer

Stephen Sanzo // January 2013

In previous posts, like “Drupal is Not a Product” I have talked about some of the uniqueness of Drupal – what makes it great and what makes it…a bit challenging.  For us non-developer folks, sometimes the most unsettling part of managing a Drupal site revolves around the “Snowflake Phenomenon”.

So, you’re saying “Snowflake Phenomenon?!  He just made that up.”  Well yes…yes I did. Nonetheless, this Snowflake Phenomenon I am referring of (and you may have surmised) calls attention to the idea that no two Drupal sites are exactly alike. Obviously, I am not talking about the front-end stuff - but how the site is built, developed, structured, etc.

Because of Isovera’s work helping organizations with existing Drupal sites, I hear a lot of cautionary tales. Tales of fairly elaborate websites or systems that were developed by one developer. This person may have moved on or even disappeared when problems with the site arose. Often times, I am speaking with a marketing person who hired a creative agency to design the site who, in turn, hired a contract “Drupal guru” to build the site. Now, as with any operation within organization, when you have one person that has all the knowledge it can lead to problems. Add in a flexible, open source “snowflake” like Drupal and the problems could get bigger.

It should be noted that one unique thing about Drupal developers is that, in many cases, they view their work as creative. So, although many hopefully use development best practices, there are still myriad approaches to get the same result. Again, that snowflake concept.

This is where things differ a bit from the proprietary CMS like an Ektron or Sitecore. Because of each systems limited flexibility and standardized structure, someone else with knowledge of those systems can step in fairly easily.

How should these cautionary tales end?  The self-serving, marketing side of me says, “You need to hire a firm like Isovera with a team of Drupal developers who collaborate on site development and foster continued knowledge transfer.”

But, the main point to consider is really identifying the investment in your Drupal website as it relates to the value it brings to your organization. If the site and its inherent functionality contributes fairly significantly to your bottom line, than having one person as the sole keeper of its inner workings can be a recipe for disaster. 

So, if you are managing a Drupal site or plan to manage one, keep these ideas in mind when evaluating your resources and assessing the best fit for your organization.

Filed under: