Of all the lessons I’ve learned during the lifespan of Jobstr.com, what follows is at the same time the most important and the most painful. I’m sharing it here, warts and all, because it’s the post I wish I’d read 24 months ago, when I couldn’t have told you the difference between a megabyte and an overbite, and C++ was nothing more than my grade point average. It’s the tale of two reasonable men approaching a task with pragmatism and restraint, and still pulling a Pacquiao faceplant, wondering where things went wrong.
The dev search begins
Since neither Frank, my co-founder, nor myself could write a line of code, one of our first Jobstr tasks was finding someone to actually build the site we had in mind. We interviewed a half-dozen developers, some of whom were offering to build our site in a content management system (“CMS”) like Wordress or Drupal, while others suggested writing it from scratch in a programming language like Python or Ruby. A pattern quickly emerged: developers always seemed to be telling us that (surprise-surprise) the programming language they specialized in was the best for our needs. This was hardly unexpected, of course, so we took it all in with a grain of salt and did our best to isolate the substance from the sales-pitch.
A dev firm I’ll call Team Droopy had (unsurprisingly) very polished explanations for why Drupal was a great platform for us. Most of these explanations revolved around what we were told was an extensive universe of Drupal ‘modules’. A Drupal module is like a WordPress plug-in, or a Firefox add-on: it’s a piece of code that a developer writes to perform a specific function, and then makes available free-of-charge to the Drupal community. The idea is that you can grab an existing module and drop it into your site so that you don’t have to reinvent the wheel by coding it yourself. For example, if you wanted a voting widget for your Drupal site, piece of cake > there’s an existing module for that. Facebook/Twitter buttons? Comments section? Contact Us form? There are Drupal modules for all of those.
And that was basically Team Droopy’s sales pitch: that we’d save TONS of time and money with Drupal (and them as developers) because most of the functionality that we were asking for already existed in the form of Drupal modules. We’d describe the question-and-answer interface we had in mind, and they’d say “great, there’s a Drupal Q&A module we can use for that!” How about an audio player to stream our podcast, we asked — “Yes, there’s a module for that too!” they crowed. Sure, the modules may not do exactly what we wanted out-of-the-box — for example, we had very specific instructions for usernames and privacy that many modules’ default settings didn’t allow for — but it was much better (so they told us) to start with a module and “hack” it to make it do what we wanted than to start from scratch. [<<Purple font for emphasis; I’ll return to this point later.]
Sounded good to us, and their fixed-price quote (mid 4-figures) and ETA (4 – 6 weeks) seemed reasonable so we hired them.
The other shoe drops
Now if this were a piece about Team Droopy rather than Drupal, here’s where I’d describe how things began to go wrong almost immediately, starting with lapses in communication, followed by deadlines missed without explanation, and most glaringly: sections of the site that were presented to us as “finished” that barely worked. By that I don’t mean a handful of pesky bugs…I’m talking about core functionality that was completely missing as though Team Droopy hadn’t even read our website spec. Imagine ordering a bowl of spaghetti and the waiter bringing you a rusty boot on a plate and presenting it, without a trace of irony, as your pasta. But since this is a story primarily about Drupal-the-CMS, simply insert your <developer-FAIL-story-of-choice> here. 6 months later, and having run up a bill THREE TIMES what we’d originally been quoted, we had a site that only loosely matched the spec we’d created, and we were in the market for a different developer (silver lining: the debacle allowed us to find our current uber-talented tech lead, Ted.)
So what happened?
Here’s what Drupal developers won’t necessarily tell you.
When you rely on a collection of pre-existing modules for core site functionality, you end up with an insanely bloated and inflexible architecture. Jobstr.com turned into a Frankenstein monster consisting of Drupal modules that had been delicately customized to do what we wanted, and interconnected in ways they were never meant to be. You might be wondering “Yeah, but who cares, as long as it works??” Well here’s why you need to care. It means that even seemingly minor changes will require massive code re-writes, because your site is a Jenga tower of hacked Drupal modules, with wires crossed in all sorts of funky ways. Asking your developers to move a login box from one location to another seems like a straight-forward request, right? Not when your site’s MacGyvered 6 ways to Sunday.
Here’s an example. We asked Team Droopy to move our question-asking text field from one page to another. They came back to us with a quote (and I wish I were making this up) that was literally higher than their original quote for the entire project. They were, straight-faced, telling us they wanted an amount higher than the entire initial budget to move a few text fields around! Our first thought was that it was just your run-of-the-mill scumbag overbilling: they knew that it would be difficult for any other developer to work on the website they’d built, so why not take the opportunity to juice their bill, knowing our hands were somewhat tied. Dirty, but they’d hardly be the first company to resort to shady practices to wring a few extra bucks out of a client. But that didn’t add up: they didn’t seem like outright crooks. We wondered whether they just didn’t like working with us and an unconscionably high estimate was their way of telling us they no longer wanted our business. Unprofessional, perhaps, but not beyond the realm of possibility.
Well, my stance on Team Droopy has softened somewhat over time. I polled many other developers, both Drupal and otherwise, who almost always offered some version of the following: it’s quite likely they weren’t spite-billing us with the huge quote for our first round of minor revisions, and it legitimately might have taken them ages for the seemingly-simple revisions, but that’s simply what happens when you build an inflexible architecture comprised of hacked modules. You end up with a bloated mess…one that may function properly in its current incarnation, but which required so many crossed wires, transplants, and unholy mashups to get working in the first place that even minor changes become drawn-out quagmires. Developers have a great term for it: technical debt. When you build an inelegant site architecture, you’re essentially accumulating debt that must be paid back in the future…typically when you want to modify or add something. Put differently, it makes scaling impossible (or at least financially prohibitive.) Had we known how much technical debt Team Droopy was running up, we would have been more way more diligent in not looking the other way when they missed something (which happened often.) We’d just tell ourselves “eh, they didn’t exactly do what we asked, but it looks pretty minor so we’ll just get them to revise it later.” Huge mistake.
I’m sure some Drupal developers will jump to the defense of the platform, or argue that we just got unlucky in hiring an incompetent development firm. But this isn’t an indictment of Drupal as a CMS, which seems to have a very loyal following and is probably a great choice for some users, perhaps for personal blogs or simple e-commerce sites that don’t require much in the way of customization nor future revisions. Team Droopy may even be perfectly adequate developers — although even if that’s the case, they probably should have cautioned us at the outset that their suggested architecture would leave us with a functional-but-bloated site for which any revisions would be cost-prohibitive. But they’d hardly be the first company to stay silent on drawbacks when courting new business. I assign equal blame to myself for not doing the research required to know what questions we should have been asking. We simply didn’t know what we didn’t know.
Hence, this blog post — it’s what I wish someone had explained to me at the outset (it’s really not too difficult to convey) so I’m sharing it myself in the hopes that it helps someone else. To be sure, we heard plenty of “Drupal sucks!” from WordPress developers, and “Ruby is the Devil’s spawn!” from .Net guys. But none of them seemed able to tell us just why they felt so strongly, so their fist-pounding usually just came across as bratty developers ripping into programming languages they didn’t know as well. The heart of the matter is this: if you’re contemplating a Drupal/PHP codebase for your project, ask yourself whether you anticipate wanting to iterate to any significant degree on your site, or whether it’s largely a set-it-and-forget-it project? Understand that you’ll end up with a pretty rigid architecture…which could be great if all you need is a stable platform that lets you add a new blog post every couple days. But if, like us, you were hoping for any sort of nimble arena where you can freely experiment and deftly pivot, take to heart the story of FrankenJobtsr.