eaton

DXP: When you have nine products, one logo, and a hundred salesbros.

I see you, and feel seen

FWIW, the "Drupal should be a framework" vs "Drupal should be a web page management tool" issue wasn't a matter of ignorance in the community as much it was a point of contention — there were fairly high-profile talks at Drupalcon as early as 2011 hitting on that very issue, and some of the linguistics stuff you mention was coming up in core conversations not much later than that. (Source: Was the crazy guy ranting about content-as-a-languagelike-system-of-communication in many of those conversations. Whew, DITA. Memories.)

The challenge, I think, is that by that point in time Drupal had gone through its first big popularity explosion, and was starting to grapple with the competing interests of many different audiences. Acquia ended up being instrumental in steering it towards "enterprise sites with complicated UGC requirements," but for quite some time the open source ideal of "the project reflects the priorities of the people who contribute time to it" meant it lacked a strong, opinionated take on many of the things you mention.

For many years Drupal's strength was (IMO) that enough of _those folks_ existed in the community to ensure you could build complex, highly adaptable structured content systems with it... and enough of _those other folks_ existed in the community to ensure that there were click-together content display and delivery tools that worked with the complex content. If you approached it with a clear understanding of where some of those boundaries were, you could build really amazing things — but if you came in looking for a well-paved path to build a simple site or architect a complex one, well... ¯\_(ツ)_/¯

edit -- clicked on your profile and read some of your posts in other threads, and I feel like I should just get a beer and commiserate with you about doomed CCS initiatives for a few hours. I salute you.

The belief that somewhere, someone else will do the hard stuff?

if you’re planning to be a top 10 site on the internet, you’ll need a custom stack

To be fair, that's the case with pretty much any CMS. Even if they start with a stock system, by the time they actually hit top 100/1000 (let alone 10) there's a lot of custom work to be done.

And realistically, a "top 100/1000 site" is almost always going to have a cloud of other sub-sites and related properties. The corporate site, intranet/HR, jobs and recruiting, press center... The penumbra of "Oh, yeah, we need one of those... but it would be ridiculous to build it from scratch" sites for a large organization can be pretty large indeed.

I've been doing software professionally for about thirty years now, and what's interesting to me is that the conversations I had with my grandfather about factory work involved all of the same dynamics. Prototyping new solutions versus consistent reproduction of known solutions? People who only understand their own tasks versus those who have a holistic understanding of the components, the process, and the final product? Troubleshooting unexpected failure states in complex systems and fixing mission-critical problems that can make or break the business, versus checking out when The System Breaks? Conflicts between book-smart college grads and grizzled vets who know how things "really work" under the hood?

Those are the stories he told me about working in a factory, and frankly the lessons I learned from him were just as valuable as any "fifteen lessons for software architects" books our industry has produced. Sure — software is unique! So is food, so is metal, so is film, so is concrete…

People don't deserve unions because they're 10x workers. People deserve unions because they're workers.

Unions don’t exist so that people you consider unskilled will get raises. Unions exist so that people who sell their labor can cooperate to influence the conditions they work in.

If you consider nothing more important than your own individual compensation, and have absolute faith in your own irreplaceable genius, it’s easy to make a case against unions — sort of like “there is no prisoner’s dilemma, why would I ever cooperate?”

This reminds me of mirror-universe conversations I've had with executives about developer experience for APIs. If an API functions and is technically capable of performing all of the operations that are business-critical, it works and is good; why complain? "Developer Experience" is just a fluffy, hand-wavey kind of mysticism that's so subjective no one can be expected to care about it!

And yet.

I really do love the fact that mass deportation and the digital equivalent of building codes are being treated as equivalent. Peak HN.

The whole post boils down to: "HTML is bad because it has scope creep and people use it for bad things, but PDF is good because I made this particular document in a way I like for a use case I prefer."

You do you, man! Some people run Archie servers, some people create a directory full of PDFs.

If a fire has burnt out, it can’t deliver any warmth anywhere, not just at some things.

You're putting a lot of weight on the mechanics of "burning," but the physics of combustion are an analogy of convenience, not the diagnostic criteria.

One of the reasons that "burnout" applies particularly to work rather than hobbies or recreational pursuits is that people (generally speaking) can't afford to just walk away from their job and return when they feel like it.

Trying to act like just because they aren't all a scam doesn't mean there isn't a systemic problem of waste that still needs to be addressed

No, of course not. But it's undeniable that these threads on HN (and other engineering-dominated forums) always include a healthy dollop of "I'd have done that better, because I'm a good software engineer" disdain. It's often paired with ignorance of how large-scale enterprise and government contracts and procurement work, what roles are necessary for large-scale projects with a significant discovery component, and what the planning process looks like when a team can't afford to launch-and-get-feedback or fail-fast-and-learn their way to a full specification.

I mean, this Deloitte project and the rollout are clearly a shitshow on a million levels. They got a no-bid contract for an eye-popping sum, then more than doubled it before the building even started! But the approaches boldly prescribed in most of the comments here wouldn't have produced a working system at the scale needed, either — only a cheaper broken one. A cheaper failure is still a failure.

Heh. That stuff has always felt like an inexplicably weird trope, like Hackers-inspired visions of computer people as living Mondo 2000 articles.

After 8 hours in a windowless conference room with a parade of stakeholders, making RACI matrices on a stained whiteboard and scarfing down cafeteria sandwiches during "bio-break," I want to _talk to my wife on the phone then stare blankly at the ceiling_, not go out for a night on the town.

One of the biggest challenges for large orgs is that the knowledge they need to do a given thing is almost always present inside the organization — but it's fragmented and scattered across different teams, roles, and balkanized administrative boundaries such that the big picture is almost never available.

A high-quality consulting partner works to build the relationships and internal lines of communication that are necessary for the client organization to do more of the work — maybe all of it! — in the future. A cash-grab consultancy will just make themselves the organization's "glue" and bill until the money runs dry.

I'd never in a million years argue that Deloitte did an awesome job on a large government contract, but it's mind-boggling to watch the regular ritual of HN posters blithely insist that anything more over $20K and a pile of pizzas for government infrastructure is a scam.

Statistically, though, that's what the people in this thread are saying — that the majority of the projects in ML/AI are destined to fail because they're BS with unrealistic goals.

"Personalization" is in a similar place for digital publishing; everyone wants it, products and services carry big price tags, and few organizations want to invest in foundational work or simple, iterative improvements. So they swing for the stars with unrealistic goals like "micro-targeted messaging perfectly tailored to every visitor, no matter where they are in the customer journey" and the results are predictable…

I take the increasingly grim accounts of project failure rates from analyst firms as a good sign — they can be used to sober up executives with unrealistic dreams.

Technically not a slippery slope, just a false equivalency. Renaming a branch and rewriting a project in another language are in no way equivalent levels of effort, so comparing them based on the principle of "no skin off my back" the original poster articulated is disingenuous.

Saying that the two cases are not equivalent is a criticism of the level-of-effort comparison, not a criticism of a particular people-group's subjective suffering.

Let's say I'm standing in the aisle at the grocery store, and someone asks me to step aside so they can pass. It takes minor effort on my part — inconsequential but more than simply standing there — but makes things better for them. Is simply doing so a defeat? Have I been defeated? Is saying, "Yeah, I'd move a step or two to the left, no biggie" defeatism because the movement does not bring "measurable personal gain" to my life?

That feels like a sad, thin way of living life.

This is what's felt disingenuous about a lot of the pushback energy, at least to me. The conflict is framed in terms of: "People who say they'd be more comfortable if X were changed to Y," and "People who say X vs Y is meaningless… but spend inordinate amounts of time arguing that branch changes and other relatively inconsequential change is _literally the death of freedom_.

If it doesn't matter, it's low-effort, and the change results in an environment that's more comfortable for some people, it seems like a pretty straightforward equation. Anyone who wants me to oppose that kind of change is implicitly arguing that it does matter, and the current state is the better one… without bothering to make a case for it.

That is the tweet of a man who slept through 2014.

Biased nerd here: I work for Lullabot and have been adjacent to a number of projects that used Tugboat for client QA and approval over the past year or two. While I can't speak to the implementation details, I can definitely say that the emphasis on automatically spinning up per-pull-request/per-feature demo instances of fairly complex sites and linking them from the PR tickets has made review and approval by nontech stakeholders way smoother.

I'd be interested in knowing if there are any other CI or CI-adjacent tools taking that approach, especially with non-LAMP hosting stacks?

It's called GodTube.com, and it's terrible.

That's really the crux of the problem, isn't it? If the organizer of a conference decides not to give a platform to neofascists who want to end democracy, they MUST also bar women who are being harassed by *chan trolls.

There's simply no way that a conference organizer could possibly handle those situations differently without being a hypocrite.

Some scumbag got a guy fired by publicly shaming him on twitter for making a joke to his friend in a private conversation. That is one of the most hostile, weird, and hateful ways I've ever seen someone behave.

A conference attendee overheard another conference attendee making dick jokes in a public space at a conference, violating the terms of the CoC that he'd agreed to before attending. She reported him and posted it on her Twitter feed, complaining about it. He was reprimanded by the conference organizers, and apologized

When he returned to his work, he was fired—and he immediately posted to HN that she'd gotten him fired. He found a new job, while she was subjected to two years of personal threats, identity theft, employer-targeted DDoS attacks, and chan grief. She still is to this day.

If you think that reporting someone for violating an conference code of conduct is the 'most hostile, weird, and hateful' way you've ever seen someone behave, you aren't watching very closely.

"The fact that a lineup of white male speakers (because a majority of programmers are male) automatically makes you think that it is an INTENTIONAL act by the event organizers..."

--

You're missing the point. The concern expressed about the predominantly white-dude lineups at popular conference IS NOT that individual conference organizers are purposefully excluding non-white-dude speakers. The people talking about these issues generally go out of their way to explain the difference between INDIVIDUAL bias and SYSTEMIC bias. The latter is not a matter of a conference organizer saying, "Hey! Let's make sure we don't have black speakers!" Instead, systemic bias is the way the status quo of a particular group or culture leads members to make assumptions or automatic decisions that UNINTENTIONALLY exclude certain people.

Think of a web developer building a new site. All of their friends use iOS, they use iOS, and although they don't have anything against Android, their unexamined default assumptions will steer them towards building the mobile version of the site with iOS in mind. Some Android users might still use it, and even get a lot out of it, but many will also be lost to bad UX collisions, mistaken assumptions about browser feature support, and so on. The result can easily turn into a spiral: Android users don't use our site, so working to support them would just be platform zealotry!

A stretched analogy? Perhaps. But it's an example of how unintentional assumptions can leave important groups of people -- with lots of really valuable stuff to contribute -- out in the cold unless work is done up front. It's not about tokenism, or quotas, or assuming bad faith and evil intentions. It's about keeping our eyes open, and listening when people say we're missing something important.

Yes, but I'm ashamed to admit it to my friends.

Once again, you're veering into "No True Cathedral" territory here.

The UNIX design philosophy -- small utilities loosely joined into a coherent whole -- is a coherent vision for a platform, under the definition you've repeated. And the Microsoft Office design philosophy, if what you're saying is true, is a bazaar because it's "incoherent."

If the UNIX ecosystem is a Cathedral and the Windows ecosystem is a Bazaar, I think we can safely say that you're not using the words that way the classic essay used them, and that the definitions you're using are malleable enough that any argument about aesthetics could bend and twist them into synonyms for "stuff I like" and "stuff that annoys me."

Maintaining disguises on the internet is freakin' EXHAUSTING. We're too busy trying to get a roadmap for the next round of refactorings ironed out. ;-)

http://drupal.org/node/1224666 http://drupal.org/node/1273344

Perhaps you should listen to the core developers who started this debate, when they explain what's burning them out? For better or worse, architectural decisions in Drupal's past have resulted in very large workload for a relatively small number of developers, and great pressure from others in the community to "Keep the system running" in the face of numerous feature requests and so on.

There's a difference between "Let's turn Drupal into an architectural masterpiece" and "Let's refactor some of this stuff to make it more manageable." Drupal has long had a culture that devalues planning and deliberation while glorifying the "firehose of code." Attempts to iron out the best path for a complex change can only go on for a few days before they're shut down with cries of "Talk is silver, code is gold!"

Obviously, the other extreme -- endless unresolved attempts to come up with the "perfect master plan" -- is just as unproductive. But there's a healthy middle ground that needs to be maintained for a project of this size to avoid crumpling under its own weight.

>> Frankly, I think that the majority of the current problems would be solved by trimming all of the fat from the core.

The challenge, of course, is that everyone has a different definition of "Fat" versus "Muscle." The developers who actively maintain the codebase are a tiny, tiny percentage of the overall community that uses it. Many of the features that are frustrating and annoying to maintain are popular among the non-developers who use Drupal for site building.

Balancing the usage needs of those people with the maintenance woes od the developers is one of the big challenges.

The other is dealing with the identity crisis you describe; the lack of willingness to focus on a manageably small set of use cases or target audiences became a real problem once Drupal's growth curve started swinging up around 2007 or 2008. Now, simply declaring that things are "more focused" will orphan large numbers of users who came on board and started doing their own thing with Drupal while it was less focused.

It'sa conundrum.