Sunday, August 7, 2011

All that glitters isn't Drupal : CMS vs Framework

While I'm using Drupal on some projects as an example, I'm not singling Drupal out for criticism for the sake of it, and not ignorantly either as it's the CMS I have most production project experience with (opposed to vBulletin, though when I worked creating that, it was a forum - and not trying to be anything else).

The purpose of this post has to do with my thoughts on : Choosing the right tool (and starting point) for the job.

Knowing not only why, but that you have done so, as no project or pieces of software is ever "done" till two things happen. Firstly when it's stopped being worked on, and then it will last as long as it is robust, and secondly when the server is turned off.

Everything from conception up to the first stage is "the development of a software system", releasing it or putting it on a server is just one part of that, typically when customers (hopefully turn up and) need supporting. It's also usually at this point that if you have community engagement and it's manage that your system can be lead and developed for the needs of the community that want and use it. Release too early and you wont have enough of a vision or direction, too late and you'll of cut off all kinds of possible user input. Also someone else might of beat you to market.

So what does this have to do with a CMS like Drupal and a Framework ?

Much the same difference that buying Ikea furniture has with buying precut wood and understanding the tools. As always there is a time and place for both, though two typical things happen when you have a CMS build vs a framework build.

First ....... explosive module bloat. I can't remember the number of times I heard the conversation :

"Oh I just want to do this one simple thing"
"It's OK I know of one module that does that, though you need five other to support it, but hey that's OK".

A few weeks later you have two hundred SQL queries per page load and 70 modules, just for an original request of one simple feature. Given that it's very likely that you're relying on 3rd party modules, you are now at the mercy of the erratic OSS winds for the up keep of the module(s).

Typically you'll never get the exact behaviour you want as any generic module is built to what ever the requirements were at the time the author write them, so likely a compromise to what ever it is you need now.

The typical approach I've seen to this in the vast majority of Drupal projects is "Time to do some integration work" ....... also known as ....... "Just keep hacking it till it seems to work" i.e  open window throw out quality and stability and upgrade path, close window.

When this approach inevitably grinds to a halt you end up seeing the "Need a rock star Drupal developer for final 10% of project" posts on job boards. At this point  you know it's a spaghetti nightmare ....... the irony of why not get a "rock solid engineer" to begin with is never lost on me.

Second thing is maintenance, or full life cycle support. i.e. once you get to market and have to care for and evolve the system, you can't. You're so hacked into a corner the technical debt overwhelms anything you can do against it. This is typically where inept management will start to blame developers for their choices when faced with the symptoms of a system in crisis.


So what goes wrong ?

1) Due diligence

A software system as we've seen is a journey. Even with my recent encounters with the games industry and individuals claiming something is "done" and should be launched, it's not, there will be patches and updates. They are just trying to minimise the latter and try to paint it as failure opposed to understanding that it's part of the process.

Obviously embedded systems in medical equipment (as an example) is a different story, though it's very much the process and understanding which is present that achieves that level of quality, so actually supports my argument.

So ensuring that you (as a client) know what the options are, or as a developer are skilled enough to communicate that to a client is essential. If you aren't go work for someone who is, and learn from them.

Are you building a product or site to depend upon or a site for a weekend event that is going to be decommissioned in a few days. One needs good foundations and the other needs speed. Understand that rapid prototyping is just that, prototyping, it's done for learning (as is the blend of development by exploration) not delivery.

Typically what happens is that speed is chosen and high quality is assumed, opposed to the reality which is the other way around.

Speed in this context is the wrong word as well - it should be velocity as that has a direction which is important and it encompasses the vision of an outcome as well as time.

Answer - Don't just do something - think first - where is this going and what does it have to do.

2) Been told vs choosing

Requirements and understanding of the problem, then the tools not the other way around. I've met with teams that seems to think that there is a one word answer to every project (i.e. Drupal). Open blog site ? Drupal ...... image upload site ? Drupal ...... hot metal device for flattening my freshly cleaned clothes ..... you guessed it, Drupal.

Fanaticism leads to blindness, not just in politics and religion, but in engineering as well.

Answer - Realise you're in a very diverse world, and that's a good thing. There is no one answer to everything how ever hard you want it to be, as every situation is different.


When to use one over the other ?

By taking the time to understand, how well do you know what it is that you want to achieved, what are your time scales and will this every have to be maintained.

Given the 80/20 rule applies to most software projects using something like Drupal do do 100%, getting the 80% done quickly and then hacking yourself into a corner to get the last 20% isn't worth it ....... given that you can do the 20% with a half decent frame work anyway.


Other reading :