Live data from Hacker News

Drupal's Golden Handcuffs

mikecr.it

71–80 of 148 posts

Re: Drupal's Golden Handcuffs

#71

Drupal 8 is basically trying to get to where django/rails/symfony were several years ago, and based on the glacial development pace of the last version, by the time it is complete, they'll still be several years behind the feature set of contemporary frameworks. In my experience, Drupal is a pristine example of the way modern software should not be made. With one or two notable exceptions, there is a distinct lack of…

"It's "success" is only because it's community consists of people who don't know any better." That is both untrue and dishonest. Drupal's success is directly attributable to all of the following: 1. a very large, growing, and passionate pool of contributing developers and designers. 2. aggressive community involvement a la issue queues, forums, IRC, local user's groups and 30+ regional camps and conferences in North…

1. Growing by what measure? When I was at Drupalcon 2012 there was a large amount of discussion about how the community wasn't growing and was the same people every year. And I seriously don't mean to be a dick, but passion doesn't equal technical competence. You don't have to be a gifted programmer to understand quality, and understand that Drupal lacks it.

2. There are user groups, I've been to them. They're mostly full of people who have basic problems and a few exasperated and grizzly veterans who offer arcane solutions to non-arcane problems "use last night's dev version of the module, sure it's ok to put php in the database... And the community of drupal.org might exist, but if you can sort it out from the convoluted UX mess that is drupal.org, good luck.

3. Is that supposed to be a feature? In theory, you can get ridiculous amounts of things done if you happen to know the arcane way to combine 30 different checkboxes and twelve different modules. How is this by any objective measure better than writing code? Code is expressive, documentable, concise. Checkboxes and UI interactions are not.

4. This is hardly a unique feature. The same can be said about wordpress, rails, django, etc (at least if you use webfaction)

I don't think you can argue under any objective measure that wordpress is more difficult to deal with than drupal. It has many of the same issues as drupal (feature management), but the ease of theming and documentation are lightyears ahead. It's also quite a bit more limited.

Re: Drupal's Golden Handcuffs

#72
And now we have all the silly arguments comparing web frameworks and CMS's.

The CMS people will compare installing modules to writing code from scratch instead of installing a library and writing a bit of glue code. If they don't make that mistake they will probably underestimate how much more flexible, better written and better tested that library will be compared to the CMS module and overestimate how hard it is to glue in a general purpose library.

The web framework people will underestimate just how fast it is to install a module into a completely integrated system and underestimate the time they would have spent integrating the library and writing the glue code. They'll also overestimate how often a client needs a piece of functionality that's in any way interesting instead of just a new skin on the same old thing.

The answer is "The progression goes: CMS -> Web Framework -> Http related libraries"

The question can be any of the following:

"What web related stuff has the worst code quality? what has the best?"

"How will the tools I use change as I get more experience in web development"

"What tools will I use for the most boring web dev work? What about the most interesting?"

"What tool skillsets in web development will earn me the most money"

"What tool skillsets have the least amount of jobs? what about the most?"

"What tools web dev tools will make me want to punch my monitor the most? and the least?"

Feel free to come up with your own.

Re: Drupal's Golden Handcuffs

#73
post #25

I would add this to the complaints: - NOT AMENABLE TO SOURCE CONTROL Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare. And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding s…

Wow. This sounds exactly like a complaint that would be lobbed against SharePoint (rightfully so, it's a special kind of hellish nightmare for people responsible for developing on it.)

Re: Drupal's Golden Handcuffs

#74
post #25

I would add this to the complaints: - NOT AMENABLE TO SOURCE CONTROL Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare. And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding s…

I work for a company that provides site implementation, custom feature coding and ongoing support for ~30 enterprise websites and all of them have this in common: 100% of the source code for each site is in revision control (SVN or Git, depending on client preferences). If you want to complain about Drupal be my guest. The ground's very fertile, but what you've posted here is FUD. Code in the database? No, just no. W…

This is quibbling over semantics. Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control -- creating a new content type in Drupal and adding fields to it is exactly analogous to creating a new model in Django. You can call it "configuration" if that makes it easier to justify its being in a table, but it doesn't change the fact that Drupal developers spend lots of time building shit that can't go in a VCS, can't be easily tested, can't be branched/merged, and can't be easily deployed without a convoluted export/import dance. Just because there isn't literal code in the database, it doesn't mean there's a clean logic/content separation.

Re: Drupal's Golden Handcuffs

#75

Earlier quoted context omitted.

I work for a company that provides site implementation, custom feature coding and ongoing support for ~30 enterprise websites and all of them have this in common: 100% of the source code for each site is in revision control (SVN or Git, depending on client preferences). If you want to complain about Drupal be my guest. The ground's very fertile, but what you've posted here is FUD. Code in the database? No, just no. W…

This is quibbling over semantics. Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control -- creating a new content type in Drupal and adding fields to it is exactly analogous to creating a new model in Django. You can call it "configuration" if that makes it easier to…

"Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control"

And that, in a nutshell, describes why Drupal's adoption rate is as high as it is compared to development frameworks developers actually enjoy working with. No fucking code. Non-developers can actually get results with the system without having to resort to the kind of miserable hoop jumping we developers subject ourselves to in an attempt to make sure nobody else on the team fucks something up.

View got changed? Log in and change it back. Absolutely, positively MUST have an ongoing log of changes to your view/content type/custom field? All of these are exportable to code and can either be imported raw or live in modules.

I suspect you've worked with exportables at some point so I simply mention this for any spectators that aren't aware there are a number of strategies for getting your configuration into code (and thus revision control) if that's your thing.

Also, for the uninitiated, apendleton makes an excellent point about deploying config changes from dev/staging to production. It sucks, plain and simple.

Re: Drupal's Golden Handcuffs

#76
post #6

I am puzzled by this: "Good Drupal developers are making a lot of money right now, much more than I'm seeing for Django or Rails or Node devs in general." I am curious where this is? This is not true in New York City, where I am. Developers who are good with a given PHP framework (Drupal, Symfony, etc) will make something like $60 to $70 an hour. The top Rails devs will make at least the same amount, and usually a li…

Depends on the gig. Of course the market is awash in no-budget clients and small shops operating on a shoestring. They don't pay worth shit.

The big name Drupal shops in DC are constantly hiring and are shelling out something like double the average PHP developer salary for experienced Drupal developers. More if you're good enough to contribute to the core project.

I'm telecommuting for one of these shops and making over double the local average wage for PHP devs. If I wanted to make more cash in this area I'd have to either take a management position or start coding .net

For reasons that are mysterious to me .net developers in my area are making (on average) 30-50k+ more a year than developers at a similar point in their career, but coding in different languages.

Re: Drupal's Golden Handcuffs

#77
Based on my two minutes of salary research I can say that someone with the title "Drupal Developer" make substantially less than someone with a title "Django Developer" (about $10k in SF), and (again, in SF terms), substantially less than the average software engineer without a framework in their title. From what I've seen on job posts over the last couple of years, including the framework in the title is something relatively endemic to Drupal, so I'm assuming that they don't get lumped into "Software Engineer" too often.

So let's take compensation out of the discussion.

Now let's just list the actual problems with Drupal.

It seems like there are as many drawbacks are there are off-the-shelf features when you're making Drupal the core of your own product. It also seems to make a lot of assumptions about your application following a very specific CRM architecture.

I'd personally prefer to spend the effort on building out the CRM components myself using a more modular framework so I have more control over the architecture, the version control history, etc.

It sort of seems like Drupal tries really hard to set itself apart from WordPress. In reality, it seems the major PHP CRMs all fall into this very narrow point of view on what the responsibilities are of the implementing developer. This minimization of implementation detail promotes a very limited perspective on how a PHP web application works. So now your product's architecture is hobbled by the philosophies of the core library as well as those most apt to develop on it.

Re: Drupal's Golden Handcuffs

#78

If you're using Drupal the way the author describes here - building in the interface rather than writing code - then yes, you're pretty much doomed. You're producing a very fragile thing that is very hard to maintain and adjust later on, and heaven help you if you actually want to do something in a different way than the modules you're working with allow out of the box. Drupal development is very divided between (a)…

What would you recommend an experienced developer coming into Drupal do to land in group A?

Group A is guarded by a learning curve like the Swiss Alps. The only way to get past that is to get as much exposure as possible. There are already some excellent suggestions here so I won't rehash those, some other things you might consider:

Idle in #drupal and #drupal-support. Whenever an interesting question gets asked, go figure it out if you don't know the answer already.

Try tackling a few issues in the novice queues for D8. Not only will you get the kind of low-level exposure to how core really works that so many "Drupal developers" lack, you'll also get some nice bragging rights when your name's listed with the rest of the contributors.

The next time you encounter a limitation with a module you're using, in addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that cleanly extends the module to do what you want. Open an issue in the module's issue queue and submit your patch. Code review can be tough to take but stick with your issue until your patch is either accepted or the module maintainer closes the issue (won't fix, whatever).

Try landing a gig with Acquia or some other big Drupal shop. You'll get to work with (and learn from) some of the top talent in the community and you'll get the kind of exposure you can't get experimenting in your spare time.

If you're serious about going pro with Drupal development drop me a line. I may be able to help and would be happy to introduce you to others in the community.

Re: Drupal's Golden Handcuffs

#79

Earlier quoted context omitted.

"It's "success" is only because it's community consists of people who don't know any better." That is both untrue and dishonest. Drupal's success is directly attributable to all of the following: 1. a very large, growing, and passionate pool of contributing developers and designers. 2. aggressive community involvement a la issue queues, forums, IRC, local user's groups and 30+ regional camps and conferences in North…

1. Growing by what measure? When I was at Drupalcon 2012 there was a large amount of discussion about how the community wasn't growing and was the same people every year. And I seriously don't mean to be a dick, but passion doesn't equal technical competence. You don't have to be a gifted programmer to understand quality, and understand that Drupal lacks it. 2. There are user groups, I've been to them. They're mostly…

1. Site adoption rates, especially in the enterprise space. You're absolutely right, the developer community isn't growing, and I think the blame for that lies squarely with the core codebase's deathmarch towards becoming Sharepoint. There was a point in time (circa D5, early D6) when coding with Drupal was still kinda fun. Core architecture didn't get in the way as much.

2. There are user groups, I've organized two of them. They are frequently full of people who have basic problems and a few exasperated and grizzly veterans who offer arcane solutions to non-arcane problems. Best outcomes typically occur when one or more local dev shops get involved with the group and use community support as a way to build their brand. Anecdotally this describes most tech user groups.

3. Yes, this is a feature. It's objectively better because you are not writing code. In addition to the obvious benefits (no fucking code) this puts the task at hand (at least theoretically) within the reach of non-technical or semi-technical individuals.

4. I dislike Drupal's internals for diverse and varied reasons I will not go into here. I dislike Wordpress's internals for many of the same reasons, and Wordpress is substantially more limited in it's capabilities than Drupal. Same general set of problems, many fewer features.

Also, I agree Drupal's documentation sucks hard. Unfortunately there's nothing to be done about it. It would take close to 10,000 man-hours to write shitty, blatantly misinformed documentation for the current body of contributed modules, assuming you budgeted 30 minutes to examine the module and 30 minutes to write about it.

Re: Drupal's Golden Handcuffs

#80

If you're using Drupal the way the author describes here - building in the interface rather than writing code - then yes, you're pretty much doomed. You're producing a very fragile thing that is very hard to maintain and adjust later on, and heaven help you if you actually want to do something in a different way than the modules you're working with allow out of the box. Drupal development is very divided between (a)…

What would you recommend an experienced developer coming into Drupal do to land in group A?

Try learning Drupal from a person first. A meetup or a Drupal camp are very good. A video is the fallback: Try NodeOne:

http://nodeone.se/sv/learning-library

or drupalize.me:

http://drupalize.me

Post reply on HN