ux

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
Abraham Lincoln

Despite such a wise dictum and lots of personal experience to teach us otherwise, we find continued pressure to dive into projects with little to no planning in efforts to “go faster”.

However the goal we set ourselves was to reduce Drupal development time by 80% and this session is to share the invaluable lessons we have learned in the quest to go much, much faster.

Developers love Drupal for a hundred reasons, not least because it makes you look like a rockstar coder whose answer to any functional request is always 'Yes I can'.

However answer me this honestly, how did the training and handover to the client go ? Did you find yourself apologising or explaining away certain areas or buttons that don't actually do anything - or worse "ah this is actually a developer's feature".

Like me, you may have looked at the admin themes out there as an aftermarket bolt on to improve this - or perhaps you're happy for your clients to use the little black bar?

Drupal lends itself well to modular, separately deployable code. This means you can often reduce quite large Drupal-based projects to sets of minimum deployable features (MDFs) - informally speaking, chunks of functionality which get a particular job done, and don't look weird on their own - which quickly start to take shape as Drupal development plans.