I’ve worked as a Drupal developer for a few organizations, and there are two in particular that I would characterize as polar opposites in their approach to custom code. The first was a “content marketing” agency I’ll call “Bloggers Inc”. At Bloggers Inc, custom code was encouraged and preferred. The other was (and still is) a US government agency I’ll call “Government Agency”. Observing the stark contrast between these two organizations has really got me thinking about the question of when it is appropriate to write custom Drupal code.
“Custom or contrib?” It’s one of the more common problems that I’ve faced over and over as a Drupal developer. Given a new feature request, should I implement it with custom code or try to find a contrib module that will work? It’s not as easy to solve as you might think, and it gets harder the more comfortable you get with custom code. For many, if not most feature requests, it may actually be faster to custom code something from scratch than to try to use a contrib module. But there are a lot more considerations than just speed of implementation.
One big one is the “hand-off” factor. At Bloggers Inc, we developed sites for ourselves to use. As a developer, my “clients” were co-workers within the agency, aka the content folks. In other words, there were never any hand-offs. We kept our sites from cradle to grave. At Government Agency, on the other hand, I maintain one site only. This site has been around since before I started, and will be around long after I leave. The same goes for the next developer to get the job, and the next after that, etc. In other words, there will be plenty of hand-offs at Government Agency. Consequently, as you might expect, custom code is a much bigger problem at Government Agency than it was at Bloggers Inc.
Another factor is the strictness of the requirements. At Bloggers Inc, each site was expected to be a pixel-perfect match for unique designs that were put together by designers who knew very little about Drupal. Contributed modules were rarely flexible enough to fit these ultra-specific requirements out-of-the-box, and so inevitably custom code was necessary. At Government Agency, on the other hand, feature requests are rarely more than 2 or 3 sentences, and almost never involve mock-ups. Consequently, contributed modules can usually meet the requirements well enough, and clients rarely quibble about visual details.
At Bloggers Inc, each site was a brand new creation, with usually little more than 10 or 20 pages. This allowed a great deal of thought and detail to go into each page, resulting in a largely over-engineered site where uniqueness and innovation were priority number one. Drupal’s contributed modules were frequently too ordinary and generic for the designers’ tastes. On the other hand, at Government Agency, the site is a massive accumulation of many years of legacy content, where consistency, accuracy, and compliance are the major criteria for success. Consequently, the generic nature of contrib modules is frequently exactly what the site administrators are looking for.
As is probably clear, on the Custom Code Tolerance Spectrum, I’ve worked at a 0 (“avoid custom code like the plague!”) and a 100 (“custom code all the things!”). I’ve already detailed some of the key differences that I think contributed to these differences of culture and policy. In future posts, I’ll delve more into these differences, and give guidelines for walking the custom/contrib line.