More information about the Underscore mailing list

[_] Drupal work wanted

Ryan T Nerd bristol.developer.ryan at
Mon Feb 11 13:56:46 GMT 2013

"Care to back that up? :-)"

"Otherwise, if you haven't anything nice to say, don't say anything at all

So which is it? ;)

On Mon, Feb 11, 2013 at 1:49 PM, James Panton <james at>wrote:

> On 11 Feb 2013, at 13:03, Ryan T Nerd <bristol.developer.ryan at>
> wrote:
> > First things first, that link only works if you take off the word might,
> > though I'm still not 100% sure of the relevance tbh.
> The point of that link was a reminder that it's people who create open
> source, people with feelings, and to simply tell them their work is rubbish
> is unkind.
> Positive criticism is useful and patches are very welcome :-)
> > Drupal is terrible.
> You mean, *you* think Drupal is terrible. Facts are facts and opinions are
> opinions. Arrogance is not appreciated.
> > 1. It murders databases with about 38937 more queries than should be
> needed
> > for any given task.
> Drupal makes a lot of queries. This is because the underlying philosophy
> of Drupal is to be as flexible as possible, which in turn tends to
> abstraction of the various systems, which can lead to more code and queries
> than might be expected for a seemingly trivial task.
> The huge benefit is the flexibility of the system. The developers of
> Drupal have *no idea* how it's going to be used and it is used for a huge
> variety o things no-one expected. The fact that it can handle these
> different, unplanned uses is wonderful.
> All the non-programmers who use it to create what they need are
> *extremely* grateful.
> > 2. It's slow. Hideously so.
> It's fast. Very fast.
> A slow Drupal site is mis-configured.
> > 3. It's like MVC never existed, there is literally no separation between
> > the data you want, and its presentation.
> There's complete separation between the data and presentation.
> I've found this very useful when outputting Drupal data as JSON or XML
> rather than the default HTML.
> > 4. Small companies use it for purposes that it's really not fit for (I
> > admit not Drupal's fault per se but a reason for my hatred of it) because
> > of its main advantage of being quick to build things in and being
> possible
> > to build a basic site with very little skill.
> This is one of the best things about Drupal: it's used in totally
> unexpected ways.
> Power to the people.
> > 5. 3rd party modules are a pain in the arse. Often poorly-written and
> with
> > dodgy security, frequently abandoned, etc. The existence of such a large
> > library of items of wildly-varying quality leads employers in the Drupal
> > sphere to conclude that you can build xyz in 3 seconds because a module
> > exists that almost does what you want, failing to understand that often
> the
> > modules lack the flexibility to do EXACTLY what your client needs,
> leaving
> > the options of a new module, horrific hacks or modifying a 3rd party
> module
> > [please never ever do any of these things]
> Some extremely complex functionality has been built with third-party
> modules, showing the power of the underlying system.
> It takes time to work out the good from the bad, but there's plenty of
> guidance from the Drupal community if you ask for it.
> > 6. It's so damn procedural
> Because for a long time it has supported lowest-common-demoninator
> hosting, which meant old versions of PHP.
> Drupal really tries to be as inclusive as possible, which can lead to some
> difficult technical and architectural decisions.
> But that inclusiveness is probably one the Drupal's key strengths.
> > 7. Have you ever tried untangling a mess of modules all interacting with
> > each other where something's not working? Again, usually a problem when
> > dealing with 2nd hand code.
> Yes.
> A problem with all 2nd hand code? It's the price you pay for not
> re-inventing the wheel.
> Was the documentation not good enough? Did you help fix it?
> > 8. Projects created in Drupal are a maintenance nightmare. At the
> employers
> > who have used Drupal, it has invariably been the Drupal sites which were
> > unmaintainable, barely hanging on by a thread, while CodeIgniter stuff
> is a
> > relative joy to work with.
> I have seen *so* many awful implementations of Drupal in my time, so can
> totally feel for you here.
> Generally, the problem has been experienced programmers using Drupal for
> the first time. What why find difficult is the concept of *not* writing any
> code unless you have to.
> It's an understandable problem: used to coding new functionality, they
> don't look to what's already there and go off and write something when they
> don't need to. Many see *configuring* functionality beneath them and feel
> they can write a better solution. Those people generally make the worst
> Drupal sites.
> > Note that I say all this as someone who has buggered off to do Java
> > instead, with a nice bit of Struts and Hibernate for good measure. I can
> > honestly say I don't miss Drupal one bit!
> I'm glad you're happy where you are now. Enjoy your Struts and Hibernate.
> But do remember, an awful lot of people, the world over, have put a lot of
> time and effort in Drupal and are constantly striving to make it better. As
> I said before, positive criticism and patches are really welcome, so rather
> than merely dismissing other people's hard work with ridiculous and untrue
> statements, please jump into the issue queues (
> and show us how it can be
> improved.
> Otherwise, if you haven't anything nice to say, don't say anything at all
> :-)
> James
> --
> underscore_ list info/archive ->

Please do not send me spam, nor pass my email address onto recruitment
agencies as I have quite enough spam already and am *not looking for a
job*[I already have one thanks]. May have some interest in
collaboration around
Android development.