The International Labor Rights Forum (ILRF) reached out ThinkShout a few months back requesting some small tweaks to their Drupal site, www.LaborRights.org. This site was then, and continues to be absolutely gorgeous - with a very tight feature set. Over time, however, many of these features and the business logic of the site found its way into the site's theme code. This is a very common occurrence with Drupal sites. And while this practice allowed prior developers to add new features to the site quickly and inexpensively; because of this development approach, the site started acquiring a lot of "technical debt." In other words, with each customization in the site's theme code, each subsequent customization became incrementally more and more expensive - and the site itself more and more "fragile."

Fortunately, ILRF made a very wise decision to invest in a code clean-up. So, our ThinkShout team went into the site and abstracted all the business logic from the custom theme and rewrote this logic in a handful of custom modules, as well as codified blocks and views. These, combined with application of the new Drupal Context module (as well as a few related helper modules), has brought the site back in line with Drupal's current best practices. And as a result, ILRF has much more flexibility moving forward when they need to add new features and tools. Similarly, the costs for applying security and feature updates has dropped significantly.

Again, there are really good reasons, primarily driven by budget and deadlines, for ILRF to have gotten into the position that it did with so much business logic written into its theme. And there was a cost for my team to dive into this code and do this clean-up. That said, I think that this was a very wise investment in the long-term health and viability of the site. Over the next year of even just a few small feature requests, this investment will surely pay for itself in reduced overall development costs. Getting the code base inline with Drupal best practices also means that ILRF will have significantly more flexibility to work with different Drupal service providers - because intimate knowledge of the old site's custom code will not be required.

I think that there are two clear lessons to be learned here:

1. Whenever building a website or paying for new website features - remember to consider the "Total Cost of Ownership". Training and ongoing maintenance often slip off of NPO's technology budgets - which can create long-term "technical debt" that over time costs more than the price of routine maintenance.

2. While there's a ton you can do with Drupal without a lot of deep engineering knowledge, Drupal is becoming more and more a development framework - like Ruby on Rails, Django, or Catalyst. There are best practices in Drupal development. It is its own discipline of web development. Whenever possible, you should try to make sure that your development service provider knows these practices inside and out.