I’ve been involved with Drupal for a long time. For my whole career as a coder, really; I wrote my first serious code in the first months of 2008, and it was for Drupal. And through the myriad technical problems Drupal has presented to me over the years, I’ve become a decent engineer myself, and gained an appreciation for the art of software engineering and design.
But for the past eighteen months or so, I’ve found Drupal progressively less meaningfully challenging. That is, as I’ve become aware of the broader picture of software engineering and computer science — lessons generally learned outside Drupal — two things have become apparent:
- Many, probably most, “hard problems” in Drupal are neither intrinsically difficult, nor hard in other web systems, but are made hard by flaws in Drupal’s design.
- There are a lot of things Drupal’s really, really terrible at. And that’s fine — good, even! Software shouldn’t try to be good at all things. However — and here’s where I honestly can’t tell if it’s my perspective or the sector that’s changed — there is less and less overlap between the set of problems Drupal is good at, and the set of interesting problems that require craftsmanship.
You see, I’d gotten into Drupal because I wanted to solve big problems. But a realization was crystalizing: Drupal itself is such a big problem that it leaves little space for the one you actually want to solve.
I think, somewhere deep down, I’ve recognized these things for a while. But I needed a soft landing somewhere else before I could really admit it. So, I started focusing elsewhere (mostly in Go and Ruby). And as I did so, my anger at Drupal began to simmer: at all its ill-or-un-conceived designs and the nifty ideas crushed thereunder, and how helpless it left me feeling. While the other systems certainly have their issues, those issues just seemed much less numerous.
Even as this resentment grew, I was deeply enjoying working in the other languages. It’s pretty much the norm, I guess, to not only learn new languages in the context of the old, but to “float up” and see meta-linguistic patterns across the languages. For me, those patterns drove me further into questions relating to math and software design. And while those two vectors point me squarely away from Drupal, there was a third, a product of the other two, that weirdly brought me back: complexity.
Now, I’d had complexity on my mind for a while, but I didn’t have words for it until I found Rich Hickey’s famous presentation, Simple Made Easy (by way of former Drupaller Adrian Rossouw’s own reaction to it). I’m not quite so absolute about functional programming as Hickey, but the foundation is sound, and the effect on my thinking was explosive. It gave me working metaphors for thinking about complexity, which shone light on previously unnamed, insomnia-inducing problems scurrying around the edges of my perception.
So I submitted a session for Drupalcon Austin, to try to get these ideas out a bit more. The problem was, though, these complexity/simplicity revelations only exacerbated my anger and resentment with Drupal. Now that I had a framework that could fit most of my frustrations, they were just about ready to bubble over.
When I arrived in Austin, the presentation was only mostly done, as was my patience. My not-very-well-formed plans for the talk involved some far worse excoriations of Drupal than I actually made, concluded by mic drop (though somehow still followed by Q&A?). As I talked with my comrades about these ideas, though, I figured out what my anger was really about: I was pissed at myself. For not seeing these issues sooner; for wrapping myself up in something that, now, seemed so clearly, deeply flawed; for all the things I could have done or understood if I had not wasted precious time. And none of that is actually about Drupal — it’s about me in relation to it. And, poof! My anger evaporated, leaving behind a simple question:
What is my identity in Drupal now?
Simplifiers
It’s kind of a weird question. No one dictates our identities or the way we contribute in the community. It’s basically a do-ocracy, as much as such a thing exists. But that’s not really what I mean.
I’m thinking of those people I know — many of the community’s heroes and stalwarts — who despise Drupal for reasons similar to what I’ve outlined above. We joke about it to make ourselves feel better, discuss it resignedly in backchannels, and generally feed our stomach ulcers with other stress mismanagement techniques.
Now, “my software project is disappointing” doesn’t exactly rank on the scale of major problems humans face. But that doesn’t mean we should just shove our discontent under the nearest rug…though that’s pretty much the only option for those with genuine, deeply felt misgivings. The community (like most communities) doesn’t really tolerate honest-but-combative criticism well. But it also just runs too harshly counter to the slightly cultish, hyper-positive vibe of most Drupal events. So, unless you’re someone with some clout, you’re sorta consigned to suffer in silence.
Which is part of what I’m hoping to change by writing this: as someone with some clout, I want it to be generally accepted, and even encouraged, to publicly hold such ‘negative’ views within the community. I think it’s an identity people should feel free to display, ‘loud and proud.’ And I think the way to do so, constructively, is to think about “simplifiers.”
This would be a good time to have a look at my aforementioned talk in Austin — it (re)defines some words used below (namely: simple, easy, and [de]complect). Unfortunately, it’s long on meta and short on examples, as my first attempt at a talk tends to be, but I do get the definitions out of the way up front.
In general, I think these are the defining characteristics of simplifiers:
- They seek out discrete, well-definable problem spaces whose requirements are based more general HTTP/HTML/software design issues than on the vagaries’ of Drupal’s requirements or features.
- Once defined, they vehemently defend the borders of this code ‘fiefdom’, keeping their solution unmuddled and uncomplected. They don’t overcommit outside of these areas.
- They only ship code that is as simple as the domain allows, or code that decomplects another problem space. To that end, they do not ship code that is “easy”; they do not ship features.
- However, they happily work with (read: seek out) others who will adopt responsibility for taking their “simple” system and building an “easy” layer overtop.
- They give zero shits about broader release dates — only getting the particular problem right.
- They either relinquish outright, or significantly reduce, their ‘voting power’ in major, direction-setting contexts.
- They actively seek out experience outside of Drupal, both in order to bring that experience back to Drupal, and to help diversify their personal incentives away from Drupal.
Now, as much as I’d like this to be a shared set of principles, I can’t imagine it’s surprising that this is, first and foremost, a plan for me.
I’m doing it in a couple ways already. There’s really just two bits of Drupal code that I voluntarily look at anymore: hookalyzer, a textbook definition for “decomplector”, and the D8 assets patch, which I’ve sadly allowed to languish. For both of those, by the way, I’d love to find partner(s) to play the role of ‘easy’ against my ‘simple’.
I’ve also tried to remain apprised of any of the work going on related to Drupal’s page model and rendering pipeline — it used to be my jam. But I’ve given up my vote, because keeping it would bind me up too much with the sort of problems I find so artificial and frustrating.
I still work at a Drupal shop, and we do find all kinds of interesting, specialized nooks and crannies. But I also spend a hefty chunk of (more enjoyable) time not working on Drupal. And I bring that knowledge back to the community wherever I know how. (In fact, doing so is another goal of this piece — that, and publicly validating my life choices.)
But there’s the other, more important motivation: I’m worried about my friends. I’m worried that they, like I, have their own questions of identity. That private kvetching masks a deep dissatisfaction with Drupal, and by extension, a disquieting unhappiness with their professional lives. Or worse, maybe they have found Steven Wittens’ ‘nothing in the middle’, but find that void preferable to ragequitting and exile.
There’s some wisdom hiding behind the frustration in Steven’s gist. Drupal’s motto of “come for the software, stay for the community” has quite the dysfunctional underbelly. For those who’ve experienced its effects, I think this ‘Simplifier’ path could be a lifeline. For me at least, it’s a relationship with the project I can accept, and that makes me happier.
If you buy the arguments I (and others) make about the costs of complexity, the wins are just as big for the project. Drupal is enormously, unnecessarily complex, and we lack both people and an effective public dialogue around keeping things simple. We need simplifiers, far more than they want or need us. And, because Drupal is one of nine ‘XLarge’ open source projects that has ever existed, there’s a big enough pool for us to find and nurture not just the simplifiers, but partners who’ll build the ‘easy’ layer.
Or maybe I’m nuts, and loosening the ties that bind will just cause everything to unravel. Either way, I think a lot of people share this feeling, and suffering in silence sucks. That, at least, is a problem we can solve: tell me about it with a tweet @sdboyer, or an email to drupal@samboyer.org.
