This is all we had back in the day. And it's all we needed.

In the spring of 1978, I spent a lot of time with Lego. 1970s Lego, for those of you that have forgotten or weren’t yet born, was a relatively simple affair, and as such was both better and worse than its modern counterpart.

It was worse in that the final products were less photorealistic analogues of the objects they were built to represent. That was OK, because back in the 1970s children possessed a faculty known as imagination.

In every other respect it was better, and it was better because it was composed of just a few simple pieces. With the exception of a handful of modish specimens which were (quite rightly) considered a bit thin-end-of-the-wedge by purists, bricks were largely of the 4 or 8 dot variety and white, red, blue, yellow or black. Despite this apparent limitation, children such as myself found it relatively straightforward to fashion any number of (albeit rough-hewn) laser pistols, dinosaurs, houses, cars, aeroplanes, animals, swords and so forth from these parts, using our aforementioned faculty.

Its simplicity made it infinitely more flexible; it also encouraged creativity and problem-solving, which I think was the point.

Blackbeard. Try making a laser pistol with this.

These days, Lego kits are like Airfix models. You can follow the instructions very carefully to build an amazing looking pirate ship / uss enterprise / batmobile. Or you can throw away the instructions and build something that looks crap, because what else can you do with a Jolly Roger, a little man with an eyepatch, a photon torpedo and a headlight? Answers on a postcard, please.

Now where was I going with this? Oh yes, that’s right: it’s an analogy. If a good module is an old school Lego brick, a bad module is a Lego Blackbeard.

When people proclaim the success of drupal by referencing the volume of modules in its library, they neglect the fact that it contains about 50 bricks and around 5,000 assorted Blackbeards.

There are good reasons for this.

For a start, there are two “rules of three” in software engineering. One states that it is three times as difficult to build a resusable component as a single-use component. The other states that a reusable component needs to be tried in three different applications before it is general enough to become a library component.

LoginToboggan, anyone?

But most drupalers – and most developers, for that matter – are not especially interested in writing reusable components. They are interested in writing components full stop, and will only consider abstraction and reusabilty when it dawns upon them that they are about to write the same code again in another context. And then they think: while that would be the right thing to do, I really just have to get this thing done today, and besides that other code’s already shipped, and so instead I’ll just copy-and-paste and change the variable names and make it home in time for Dollhouse.

Even if the developers are good boys and girls and want to do the right thing, they probably find themselves sneaking in a bit of refactoring when the boss isn’t looking, ’cause the boss is generally more focused on the fact that the whole project should have shipped yesterday and could you just “make it work” if you’d be so kind?

Beyond this, even with the best will in the world and a zen-like mastery of “the drupal way”, the breadth of drupal is such that omissions of logic are inevitable. That someone’s module doesn’t play nice with domain access or i18n is as forgivable as it is frustrating for anyone who gamely retains a ‘plug and play’ attitude towards drupal’s bold but fallible modularity.

So, things being what they are, an awful lot of modules are not designed with reusability in mind and are contributed in that state – fantastic at solving one particular problem well, but not especially adaptable. They are Blackbeard, if you will. Except for the buggy ones. Those are more like a Blackbeard that your little sister has chewed on, perhaps swallowing an arm.

This begets another problem, which is that the library is bloated with a lot of not particularly modular modules, and you can waste a lot of time playing around with them before you realize you’d be better off starting from scratch (incidentally making this a circular problem). This is due to another law of software engineering, namely that modification of reused code is particularly error-prone, and if more than 20-25% needs revision, it is more efficient and effective to start again.

I know that’s an ugly truth, somewhat antithetical to the spirit of open source, but truth it is. Besides, every developer knows that it’s easier and a lot more fun to write new code rather than analyze and fix/enhance somebody else’s mess. That’s why they call themselves developers and not maintainers / enhancers / fixers etc.

And so it goes on, with some notable exceptions, some of which will one day find themselves in core.

There’s an alternative to rewriting modules from scratch, of course. You can simply take them “as is” and live with (or workaround) the fact that they’re not exactly what the spec asked for, but they are at least going to save you a week of work. And that’s a fairly easy sell when management only scheduled half as many weeks to complete the project as it would take Dr Manhattan to write it. It’s the kind of mediocrity that satisfies no-one, but is suffered in the interests of pragmatism. In other words, it’s soul destroying.

Well, there you have it… and the fact that the phenomena is explicable doesn’t make it any less annoying.

Posted in Drupal
2 Comments Posted by admin