Boutique medical services offer wealthy Americans the chance to cut the line - <AUTHOR> https://mobile.nytimes.com/2017/06/03/business/economy/high-end-medical-care.html <comment><USER2> My concern is that this sort of approach to medicine is going to result is the "top specialist" tier of doctors spending more time treating complaints that don't really require their particular level of expertise. You probably don't need to see the world's best cardiologist if you just have high blood pressure, but if you are paying 40k a year for a concierge medical service they might feel that the need to get you in front of him or her in order to justify their fee. Otherwise what are you paying for? Consequently this amazing heart doctor spends an hour telling you to eat better and exercise rather than evaluating someone's complicated and life threatening condition.

<comment><USER3> In theory though, the market should address that right? e.g. a version of this that's $10k a year but can handle 10x the volume because you triage patients with competent nurses and PAs and save the expert's time for the cases where they can actually make a difference.

<comment><USER4> Starting to sound an awful lot like the U.S. health care system...

<comment><USER3> Yeah, I had the same thoughts when I was writing that. The key difference is that the current system is so convoluted that there is almost no meaningful market for consumers on the actual care side of things.

</comment></comment></comment></comment><comment><USER5> I like how the article says Private Medical "does not advertise", then immediately follows that with some glossy, staged press shots. They don't advertise, except for the advertisement they just ran in the New York Times.

<comment><USER6> The NYT, with advertisement slogans like "Truth. It has no alternatives." (When I first saw it, I had to double-check whether I am reading some English translation of one of the "Pravda" issues in the USSR -- no, it was still NYT), -- well, despite such bold claims, they often act as the principal venue for top-level PR firms. Increasingly so in the last few years -- I understand that newspaper business is in deep trouble, and I understand their envy to Facebook and Twitter, but this sounds just a teeny tiny bit unethical to me.

</comment></comment><comment><USER7> This is the sort of thing that ends up with rich people swinging from lamp posts.

Not the fact that you can hire a private doctor. Taking one doctor out of circulation, more or less, doesn't enrage people.

No, the offensive thing is that John Battelle's kid's broken leg is too important to be seen by a mere ER doctor, and instead the very senior orthopedics doctor is summoned away from dealing with serious problems to deal with a broken leg.

How does the head of orthopedics live with himself? I'm sure he comforts himself with money.

Battelle made his money by doing things, and hardly anyone begrudges him that. But his son now knows that his broken leg is more important than some grandmother's shattered hip, and is likely to keep that attitude as he rises to adulthood.

<comment><USER8> >This is the sort of thing that ends up with rich people swinging from lamp posts.

i don't understand why smart-ish people keep repeating this. there will never be another revolution in a first-world (western) nation. it's just not happening.

<comment><USER9> why do you think so? i don't have strong convictions either way, but i don't think i'd count it out as an impossibility.

<comment><USER10> A lot of reasons, but one solid one is that there is a pretty strong anti- pattern in that the ones that desire wealth redistribution the most are the most likely to support gun control and/or the banning of private ownership of weapons.

<comment><USER6> Wealth inequality is not the only reason for revolutions. There are also dictatorships, human rights abuse, corruption, disregard of laws for the elite, and other fine things that might warrant the direct action.

<comment><USER10> While true, those values are highly correlated - at least in Americans, and most of the developed world - with people desiring lower access to guns for the private citizenship. Low access to force multipliers makes it much harder to spark and win a revolution against the state.

</comment></comment></comment></comment></comment></comment><comment><USER11> I don't personally have a problem with people paying extra to receive what they perceive to better care. But I think if you look at outcomes, I doubt you will find that they have received better care by paying the extra 40k or whatever it is a year. It's great that the kid in the story was able to be seen by a established orthopedist in a city hospital - but most general orthopedists know how to set a kids leg, and I doubt the outcome would have been much different if they had gone to the originally intended ER.

It's certainly a good gig for the family practitioner, but I think the following quote at the end of the article:

""The traditional model of having a good internist is dying," said Mr. Traina, a scion of a prominent family here that arrived with the California Gold Rush.

will apply to the concierge doc in the longer run as well. If you are reasonably healthy, checking your blood work once a year and your blood pressure every so often, you don't have much need for a family doc. If catastrophe strikes, then you will probably need a specialist - and if you're willing to spend the money, it's best to save it for these times - yes your cash will get you in as easily as a concierge doctor can - rather than dishing out 40k annually.

I recently chose a medical clinic that's part of a university system for my own healthcare, as opposed to a family doc who charges $1400 for an initial exam and $400 for follow ups. Do they spend as much time with me? No, I'm in quick and out quick. I get my shots and blood work and I'm out the door. Since I'm pretty healthy, that's the way I want it.

<comment><USER6> It is the most rational model. Unfortunately, like mentioned in other threads here, fully private, cash-to-hands medical practice is prohibited in many countries.

I have to travel to Spain for my medical tourism needs. However, it is mighty inconvenient.

</comment></comment><comment><USER12> It's unclear what the point of this article is supposed to be other than to stoke outrage at the 1% who get premium treatment while the rest of us proles suffer 'normal' healthcare. It's almost as if all of a sudden having money buys you nicer things, as it always has for all of history, including in the healthcare systems of every other nation.

In developing countries like China, Russia, India, Saudi Arabia, there are entire parallel healthcare systems for the wealthy and connected to get high quality care and when such care isn't available, they travel to richer countries or hospitals that cater to foreigners in Bangkok, Seoul, Cleveland, Medellin, and any number of medical tourism destinations that have popped up. I've been to several of these hospitals and they are _nice_. In Seoul, at the Samsung Medical Center, hospital rooms for foreigners have one bed each, as opposed to four beds each for Korean nationals. Why? Koreans are paying less via subsidies and rich foreigners with weaker currencies are paying full fare.

In universal healthcare countries with market economies like the UK and Canada, private clinics are the only way patients with money who want to avoid the limitations imposed by rationed care can get access. In Canada, instead of waiting an average 9.5 months(!) to replace a painful knee, you can go to Duval Orthopedic Clinic in Montreal to get a knee replacement for under $14,000 USD (compared to $49,000 in the US). In Hungary--this is a fun one-- you can go to a terrible state doctor for free or pony up $50 US for a private doctor. Most Hungarians who can afford it pay the cash, because they know they will get the quality for it. Even in the so-called universal medical system of Cuba, the political elite and their relatives have their own private hospital, whereas the rest of the population suffer substandard equipment, years-long wait lists, lack of medication and outdated facilities, and worst of all, doctors who spend half their time working side jobs as taxi drivers to pay the bills.

The point is, markets will always step in to fill needs that aren't being met by state-run care--it's as predictable as the sun coming up. Often, the gap between rich and poor is worse in systems that try to do the most to eliminate it--Cuba being a prime example.

What I found most interesting about this article--most likely unintentionally- was the hypocrisy of the Bay Area, the liberal mecca of the country, that would vote for universal healthcare in a landslide, also being the main drivers of demand in premium private service, widening the gap between the rich and the poor such a healthcare policy is bound to exasperate.

<comment><USER13> _In Canada, instead of waiting an average 9.5 months(!) to replace a painful knee, you can go to Duval Orthopedic Clinic in Montreal to get a knee replacement for under $14,000 USD (compared to $49,000 in the US)._

In the US, your _charge_ is likely to be $49,000, but I think many insurers have agreements to only pay 20-40% of that.

Woe to you if uninsured in the US, though: they'll expect the full $49K. See David Belk's [http://truecostofhealthcare.net/](http://truecostofhealthcare.net/)

<comment><USER12> True, and it also varies widely by region.

</comment></comment></comment><comment><USER14> I think a fair question is whether all that additional expense results in better outcomes. I certainly understand the experience is better for patients, and there is little or no wait time, but is there evidence that health outcomes are actually better?

I wonder if it's like the difference between taking coach vs. a private jet. The private jet is more convenient and comfortable, but safety ratings are considerably better on major airlines.

<comment><USER15> I think another way to look at this is minimizing risk/resulting guilt. The broken leg example seems to support that - the father is paying for the best possible care for his son, even if the outcome is the same (leg heals properly) as the ER doctor, the father has obsolved himself of the risk that he didn't do enough and allowed the leg not to heal properly.

In other words, the (I'm guessing) relatively slim chance there is a complication with the broken leg is not worth it to the wealthy father to take.

<comment><USER14> > In other words, the (I'm guessing) relatively slim chance there is a > complication with the broken leg is not worth it to the wealthy father to > take.

In medicine, though, there have been a lot of recent studies recently that have shown that too much care can be harmful (especially in the orthopedic realm). Sometimes the best thing to do really is nothing, but when you're paying 40k a year, my guess is you, and more importantly your doctors, would rarely take that point of view.

</comment></comment></comment><comment><USER16> Doesn't this exist in almost every country? There is always market for rich to get better health care.

<comment><USER17> No. It's really as simple as that. only the US allow for this.

Edit: To all the down-voters. The article isn't about private healthcare which in the US is more the rule than the exception. It's about a layer on top of private healthcare.

Of course private healthcare exist in other countries. But this concierge layer for "normal" rich people you will be hard pressed to find many other places I ma pretty sure off (but could be wrong of course). Unless you are a politician or royal or something.

<comment><USER18> While there may be some countries that disallow private healthcare entirely, the international situation is far more nuanced than your comment implies. For example, I lived in Spain, where most people use the highly functional public health system but there is a parallel private healthcare industry that is also very effective (and still reasonably priced, compared to private healthcare in the US).

<comment><USER17> Yes private healthcare systems of course they exist in other countries. But the article is as far as I understand it about something else. It's about a layer on top of the already existing private healthcare system in the US.

</comment></comment></comment></comment><comment><USER19> What is interesting is that anecdotally in my experience and those I talked to the VIP patients in VIP rooms tend to have worse outcomes.

It may be because there is a tendency for VIP to demand that something be done and it not be uncomfortable. So they may go through more tests and procedures for every little complaint and maybe get more pain meds which ends up contributing to worse outcomes.

In addition, the doctor may be reluctant to say "no". For the ultimate example of this, see Michael Jackson.

Finally, teaching hospitals provide some of the best care in the country. So because of that, a VIP may go there. However, many of them don't want to be seen by residents and medical students and residents. They want to be seen by the famous department chair. Well, in many cases the department chair may be good at research and politics and fundraising, but may not be the best actual doctor. In addition, they may be years removed from actual day to day patient management, relying on the residents to manage the details. You can imagine how things can go wrong.

</comment><comment><USER20> And?

You can always get better faster service if you pay more.

Disney World, health care, cars, political favors, nutrition, hospice, climbing Everest, prosthetics, cleaning staff, coaches, going to outer space, etc.

I wouldn't expect Health Care for the proletariat to be somehow different from the rest of our brief mortal existence. Somehow, it has seemed recently to gain a special status all to itself.

\---

"Wish not so much to live long as to live well."

\- Benjamin Franklin

<comment><USER21> You are equating health care with going to Disney World ?

<comment><USER22> Pay more and cut the line all day long, access to exclusive restaurants, private meet and greets with characters, etc.

</comment></comment></comment><comment><USER23> MDVIP. Pay an annual fee in exchange for the doctor keeping a reduced patient load.

It's reasonably affordable without being velvet rope wealthy and gives you a much more streamlined care experience.

</comment><comment><USER24> As usual the elite can afford the best and will get it.</comment>


A Plague of Pigs in Texas (2011) - <AUTHOR> http://www.smithsonianmag.com/ist/?next=/science-nature/a-plague-of-pigs-in-texas-73769069/?all

<comment><USER3> The environmental history of this stuff is really interesting - <USER2> Melville wrote a good book about the "ungulate eruptions" following the Spanish conquest of Mesoamerica: [http://books.google.co.uk/books/about/A_Plague_of_Sheep.html...](http://books.google.co.uk/books/about/A_Plague_of_Sheep.html?id=kEvQLSDmv_wC)</comment>


HN voting ring improvement - <AUTHOR> http://twitter.com/paulg/status/22551773068 <comment><USER3> A technical solution to a social problem. I am not confident that this will solve the root cause of the problem. Not that I understand the root cause.

Coming from a game development background ("real" games not "social" games), there are feedback issues with the voting system. Frankly, I don't vote a lot because I don't understand the system. I usually only up-vote one story a day.

Sometimes, if there is a "crap" story in the top 5 I will up-vote the other 4.

Look up the term "meaningful choice" in the book _Rules of Play_. [http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&...](http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=9802) <http://en.wikipedia.org/wiki/Rules_of_Play> [http://www.amazon.com/Rules- Play-Game-Design-Fundamentals/dp...](http://www.amazon.com/Rules-Play-Game- Design-Fundamentals/dp/0262240459)

The problem is that I don't have to choose between story A and B. I can up vote them both because there is no scarcity built into the system.

I don't even think there is a scarcity model with voting. How many up votes do I get in a day? If there is a model then I don't understand it. That implies the second issue with the system is that there is a lack of feedback.

This isn't only an HN problem. I see the same problems with other social sites that try to implement voting or other game mechanics.

Focus on improving the system for good players. Don't focus on squashing behaviour by bad players trying to game the system. The good players will police the bad players if the system is fairly balanced. No one reads the instruction manual, therefore the good behaviour has to be designed into the system. And feedback, feedback, feedback. There needs to be better feedback when there is good behaviour.

<comment><USER4> I wonder if providing the ability to downvote submissions would fix the problem of voting rings. Surely there will always be more legitimate voters than ring voters, and if legitimate voters can downvote submissions that were artificially inflated by ring voters it would balance things out.

Of course there is a reason why we don't have downvoting of submissions. The negative side-effects would probably outweigh the positive.

<comment><USER5> I am not sure I support downvoting of links. Though I am intrigued whether allowing downvoting for a set of users with some higher criteria than upvoting (say account date > 1 year + 500/1000 karma) will have some positive results.

</comment></comment></comment><comment><USER6> On Twitter I follow and am followed by a lot of HN users and I know a lot of HN users independently and.. I can recall fewer than 10 times anyone has ever said "check this out and vote it up?" Sometimes I do, sometimes I don't - <USER2> entirely depends on if I'd vote it up _anyway_.

It saddens me, then, that there are "voting rings" which, I'm assuming, rely on people voting up each other's stories in a mutually beneficial way. I hope this can be curbed but, I fear, innocent groups of friends or popular HN users could fall foul of it merely for consistently submitting or voting up each other's stuff in an unorganized fashion.

<comment><USER7> The nice thing about dampening collusive votes in code is that we don't have to sit around in threads like this arguing about the "ethics" of voting and searching our souls. The nice thing about having a benevolent dictator behind the site is that we can just have things like this fixed automatically.

I suggest: stop worrying, vote however you want.

<comment><USER6> The ethics of voting are not my focus. My concern is the potential _collateral damage_ of the "punishment." Google has had to take similar actions with its algorithms and even their best efforts yield collateral damage - I suspect this is why it takes them so many people and so much time to make improvements.

The voting system on Hacker News is small beans compared to Google rankings (which can make or break entire businesses), but it doesn't negate the validity of showing concern for a site from which I get much of my daily reading material.

</comment></comment></comment><comment><USER8> This must be difficult. I presume that some of the more popular personalities on HN receive quick and multiple upvotes per blog post by a number of "fans" rather than a ring. Should these also be ignored?

How does one differentiate between a voting ring and genuine fans who like a particular blog article by a popular author (say having read an RSS feed and independently submitted the same article to HN)?

</comment><comment><USER9> For the San Diego Hacker News meetup announcements, we generally post the HN link on the SDHN mailing list and invite people to upvote so there's a realistic chance new potential attendees will read about it. Would this constitute a voting ring?

<comment><USER10> "If that is wrong, I don't want to be right."

</comment></comment><comment><AUTHOR> Would love to know more details about this.

<comment><USER11> What does he mean by "voting ring"?

<comment><USER12> At the time of this comment this submission has 5 upvotes in its first 22 minutes and it is #5 on the front page.

This means if you can convince just 5 of your friends to quickly upvote your submissions, they will all get promoted to the top of the front page. You can do the same for their submissions. That's a six-person voting ring.

Ideally pg would like to detect these rings and assign your friends' votes a lower weight on your submissions.

<comment><USER13> Sounds like a NP-hard problem, am I correct?

<comment><USER14> Not so much. Trust metrics (underpinning Google's PageRank) are pretty efficient at this sort of thing. If people A-Q all vote each other up, but nobody votes them up, their weighted effect is pretty close to nil.

Try: <http://en.wikipedia.org/wiki/Trust_metric> <http://en.wikipedia.org/wiki/PageRank> and <http://www.advogato.org/trust- metric.html> for a bit of an overview.

</comment></comment></comment></comment></comment><comment><USER15> Would it be possible to apply this research to the new page in order to reduce or eliminate information cascades?

<http://www.overcomingbias.com/2007/04/popularity_is_r.html>

If we split the new page into three or four parallel universes then it seems like that could go a long way to improving the quality of what hits the front page.

<comment><USER16> That would likely backfire, already a lot of stuff that is good or even great does not get enough votes to make the homepage. Splitting the new page in to multiple segments would make that worse.

I can see the case for randomizing the entries on the newpage, and maybe making it a bit longer to offset the variation in traffic on the site at different times.

Happy to see PG work on more voting ring busting, there is definitely still quite a bit of that happening, the new page sometimes shows pretty weird things.

<comment><USER15> "Already a lot of stuff that is good or even great does not get enough votes to make the homepage."

The reason this happens is because stuff scrolls by very quickly, and people are most likely to click on the stories that already have votes. And the first stories to get votes are always the ones from outlets that people are familiar with, like Mashable and TechCrunch. If you split the new page into three universes then all of the stories that would normally get free votes have their vote count divided by three, whereas the other stories do about the same, which is comparatively better than they'd do otherwise. At least this is my thinking. And then you just add up all the votes from all the new pages to determine the front page.

</comment></comment></comment><comment><USER14> If we can get a PG in here, I have a question:

Trust metric based, or something else?

I'm not asking for code, as I suppose exposing that could make it more attackable, but I _am_ curious about the technique.

</comment><comment><USER17> I would like one story taken from the new section to be randomly inserted in my top 10. This would encourage readers to vote and make it easier for good news to go top.

</comment><comment><USER18> Does HN give less Gravity to a vote if they don't actually view the story? (i.e. click through to read it)

<comment><USER19> I'm not sure if HN tracks this, currently; it's pretty obvious that clicking on a story doesn't send you through an intermediate redirection page, which is the simplest way to monitor that sort of thing, but there could be some fancy javascript stuff going on to register click-throughs. It's all in the source code, of course; if you want to go hunting for it, then by all means do so.

</comment></comment><comment><USER20> I suppose this explains why my rep suddenly dropped by over 12 points today. Perhaps I'm part of a voting ring that I wasn't aware of?

<comment><USER21> It looks like you were downvoted a lot for this post: <http://news.ycombinator.com/item?id=1646903>

The karma for that post is actually less than -4, as explained elsewhere, the karma for a post can now be lower than -4.

<comment><USER20> Could you point me towards where that was explained? And why would it be less than -4 and only show -4?

<comment><USER22> PG mentioned it today actually:

<http://news.ycombinator.com/item?id=1647322>

</comment></comment></comment></comment><comment><USER16> Cool :) And thanks for keeping it a level playing field.

Once voting rings get the upper hand it would be a real problem.

</comment><comment><USER23> It'll be interesting to see some statistics on this.

</comment><comment><USER24> Quora does this by not identifying the poster, so that self-validation does not occur.

</comment><comment><USER25> Call me naive, but I thought stuff like this only happened on digg and reddit.

</comment><comment><USER26> Not worth a hacker news post.

<comment><USER27> A post concerning how the site functions isn't relevant? Dang, picky crowd.

<comment><USER26> I didn't say not relevant, I said not worth a post. The main problem with twitter is that it turns content which would normally be too light into something that seems like it is substantial.

But your quip got your 1.5 month old "drive by account" a dozen up-mods, so good on you.</comment></comment></comment>


Drupal's Golden Handcuffs - <AUTHOR> http://mikecr.it/ramblings/drupals-golden-handcuffs <comment><USER4> 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 standards look like, a lot of them don't even have a development/production separation: they just hack away on the live site with no source control or backup. And no one writes tests, or sees why they would be useful.

Some of the big professional drupal shops appear to have basically written their own cms on top of drupal, with a bunch of terrible hacks to try to make source control kind of work, and just use the drupal name basically as a marketing technique.

So glad I don't have to deal with any of that insanity any more.

<comment><USER5> 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. While it is technically possible to stuff code into the database community best practices (not to mention common sense) strongly advise against this practice. What you are describing is the system handing you enough rope to hang yourself, not it's default behavior.

Configuration lives in configuration tables.

Content lives in content tables.

"they just hack away on the live site with no source control or backup"

It would be a mistake to take the fumblings of a few scrub freelancers or interns and extrapolate that as being the norm for all (or even most) Drupal developers.

For all core modules and all quality* contrib modules there are $N_load() functions to extract these (reliably) from the database.

* With ~8000 contributed modules to choose from, quality varies wildly. While unfortunate, it's to be expected when you've got that many chefs in the kitchen.

<comment><USER6> 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.

<comment><USER5> "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.

<comment><USER6> Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed.

Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows. Assuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't), it's true that each developer could export their own version of the given content types, views, etc., and commit them to version control. The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result? All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy.

Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere (see also Drupal's "database abstraction layer" or its supposed "object-oriented design").

<comment><USER5> "Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed."

Features, exportables, Strongarm (et al) are all compatible with the workflow you're describing. Our development workflow is heavily dependent upon branching. All new feature development takes place in branches that are later merged into dev, with stable "snapshots" taken from dev whenever we do a release. Pretty standard stuff, and we use features and installation profiles heavily in our implementation work.

"Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows."

What you're describing isn't a credible workflow, it's a mess. Field declarations for a single content type strewn across multiple features? Why? Designing a content type and exporting it to code shouldn't take more than 30 minutes for even the most complex content types. If additional features are required they can be added to the feature but separation of concerns typically dictates that that code goes into a separate module. Cleaner that way.

"ssuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't)"

All of our developers maintain local mirrors of the dev environments for all of the clients they work with. This includes snapshots of the dev database. Also, how is maintaining a local copy of a database either impractical or in any way a Drupal-specific problem? Any project that includes a datastore is going to have similar issues.

"The exported blobs are pretty much opaque to many Drupal developers (or non- developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result?"

Merge conflicts happen with any workflow. Merge uncertainty is an issue with revision control, regardless of what platform you're developing in. As far as manual merges goes, I submit that any developer should be capable of manually merging simple array declarations (because that's all exportables are).

"All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy."

I think our definitions of both "code" and "trustworthy" differ greatly. Exportables aren't huge blocks of opaque logic. They're simple associative arrays. I have no problem trusting code that generates array declarations and has been tested by the core project devs, security team, module maintainers, and several thousand developers on tens of thousands of websites. Your mileage may vary.

"Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere"

100% accurate, you'll get no argument from me here.

"database abstraction layer"

My kneejerk reaction when this was first announced: DBTNG is a fucking travesty foisted onto the community by Acquia as part of a corporate play for the "enterprise" market. After a year of screwing around with it: It still a pain in the ass but with all of the bullshit going on with the MySQL project courtesy of Oracle, this might turn out to be very very useful.

"object-oriented design"

Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty.

<comment><USER6> "Field declarations for a single content type strewn across multiple features? Why?"

Sorry for the confusion; I meant lower-case "features," as in, new pieces of functionality that both affect the same kind of data, not "Features" in Drupal terms. I don't think it would be especially unusual for multiple feature branches to affect the same content type in different ways.

"Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty."

Admittedly I've been away from the Drupal community for awhile, but I attended a DrupalCon several years ago in which the argument was made in multiple talks that Drupal's design followed the object-oriented philosophy despite not taking advantage of PHP-native object-oriented mechanisms. This (old) article seems to espouse these sentiments roughly as I remember them: <http://drupal.org/node/547518> and I remember finding them to be pretty ridiculous at the time. Perhaps community sentiments have changed since then.

<comment><USER5> Thanks for clarifying. At time of writing the only two data types that are routinely and consistently cast as objects in Drupal's codebase are users and nodes. The comical thing is neither have methods assigned and can just as easily be cast as associative arrays (like everything else).

Outside of core, contrib has gotten quite object oriented over the last few years as Views, Panels, Simpletest, Ctools (etc) are all heavily object- oriented and the popularity of these modules has driven a lot of other contrib module development that in turn is required to take an object-oriented approach to interact smoothly with these modules.

Still, attempting to claim Drupal is in any way object oriented is like hot gluing a handful of feathers to a basketball and calling it a chicken.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> 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) the small number of people who can treat it as a framework and write solid custom code while still making good reuse of core and contributed modules to speed development versus (b) the much larger number of people who treat it as a sophisticated CMS with plugins, and typically use Views and template overrides to produce a fragile solution.

On the money side of things - yes, if you're in group (a), then you can charge a bunch of money. Drupal development is very lucrative. If you're in group (b), then no. That's just an average wage.

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

<comment><USER5> 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.

</comment></comment></comment><comment><USER9> Moving away from Drupal was one of my biggest steps forward as a web developer.

I worked with Drupal full time for a little over two years. I spent much of that time clicking around in config screens, and when I did have to get my hands dirty with some custom code, I usually felt like I was just stumbling around in the shadow of the behemoth that is Drupal's API. I thought, "Surely this isn't what web development's supposed to be."

Turns out I was right. On recommendation from a developer friend, I started experimenting with a bit Rails, tried a couple of "proper" PHP frameworks, and then discovered Python and its excellent web development ecosystem. That's when it really started to click for me—all these pieces that Drupal had so kindly obscured from me started falling in to place. Rather than trying to push around a monolith, I learned how to keep things lightweight and use only the pieces I needed. And importantly, I was actually writing _code_. Sweet, readable, maintainable, version-controllable code. None of this "serialize a hugely long options page and dump it all in the DB" stuff. (On a side note, learning git was another big catalyst for my move away from Drupal. D6 always felt like a pain to track in a VCS, especially when I was collaborating with another developer—though the situation may be improving.)

I should point out: I think a big part of my frustration was the fact that many of the sites I was building didn't need something as big as Drupal. I've since found WordPress to be a better fit for most of the "easy" stuff, or even static HTML/CSS if it makes sense for the project. When I'm building something more complex, well, there rarely seems to be any reason for me to use Drupal anymore.

<comment><USER10> I've been doing Drupal full time for the past four years and I'll agree 100%. People that try to build applications in Drupal are running a fool's errand. It's got a ton of code and another ton of assumptions, but that's the thing; when those assumptions are what you need and that's code you don't have to write, magic happens.

I'd say, 90% of the time, if you're using Drupal and you're in a code editor instead of the admin UI, you're making a mistake, either because there's an easier way to do what you're doing, or because you shouldn't be using Drupal. The real trick is knowing which.

</comment></comment><comment><USER11> Developing a large web application in Drupal from October 2011 to May 2012 was, by far, the most stressful period of my professional life. The most difficult part is that the vast majority of learning materials for Drupal are aimed at non-developers. So much literature is dedicated to impressing people who otherwise couldn't create a website with things like, "LOOK! You can implement access control, put a smiley face next to all comments, AND have a YouTube video feed!" that finding documentation on actual code is extremely challenging.

Another aspect of the project that was difficult was that the client had very specific needs. In almost every piece of functionality they requested, there was some wrinkle that made using an off-the-shelf module impossible. This meant having to code against the behemoth Drupal API. After about 3 months of work, I created an OO-wrapper module around Nodes called Doodal (<https://github.com/rybosome/doodal>) that makes it possible to code in an MVC-like way. This made the rest of the project somewhat easier, minus the parts that involved interfacing with native Drupal. Drupal was created at a time when PHP didn't have object oriented features. Their solution to the problem of needing OO-like behavior but not having it was to emulate it, which is an abstraction that quickly falls apart. For instance, the shortest line of PHP you could possibly write to simply print out an optional "first name" value from a node representing a person is...

array_key_exists('und', $person->first_name) ? $person->first_name['und'][0]['safe_value'] : '';

While I was wrapping up this project, a friend of mine pointed me to an opening his company had for a Drupal dev, paying about 1.8x what I was making at the time. I declined without even thinking about it, and have not regretted it for a second.

<comment><USER12> First, it's LANGUAGE_NONE not 'und'. Second, while I could go on how you should use field_get_items instead, it's very very likely you are missing some concepts here an you want a formatter, a whole display mode etc. You very rarely need that level of plumbing.

<comment><USER11> The constant LANGUAGE_NONE represents the value 'und'. Yes, using the value directly rather than the constant is bad practice, and certainly is not idiomatic in any language; I'll concede that point to you.

Regarding the use of field_get_items, check the documentation on the return value: "An array of field items keyed by delta if available, FALSE otherwise." Per my requirement of getting a single, OPTIONAL field value, field_get_items might return false, which means we are still looking at something like this overly verbose code:

($first_name = field_get_items('node', $person, 'first_name')) ? array_shift($first_name) : '';

Lastly, "you want a formatter, a whole display mode, etc. You very rarely need that level of plumbing". One of the requirements for this project was that each page represented by a person node would have a very specific layout. This meant that I couldn't rely on Drupal's default layout (even with formatters there was too much baked-in HTML that was unacceptable), and had to create a node--person.tpl.php file, i.e. a custom template.

<comment><USER12> I still say this: If your node.tpl.php contains field_get_items or equivalent, you are doing it wrong, on a very fundamental level. If the formatters provide too much HTML, write your own, write a proper field.tpl.php etc.

<comment><USER13> So in order to "print $person->first_name;", you must first create formatters, display modes, and templates? Point goes to the one who's saying that it's overly complicated. Drupal makes it easy to do difficult things, but infuriatingly difficult to do simple things.

</comment></comment></comment></comment></comment><comment><USER14> 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 little more than that.

<comment><USER15> This doesn't make sense to me either, though I haven't touched Drupal for at least 6 years.

In my experience, Drupal is ideal for cheap clients who want a zillion features but don't have the budget. You can deliver more functionality in Drupal than anything else, that is absolutely true.

For high-end clients who are willing to pay for impeccable UX and solid problem-solving, I can rarely recommend Drupal because it starts with a raft of assumptions that tend to lead to subtle compromises in the UX but would require an inordinate amount of effort to fix.

I ditched Drupal for Rails specifically because I hate being in the position where I have to explain why a seemingly simple change would require far more work than logically makes sense (to be fair, this is an occupational hazard of programming, but with Drupal it happens to an obscene degree). Going to Rails felt like targetting a higher class of client.

Meanwhile Rails developers seem like some of the most sought after programmers today. Where is this elite Drupal employment world that the OA speaks of?

<comment><USER16> It appears you don't really understand the Drupal theming layer.

<comment><USER15> You created a new account just to post this ignorant snark?

My Drupal knowledge is well out of date, but the indisputable fact that the Drupal architecture like all software architecture imposes assumptions, many many more assumptions than a low-level framework like Rails (which tries to keep its assumptions as broadly applicable to all HTTP usage as possible). These assumptions imply tradeoffs. If you think there are no tradeoffs you need to step back and realize that Drupal has corrupted your mind and the limits of your web development ability will be constrained by whatever ideas Drupal core is able to harvest and integrate from the wider world of web development.

</comment></comment></comment></comment><comment><USER17> I don't have this problem, currently. But I've previously used boring, lucrative work to bootstrap my way into more interesting work. Here are the steps:

1\. Identify what you would rather do

2\. Keep doing boring work, but part time

3\. Reduce expenses

4\. Use money from boring work to subsidize skill development in interesting area

5\. Switch to interesting area

Obviously, this only works in fields where you can get away with ~4 per day spent on your main work.

</comment><comment> at-fates-hands Okay here's my Drupal story. It starts out with me at a Drupal conference. First question I ask is this, "Is Drupal a framework or a CMS?" To which the guy running it said cheerfully, "Both!"

After building my personal site with Drupal, I realized the one thing which drove me nuts was the vast number of modules I wanted to use either had shitty documentation or none at all.

It was basically, "Install this and it works!" Which made me spend even more time either having figure out how this thing worked, or attempting to write my own.

To me, this is not a developer friendly framework. When I talk to my friends who are developers and they flat out tell you there's a STEEP learning curve with Drupal, they're not kidding.

I can honestly say I built a dealer locator from scratch faster than I did trying to figure out how do it in Drupal. Just an example of the stuff I'm talking about:

<http://drupal.org/node/38401>

</comment><comment><USER18> Developing via a GUI is good for rapid prototyping or CMS applications, but I prefer traditional coding for web applications. It's easy to change something in a GUI and not notice it. You can't "grep" a GUI to find the screen you need to access to change something (as you may need to click through several screens to get to where you want to go). Version control becomes more complicated as well: when development is defined by data in a database it's more complicated to have a staging/production setup than with straight-up code in version control. Plus text is expressive: there's a reason humanity moved to the written word from pictographs.

Performance can also be an issue as well in Drupal, depending on your use- case. Stuff based on layer upon layer of abstraction uses more memory and can be slow. "Just add Varnish" works for some use-cases, but not others.

Upgrading can be painful as well. Because third-party modules are dependent on Drupal core, when you upgrade Drupal core you also have to upgrade all your modules at the same time. For a complex site this can take awhile. If a module isn't upgraded you either have to do that work yourself, drop it as a dependency, or wait to see if the module gets updated. With less monolithic systems you can deal with upgrading components individually which can make the process more manageable.

<comment><USER19> you can use the features module in drupal and have the best of both worlds. You click to get a prototype quickly, then you export the functionality to a module with drupal and keep track of changes with git.

</comment></comment><comment><USER20> 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 computer science type knowledge in the drupal world. The result is kludgey, over-complicated, and inefficient code.

Drupal's "success" is only because it's community consists of people who don't know any better. The author himself points this out by making laborious points about how much money there is to be made propagating bad, wasteful practices.

<comment><USER5> "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 America alone.

3\. Did you read the part where the op wrote about the ridiculous amount of shit you can get done without opening a text editor? Office staff with minimal technical background can be trained to implement/manage most of it.

4\. It. Just. Works. On commodity hosting no less. Or on expensive enterprise hosting. With little or no assing around with server configuration. There are hosts that have push-button site installation.

In short, Drupal is popular for all of the same reasons that PHP still hasn't gone away after almost a decade of developers whinging that it sucks.

Is it fun to code for? Nope, not even a little bit. By the time you've written your fourth or fifth custom module 99% of it is the same tired slog through boilerplate code and hook_$N_alter() groveling. Dull, dull, dull shit. And yet I suspect Drupal and Wordpress (which is arguably even worse to deal with) are running way more websites than django, rails, and symphony put together. Look on the bright side, at least it wasn't written in Perl. :)

<comment><USER20> 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.

<comment><USER5> 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.

</comment></comment></comment></comment><comment><USER21> If you're an engineer/coder building sites by clicking buttons all day, you're in the wrong job. That's not Drupal's fault though. Drupal is a CMS - <USER2> powerful one, but not a framework..

At my work we've got a team of "web designers" building websites using Drupal. It allows them to build most of the stuff that clients want for their website/intranet, without writing code. For the more business-logic heavy applications that need to scale and continuously require new features there's a separate team of Django developers.

This approach seems to work fairly well: designers get to build pretty advanced stuff they normally wouldn't be able to without some programming help, developers don't get the boring CRUD/shopping cart stuff.

</comment><comment><USER22> Interesting article, perhaps if a few of those "I'm bored"s were changed to "I'm helping make Drupal suck less by writing some documentation" or "I'm learning cool new stuff cos Drupal does the generic boring stuff for me" the author would have a more fulfilling life.

If everyone blows a little more energy back into the Drupal project, it'll suck a lot less ;)

<comment><AUTHOR> It depends on your work environment. If your boss asks for 40 billable hours a week and you have a family to keep you busy in off hours then there's not much time for writing docs or contributing modules.

<comment><USER19> Is the same problem that every person working with free software projects faces. Can I contribute more if I'm not being paid to do it?

In the long run you can expect those extra hours contributing to the project to really pay off, because you gain a deeper understanding of where things go, because you meet people that can help you, because people see your contributions and you make connections and a lot of other goodies.

</comment></comment></comment><comment><USER23> I'm a Sydney-based UX person with a background in UI and front-end coding, and I happen to find programming (I dabble in php) extremely satisfying. Drupal, to me, is definitely a means to get things done.

Here's my "day in Drupal":

\- Amazed \- Amazed \- Bored \- WTF? \- Lunch

\- Amazed \- Puzzled \- Amazed \- FUCK YOU DRUPAL! \- Amazed

Yes, setting up content types and views can be annoying, but really, sometimes you get a view done in under 15 minutes. Including styling. Stuff like that never ceases to amaze me, and really makes Drupal worthwhile.

I could never code a cms ground-up, and the likes of cakePHP and whatnot just seem a wee bit too far down the rabit-hole (for now).

Drupal is an "easy" alternative.

</comment><comment><USER24> I have just left my Drupal job for a Rails job, pretty much for the reasons listed here... I'm certainly going to be making _more_ money doing it too.

I reckon 40 hours a week (or whatever you work) is far too many to be doing something that leaves you bored or frustrated for a reasonable percentage of the time.

</comment><comment><USER25> 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.

</comment><comment><USER26> 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.

</comment><comment><USER27> Couldn't agree more. Having built a range of Drupal sites on a freelance basis, I can confirm that you can do crazy amounts of work with just a few clicks of the mouse. The moment you realize you need to customize, however, is a dreadful one.

</comment><comment><USER28> Years ago, I wrote and published a couple of Drupal modules, which are still being used from time to time. But I moved away from Drupal. With Drupal, you don't learn about building web apps; what you learn is "tweaking" a complex system. You can be building very complex apps nicely, but at the same have no clue about what is underneath.

</comment><comment><USER29> Drupal definitely allows you to get 95% of the most common features done very quickly with contributed modules but the assessment that it shatters if you try to bend it too far is very accurate.

Also, the RESTful API is not fun to work with, mainly because the documentation for it is really lacking. It gives you all the information that you need to do CRUD on standard fields but if you throw date or file fields into the mix, you'll be tearing your hair out. It's also quite clunky and tedious to parse responses from since it responds with entire nodes which can include unnecessary RDF info or multiple languages along with field values nested 3+ levels deep in arrays.

</comment><comment><USER30> This all sounds like my $dayjob with Oracle Application Express.

Except that ... you know ... people have _heard_ of Drupal.

</comment><comment><USER31> I just spent over a month on a project where we started to use Drupal and I can't see a single thing that is good about it. Poorly written core code. Poorly written modules. Abysmal UI. The only thing I can possibly think that Drupal has going for it is a great community and, as this article mentions, the ability to make a lot of money for little work.

Needless to say, a month and a half into the project we dumped Drupal.

</comment><comment><USER32> I think author is switching _cause and effect_ :

Move a few paragraphs around and the problem becomes clear. It is right in his article!

> Drupal just isn't a great system to code for.

And _then_

> No debugging your custom code

Proper, well architectured custom code is not hard to debug. At least not anywhere near as hard as debugging Drupalcode. Due to, yup "Drupal just isn't a great system to code for."

> No digging through the docs trying to find the API function you need for an > odd task

"Drupal just isn't a great system to code for."

> A discoverable UI--click around until you find what you're looking for, > rather than digging through code

Hmm. there is a pattern here: "Drupal just isn't a great system to code for."

> A team of thousands of users and contributors testing the code in ways you > never would have imagined and fixing the bugs

Klicking Monkeys testing stuff? Where are the unit-tests? CI? They are there, somewhere in Drupal, but in reality unusable, because, yup "Drupal just isn't a great system to code for."

> A much much smaller risk of security breaches due to that team

Well, to an extend. But the most security comes from your arcitecture. And 90% of the Drupal-security-anouncements can be tracked back to, yup "Drupal just isn't a great system to code for.".

> Holy crap, so much faster

Yes. Faster then coding. But that is only true for Drupal, because, "Drupal just isn't a great system to code for.". It certainly is not faster then your average _R_ AD-framework for many, many sites. There may be some cases where Drupal is faster, but only when you don't have to write a line of code, nor need to debug and find why Module Foo and Bar don't work together, because.. well. See above.

</comment><comment><USER33> I wrote a blog on this problem for Drupal a while ago - but with a particular focus on the fact that Drupal has a 'talent problem' precisely because of what the article says (Drupal is not fun for developers and, moreover, fails to promote learning). You can read it here: <http://room271.net/2012/05/24/developers-and-drupal.html>

I worked on Drupal for ~1 year and wrote very little custom code.

The caveat is that core developers working at one of the top Drupal shops do get to write interesting code, but they are the exception rather than the norm.

ps. still a big fan of Drupal, just don't want it to be my day-to-day work.

</comment><comment><USER34> The beauty of open source is that we have the ability to learn from the experiences of others. Many of the challenges expressed in these conversations are being met head on by the Drupal community. I disagree with many sentiments of the OP but also practice integrating different technologies, when appropriate, to get a job done ... The feedback in this thread is invaluable and highly appreciated.

There are technical solutions in the form of modules and organizational workflow solutions that can be used to solve most of the issues I see mentioned here. There are also a lot of false or mis-informed assertions. Thanks for the insight.

</comment><comment><USER35> I left Drupal for WordPress because:

1\. When it breaks, it shatters—as you said 2\. WordPress's UI is so much better for clients, in my experience 3\. Theming in Drupal was a nightmare — div.class > div.class > div.class

It's such a shame about Drupal. It's so capable, flexible and powerful, but the ui is a tough sell. You can build almost anything with it, but when it comes time to theme and eventually time to hand it off to the client, that's where things got hairy for me.

</comment><comment> jack-r-abbit uh... I have never had a day when I said "I'm Bored" like that. What you describe as all the Productivity stuff that can be done with zero coding isn't really all that Drupal _developers_ do. At least not where I work. We are writing custom code/modules on a daily basis... not just "every now and then". But I guess it comes down to the type of site you're building.

But I have had my fair share of "WTF?" and "Damn it, Drupal!" moments. That much is true.

</comment><comment><USER13> 1) Drupal's great if you can accept something close to what you want - <USER3> has most (but not all) of what you want, plus some stuff that you didn't need. But if you're dealing with perfectionists who want things precisely their way, then you'll spend a lot of time and add a lot of complexity overriding, suppressing, and customizing things and gluing clusters of modules together. Sometimes more than if you'd just built what you needed from scratch.

2) Initial standup can be very quick and easy, especially if you can do it with mostly out-of-the-box stuff (see 1). But over the long-term maintenance and development can be extremely difficult.

3) If you're stuck using designs from designers who aren't skilled with Drupal, theming is likely to be inordinately difficult. Drupal provides a great amount of useful tools and utilities to designers, but if the designer doesn't use them then you basically have to rip them all out and/or override them all and the theme can grow monstrous.

4) The ability for a 'non-technical' user to do so much through the admin interface is a great strength. But the fact that there is so much there in the admin interface (scattered around by the different modules) means that non- technical users often can't (or won't) use it without a thorough understanding of Drupal and the modules. It's too complicated. So you'll need to add time to strip out, simplify, and rework the admin interface. Even then, you may still end up with programmers being tasked with content edits.

5) The database for config+content really is a big issue that majorly affects long-term maintenance and continuing development/deployment on a live site. 'Features' and exportables are not a good enough fix. They're better than nothing, but don't rely too heavily on them. They break down in a lot of cases. D8 promises to be better on that issue...we'll see.

6) Performance really is a problem. For any moderately complex and trafficked site, you have to set up proxies and elaborate caching and etc. etc. just to get "okay, I suppose that's acceptable enough" performance. It can be done, but it's a major headache. That's a tradeoff for the flexibility and modularity.

I've built scores of sites in Drupal over the years, and it's a great tool, but it's far from perfect. It's all about tradeoffs, and often the greatest strengths are also the greatest weaknesses. You just have to decide whether it fits what you need. If you can live with the drawbacks, then it's good. If not, then you'll need something else which will have it's own different set of drawbacks.

</comment><comment><USER36> I think this applies to a lot of platforms, tbh. It even reminds me of when I was a #embarrassed cough# Lotus Notes developer 12 years or so ago.

I think it might be the price you pay for using a "framework". 80% = really easy, the remaining 20% is a git.

</comment><comment><USER37> the article refers to being bored. any drupal dev who is bored because they are talented and unchallenged should be contributing to core development. the OPs d.o profile shows contribution but not focused on a particular core initiative. the employer could be giving time over for that. contribution is satisfying and challenging. and much needed!!

</comment><comment><USER38> I'm using Drupal as a back-end, and doing the fun stuff in the front-end on the client. No boring days here.

</comment><comment><USER39> Drupal is fine to code for, as long as you know what you are doing. #codemonkeylaughsatalltheclickmonkeys

</comment><comment><USER40> ...note... After Mike published the "Golden Handcuffs" post he publicly stated that he did not intend it to be so negative. [yah... I've been there. I start typing and my passion pours out and all the sudden I'm fire up like crazy] So I hope my criticism of this article is pointed in the right direction. ... here goes....

I can not begin to state how much I disagree with the conclusion of this post by @mcrittenden . I believe he feels the way he feels. I believe he has experienced what he says he experienced. But the conclusion is not a typical one. Most of us who are making tremendous earnings in Drupal are NOT bored, unchallenged and lamenting the lack of fun and elegance of coding. We are excited, challenged, evolving, stretched ppl who are having a blast with what we believe to be the BEST community associated with the BEST software out there. [yah... we're pretty biased but THAT is the enthusiasm you run into on a large scale]

I am not saying that he's lying. I believe he is telling the truth when he says he's bored and unchallenged and despises the lack of elegance. I liken that to some one who really misses their horse after trading it in for a Model-T. I get it. We did just find for a very very long long time with the horse. Horses are still used today and not just for entertainment but for very real and practical reasons. There's simply NO WAY that some one is going to have a relationship with a car in any similar manner that they did with their horse. I fully respect @mcrittenden and his position here. When ever some one goes on a rant about what they don't like about Drupal [and OH how often this happens!] I find that many of the points are valid and I can not write them off and dismiss them out of hand. Such is the case here. I will say this.... Drupal is a career and a discipline and a community. I encounter some of the same challenges that @mcrittenden does. I don't have the same reaction. I get better and better at this and I have many friends who I can reach out to. Whereas shops have a lot of BRAIN POWER in-house, we independents stick together and hit each other up with those WTF moments. Between all the DrupalCamp, DrupalCons, local UserGroups, Internet Relay Chat, Skype, Email... I'm very connected to the community and I get answers to my questions when ever I need them. If I know an area of development is going to be extra challenging.. I will factor in some room to pay my friends who know things I do not. Yah... We get freebys from each other ALL THE TIME but I really love it when I tell some one I have a couple hundred bucks to spend on them to teach me something or to architect a solution. I've even spent thousands like this before. I knew the client had needs and I connected them with another shop to handle a very specific piece of the puzzle. It worked well for all concerned. And by the way... this was FUN and Challenging and the solution was very Elegant.

CONCLUSION: I DEFINITELY run into issues with Drupal from time to time. Just like sharepoint and vignette and ez-publish and auto-mechanics and horse- handlers do. My reaction is a little different. I have made the choice long long ago that DRUPAL is my vehicle. I don't want to use Joomla like I used to. I don't want to use Sharepoint like I started to and was studying in 2007. I chose Drupal. Now that I have made that choice I am enjoying great money and great challenges and an even greater community. Our system has its quarks; some are minor and some not so minor. Regardless, this is the path I'm on. We, the community, are continuing to improve "this area" and "that area" and yes I'll even agree that some areas are getting a little worse with each release. This is no secret and I'm part of two different teams that are assessing the situation and proposing action and then encouraging and seeking funds for that re-action. We're seriously on a roll here with this stuff.

@mcrittenden I get it, man. This stuff [called Drupal] can ROYALY piss a guy, or gal, off at times. But what you describe as boredom and click monkeys is a drastically inaccurate description of what I, or anyone I know, do for a living. I do know of many HOBBYIST Drupalers who just want to point and click and they are using Drupal as an overgrown geo-cities but I know that's not who you're talking about here.

I really appreciate the article! This global conversation is sparking other conversations that are enacting change! So.. THNX!

Doug Vann [Drupal Trainer, Consultant, Developer] <http://dougvann.com>

</comment><comment><USER39> if you can't code a CMS, don't claim to be a professional at using them.

<comment><AUTHOR> Can you expand on this? How is this comment relevant to the article?

<comment><USER41> If that were the case, there would be no market for CMS. Everyone who wanted one would hack one up in Excel.

Or maybe Word with macros.

<comment><USER39> Not really, a CMS is good because you don't have to build the same thing multiple times. However, if you plan on using a CMS as a tool to create solid, scalable, efficient applications, you will need to understand how to use the CMS properly. Many times that means understand what the CMS is doing behind the scenes. Any good programmer should be able to code a project like Drupal, granted that would take time, but they should be able to do it without sweating too much. I get extremely tired of the noobs and click-monkeys taking of the drupal community. If you can't write your own decent CMS because you don't know how, you should find another job, and leave application development to people who can do it properly and give clients a product that is worth the money they payed.

<comment><USER41> You're confusing Drupal with a CMS. It's much more, and less.

<comment><USER39> I'm not confusing it with a CMS at all, it is a CMS. You can use it more as a framework, but as a framework it really kind of sucks when compared to Code Igniter or zend, or even Yii.</comment></comment></comment></comment></comment></comment>


Zero to Startup: Prerequisites - <AUTHOR> http://okdork.com/2007/07/02/zero-to-startup-prerequisites/ <comment><USER2> Here's a prereq: having enough cash to live on until you can turn a profit or convince someone to invest. That's my biggest worry right now.</comment>


Facebook Terminated Corporate Development Employee Over Insider Trading Scandal - <AUTHOR> http://techcrunch.com/2011/03/31/facebook-terminated-corporate-development-employee-over-insider-trading-scandal/ <comment><USER2> Re: the last paragraph in the article

Considering this can potentially ruin Brown's reputation, shouldn't they wait to get solid confirmation before slapping him with the 'insider trading' label?

</comment><comment><USER3> I'm really a bit confused here. If a Goldman employee did this, he'd get a $50M bonus, be knighted, and be given permanent immunity in advance by the President of the United States against all prosecution, whether related to this affair, or any others, past, present, or future. If a hedge fund manager did this, same thing. If any Republican politician did this, same thing. But somehow, if it's a tech industry employee, or (of course) anyone in the bottom 99.5% of the class structure in the US, they get fired and/or jailed.

<comment><USER4> Have you heard of the term "libel" ?

Insider trading is a criminal offence, if you're going to accuse a company of advocating it you should probably have solid evidence.

If you wanted to make a general point about how you think investment banks are unethical, then use the term investment banks.

Naming a real company and accusing them of illegal behaviour just to make a point isn't a good idea.

<comment><USER5> I think you are being just a _bit_ over sensitive....

<comment><USER4> Imagine instead of Goldman the OP would have said "YCombinator", how fast do you think it would have been downvoted ?

You can't have one rule for companies you like and another for companies you don't.

I like many HN'ers am a startup founder, I'd be horrified if someone baselessly accused my company of advocating criminal activities. I don't care if the company being wrongly accused is Goldman, Microsoft, AOL or some tiny startup. Wrong is wrong.

While such behaviour might be tolerated in other online communities, it should have absolutely no-place on HN.

<comment><USER3> You're just being obtuse. I didn't wrongly accuse Goldman. I _rightly_ pointed out past abuses which Goldman has carried out. Do you not read the news?

And yes. You most certainly can have one rule for companies who are multi- billion-dollar bad actors, and other rules for companies which, well, aren't.

This isn't complex.

</comment></comment></comment></comment></comment><comment><USER6> Take everything posted by TechCrunch (and all news websites) with a big grain of salt for the next 24 hours.

<comment><USER7> Arrington is a lawyer. These are serious allegations. I don't think he's stupid enough to float something like this as a joke.

<comment><USER4> After the Calacanis lawsuit and the Techcrunch Tablet lawsuit, I'm not entirely convinced Arrington applies his legal skills in his business dealings.

</comment></comment></comment><comment><USER8> Well, if the article is not an April fools joke then its a leap to claim that this is "Insider Trading". The term specifically applies to public companies and not to companies in general. This distinction is not a "footnote" in the article, it is the fact that negates the entire article.

<comment><USER4> Insider trading cases in the US have been bought under SEC Rule 10b-5 which reads:

      To use or employ, in connection with the purchase or sale
      of any security registered on a national securities
      exchange or any security not so registered, or any
      securities-based swap agreement (as defined in section
      206B of the Gramm-Leach-Bliley Act), any manipulative or
      deceptive device or contrivance in contravention of such
      rules and regulations as the Commission may prescribe as
      necessary or appropriate in the public interest or for the
      protection of investors.

(source: <http://www.law.cornell.edu/uscode/15/78j.html#b> )

Note in particular the line "security not so registered".

Trading in private companies can be considered Insider Trading.

</comment></comment><comment><USER9> I'm gonna stick taking everything on the internet with a grain of salt today. We really do need a safe word for "real news" for the day.

</comment><comment><USER10> Or maybe not, since the sources conflict.

This is not something you write without being 100% sure.

</comment><comment><USER11> Sincere question: has anybody ever punked a journalist as an April Fools prank?

<comment><USER12> Facebook released "Fax this photo" feature to a specific subset of user IDs. [http://techcrunch.com/2009/09/10/yeah-ok-so-facebook- punkd-u...](http://techcrunch.com/2009/09/10/yeah-ok-so-facebook-punkd-us/)

<comment><USER11> Oh right, I remember that. Thanks for the link.</comment></comment></comment>


Warren Buffett Live Q and A with the Levo League - <AUTHOR> http://www.levoleague.com/officehours/warren-buffett

<comment><AUTHOR> Looks like I submitted too late to catch this live, however, he'll still be answering questions on his profile throughout the month. <http://www.levoleague.com/warrenbuffett></comment>


Guide to Sending a Google Voice MMS, maybe - <AUTHOR> http://www.burnerapp.com/gvfail

<comment><USER2> HA! I can't even get Google voice to work normally without dropping calls or missing calls while forwarding... Let alone send an MMS</comment>


Blame FriendFeed - <AUTHOR> http://www.techcrunch.com/2008/05/24/blame-friendfeed/

<comment><USER3> Can somebody translate this to English? I can't tell what parts are sarcastic, and I can't decode the cryptic in-jokes.

<comment><USER4> Translation (as I read it):

Twitter was down due to a bug in their Jabber APIs.

Although FriendFeed does not use this API, I obviously don't know that, so I'll pretend to act smart and smugly blame them for Twitter's downtime.

Also, FriendFeed has nothing going for them minus Twitter. Forget about their 34 other supported services, evangelical community, and the fact that we already proclaimed them this years Twitter ([http://www.techcrunch.com/2008/03/14/friendfeed-is-this- year...](http://www.techcrunch.com/2008/03/14/friendfeed-is-this-years- twitter-but-why/)). Yup, nothing.

Now if you'll forgive me, I must return to sucking on the teat of my God that is Twitter.

In other news, I am high as a kite.

<comment><USER5> Nice try at playing Mark Pilgrim - evidently you disagree with the article. You're right that Friendfeed probably doesn't use the Jabber API, but what else is wrong about it?

I don't use friendfeed, but whenever I see friendfeed widgets on people's blogs, they have nothing but Twitter messages and RSS entries - I can get those elsewhere, with no trouble at all. If Twitter blocks friendfeed, what else do they have going for them?

<comment><USER4> So, I don't think I'm really the most qualified person to answer this question, as I don't use Twitter at all (I do understand the potential value of it, but I think the fanaticism surrounding it is beyond silly) and have only recently started to scan FF (sometimes I'm able to pick up a cool link or two with minimal time investment, which is good).

I disagree with the post because it contains over the top sensationalism, misinformation, and trivial matters -- not because I've a FF evangelist like some others noted in the post.

Those things being said, I do think they have a few things going for them (Disclaimer: I was interested in interning there this summer, but had committed to a position by the time they got back to me):

Minus Twitter, they're still supporting 34 other services. (<http://friendfeed.com/about/faq#services>).

Their team seems pretty strong if you ask me, or anyone with a clue (<http://friendfeed.com/about/team>).

Some people obviously like the service (<http://siteanalytics.compete.com/friendfeed.com/?metric=uv>).

There's a few other things but honestly, to me, by and far the strongest point about FF seems to be their vision as a content discovery service (<http://mashable.com/2008/03/25/podcast-friendfeed/>). They're gathering a lot of data, and while it may not seem very useful or valuable yet, I think when they work it all out, it will really be something special. You might want to read Paul Bucheit's (one of the co-founders of FF + Gmail creator) post on this ([http://paulbuchheit.blogspot.com/2008/04/power-of-links- and-...](http://paulbuchheit.blogspot.com/2008/04/power-of-links-and-value-of- global.html)).

To be fair, I do think they have a few things going against them as well:

Out of the box, there's way too much noise on the service right now. Although they've given users fairly good tools to deal with it (Subscriptions, Likes, Hiding, Views, Rooms, etc.), it's still not good/easy enough for most users. I just want to see interesting content without any work or knowledge on my part. Even simple things like sorting by most likes or most comments (or some sort of magic 'ContentRank') would go a long ways. They are working on this, so we'll see how it goes (in the meantime, you could check out <http://friendfeedlinks.com/>, but it doesn't seem very satisfying to me because it's only for the link/digg entries of FF).

Facebook seems to be trying to get in on this space by integrating external services (<http://mashable.com/2008/05/23/facebook-friendfeed/>) as well as their upcoming profile re-design: "As part of the redesign, Facebook is dramatically playing up the role of its News Feed" (<http://news.cnet.com/8301-10784_3-9949475-7.html>). To be fair, they are in slightly different groups (Subscription Model vs. Friend Model - <USER2> Open vs. Relatively Closed), but FB still poses a very big threat (not to FF's current user base, who all seem think FB is old and lame, but to their potential future user base).

To get perhaps get a more qualified (though obviously a little biased) perspective of what they have going for them, you might want to check out what some of their users think: <http://friendfeed.com/e/cf6b48c8-29d8-11dd-92fc-003048343a40>

P.S. You note that when you see widgets on people's blogs, they're twitter loaded. This makes a lot of sense if you think about it, I mean how often do you post photos on Flickr versus sending out a tweet? Again, this is an issue with noise. You'd probably be way more interested in their non-tweets if only they'd show up.

</comment></comment></comment></comment><comment><USER6> The difference between TechCrunch posts such as this and Valleywag: at least Valleywag don't take themselves too seriously.

<comment><USER7> What should I do right now? Should I do some hacking or write "Why not to get on covered on TechCrunch"?

<comment><USER7> Hacked a tiny embeddable slide show.

</comment></comment></comment><comment><USER8> Where do I sign the petition to ban *crunch posts on HN?

<comment><USER9> You'll find the petition here: <http://news.ycombinator.com/newest>

or here: <http://news.ycombinator.com/submit>

to get other content to the front page

</comment></comment><comment><USER10> I'm not a big fan of Mr. Gillmor, but some of this was nearly cogent, and even funny.

And it seems to me, the fact that friendfeed is entirely parasitic makes one wonder how it can survive once it actually starts to compete with the sites it aggregates. Of course the same thing could have been of google once upon a time.

<comment><USER4> I don't know, maybe by perhaps driving traffic back towards the original site? Yeah, I think that's how it worked for Google (and all other services that have APIs). You might even have heard of the little known market known as SEO these days (or in more familiar words: parasite baiting).

<comment><USER10> "Perhaps" is a good word. Not to be snarky, just that the result is still in doubt. You have to be large relative to the sites you're aggregating to "drive" traffic.

<comment><USER4> It seems like it's really just a matter of personal semantic interpretation to me. Did Hacker News not drive some traffic to TechCrunch as a result of this post? How much bigger must Hacker News be relative to TechCrunch for it to begin "driving" traffic as opposed to some other verb? According to who? Either way, call it whatever you'd like, but the point remains that driving/sending/adding/creating/dispatching/routing traffic and/or increasing visibility is what these "parasites" have going for them. Whether or not that's worth the cost of letting them "leech" is debatable, but I'm going to go with yes given that people keep on cranking out APIs.

P.S. Since you didn't seem to notice, "perhaps" was sarcasm on my part. FriendFeed will most certainly create some additional traffic and/or visibility for the sites it "leeches" off of. It is important, however, to note that traffic != visibility. Sometimes times visibility detracts from traffic because there's no need to visit the source (i.e. Google Maps, YouTube, Scribd, etc.) but other times it creates traffic because the source provides added value (i.e. Thumbnails -> Larger Image, HN Links -> Stories, etc.). It's also worthwhile to note that the former (increase in visibility, decrease in traffic) still has benefits, as your service becomes more well known (creating future traffic). I'll leave you with this: <http://friendfeed.com/e/d1ffcc73-040a-5609-6168-993c4549591a>

<comment><USER10> There's one rather large difference between Hacker News driving traffic to Techcrunch, and FriendFeed driving traffic to twitter. Hacker News doesn't actually scrape techcrunch or get it's content via an api.

From a practical viewpoint (and this is why I used the word parasite - not to be pejorative, but to indicate that FF is entirely dependent on its hosts), Friendfeed could be shutdown tomorrow by the sources. If they're using APIs, then just about every api out there is for non-commercial use, and if they're scraping, then an appropriate robots.txt, backed up by IP blocking and lawyers, does the trick.

</comment></comment></comment></comment></comment><comment><USER11> TechCrunch didn't exactly have a high bar for technical knowledge before, but Gillmor is definitely lowering the bar. He's the John Dvorak of web 2.0. He's perfect for TC's style of throwing shit up against the wall and not linking (and possibly blocking) anyone that refutes it.</comment>