|
|
|
|
|
|
by AdrianRossouw
4765 days ago
|
|
|
i was a drupal core developer for almost 10 years. I had a falling out with the underlying premise of Drupal, which led me to question a lot of it's base assumptions. In the end, what made me leave was that I realised it was far far simpler to build up, than break down. The amount of code and resulting complexity of building something to be completely generalised / abstracted, was not in any way justified by the supposed benefits. Even when developed to make as few assumptions as possible, you end up running afoul of the assumptions there are. This then requires you to spend considerable time and effort, using increasingly byzantine and labyrinthine API's (some of which I even invented), trying to trick the underlying system to work the way you want. The entire thing becomes an exercise in the [1] Inner-platform effect, and won't stop until you have had to re-invent an entire turing-complete programming language driven by multi-dimensional arrays and subsequently serialised and cached into a database. My time with Drupal was definitely some of the best times of my life, and I will remember it fondly till the day I die. The people in the community are also amazing, but i do think there is a lack of critical questioning going on sometimes. [1] http://en.wikipedia.org/wiki/Inner-platform_effect |
|
|
1) Okay, this is a decent system for people who can't code to cobble together a mostly-working prototype of the thing they need, so long as they're flexible enough to work with it.
2) Why aren't my clients flexible enough to just do things the Drupal way.
3) Why should they be? My agency sold them bespoke development, and their UX (both administration and end-user) should honestly be better than this, and adjust to their needs, not the other way.
4) Jesus Drupal makes deviating from the beaten path miserable, but it pays well and I've gotten good at it now so I guess I'll keep on truckin'.
5) Breakdown. Giving into the evidence that it seems easier to build up from a framework with nice tools and decent libraries than to chisel away at awkward building blocks, even free ones.
Currently though, cleaning up messes and adding missing polish to Drupal projects created by people who are still at step 1 is continuing to be a financially responsible decision.
Drupal's building blocks though, do have two important uses:
They give developers who have no right to be coding a way to be productive, and the people who employ them some insurance. Brogrammer gutter rails.
There are truly miserable projects that shouldn't have budgets to do bespoke development and have nothing at all unique about them, that can be built in Drupal with zero code. CRUD legos.
Neither being of much interest to me anymore.