Here at Camp Lulalbot we’ve been whipping up a series of sites that differ from our normal work: they’re meant to be built with no custom code, only contrib modules and UI-driven configuration. Sure, there might be a bug here or there to fix, but the idea is to speed things up dramatically by sticking to ‘pure’ contrib code.
In a lot of ways, it’s dazzlingly cool. We’ve been able to put together a relatively advanced social site with some great community features in record time. But on the fuzzy edges – the tweaky little bits of the designs, and a few ideas we thought would be simple – it’s apparent that doing some things WITHOUT custom code is really annoying and convoluted.
Some of this is due to the law of diminishing returns. Making simple, easy-to-use administrative interfaces for the really COMMON tasks pays off nicely for developers. Things like making custom content types, building listing pages, and so on are so common that Drupal’s UI-based builders for the tasks have become pretty powerful. The more esoteric the tasks get, though – the more site-specific – the harder it is to provide good tools for non-developers. A task that might take 30 minutes and 20 lines of PHP in the hands of a developer could be performed by any site administrator using a configurable UI-based wizard. Building that wizard, though, could easily take hundreds, thousands of lines of code and man-months of development time. Where’s the line between ‘needs to be automated’ and ‘seriously, just stick some PHP in…’?
All this is to say that I have newfound sympathy for the non-developers who want to put together complex sites with exacting specifications. You can get 90% of the way there pretty easily, but the final 10% will require compromise, or custom code. Drupal has massively accelerated the process of putting together feature-rich sites for us, but sometimes – as with LEGO building blocks – you don’t have just the right piece in your bucket of bricks.