LEMON: Drupal Diseases and Cures (Part 1)

Lemon tree

I've worked on many "Site Rescue" jobs, in which a client comes with a sick, but often brand-new and expensive Drupal site, desperately needing it fixed in a number of ways. Through this work I've seen a lot of patterns of "worst practices" employed. I enjoy the challenge of this cleanup work, while feeling bad for the clients who have been taken by incompetent vendors. I refer to these sites as "lemons" and I've made a study of their characteristics. This post starts a series based on my presentation of the same name. See also the video or slides.

Definition

A Drupal site should be considered a lemon if it would be cheaper to rebuild it from scratch than to fully fix it. One way to tell if a site is a lemon is to put the code in front of an experienced Drupal developer: if she laughs and cries at the same time, or exceeds five WTFs per minute, you probably have a lemon. If you have a lemon, a small change is always a big project and interactions with the site consistently involve frustration.

Prevalance

Drupal lemons appear to be very common. Part of the problem must be the immaturity of the field (both Drupal and web development in general). There is a lack of experts and a steep learning curve. The difficulty of the field of web development itself may be underappreciated by decision-makers. The ease of using Drupal or performing basic site building may stand in confusing contrast to the complexity of custom application development. It is difficult for non-technical decision-makers to assess the credentials of potential developers (open source provides a completely transparent and inscrutable system for doing so). In some cases, a decent team may be selected, but a client's timeline or budget is out of proportion to their demands, and a novice team may allow themselves to be pushed into delivering a poor product.

But Drupal has a kind of special talent for delivering lemons (which is also one of its greatest strengths): Drupal's flexibility and ease of site-building sets a low barrier to the ability to completely mess up a site in so many different ways.

Pathology

By studying worst practices, we can desire and create best practices. For there could be no best practice until the discovery of the worst. This is our lemonade.

A lemon is always rushed and/or foolishly designed. It lacks quality on many levels, so that the more you look the more you see problems.

Quality is a major focus of my work, which is why the lack of it shocks me. Before coming to the web I worked as a QA/QC (analytical) chemist in pharmaceuticals. As a tightly regulated industry we had strict quality procedures, far beyond what we see (or necessarily want) in web development. With this background, the lack of focus on quality in many expensive web projects amazes me.

There is a difference between QA (Quality Assurance) and QC (Quality Control). Quality Assurance includes all the processes designed to ensure quality, including source code control, code review, automated testing, and release management. Quality Control is a review of the final quality of a product. Because software does not need to have a 'final' state (it can be fixed rather than tossed into a 'defective' pile), we tend to focus primarily on QA. QC of a web project tends to map most closely to the period before launch in which the client team reports bugs, or to Acceptance Testing.

Quality is not something you can ensure just before launch after ignoring it throughout the project. Even worse, it is very common for clients to ask to slash the QA line item and time period from project budgets partly or entirely. Quality work in our field also tends to be outsourced to less skilled workers, as if 'quality' is not especially difficult or important, but just an afterthought. After all, software development isn't a process that is prone to any type of errors, right?

To create a quality website, QA processes must exist and be followed at every level of the project. If you wait to 'fix' all 'quality issues' until development is complete, you may be able to meet specs but you will never have a quality product. 

To be continued... Symptoms, Diagnosis, Prevention and much more in the following installments...

Continue to Part 2

Jody Hamilton
Jody Hamilton

Co-Founder / CTO

Jody is a full stack Drupal expert. She does technical architecture, strategy, development, consulting, and developer training. Jody has worked on hundreds of Drupal projects since she began as a freelancer in 2006 and co-founded Zivtech in 2008. Jody grew up in the Philadelphia area and graduated from Harvey Mudd College in California in 2000.

Related Services

Ready to get started?

Tell us about your project