[dnautics]

The hatred for atlassian products, IMO, has a root cause in a few facts:

1) it's an enterprise product, so the typical enterprise issue of: it's not being sold to the users, the people who it's being sold to don't have to feel the pain, and checking off features is more important than UX.

2) that said, it's not the worst enterprise. It is possible to configure atlassian products to have a really smooth UX (can't say the same about speed, the last I used atlassian, it was really, really, slow though that may have changed). However, wrangling the product (and its users) is almost a full-time job, and atlassian is known to have breaking transitions that mess up your workflow with no recourse to go back to classic. Change management is hard.

3) a lot of higher ups who make the choice of using atlassian even if they are technical and once were a user of atlassian products, used it in an era where it was simpler or worked in an environment where they were privileged enough to have a full-time wrangler from 2)

[jerf]

You don't understand the hatred for Atlassian until you've been around long enough to notice there's a cycle: 1. We hate X. 2. "Here's a lightweight replacement Y for it!" 3. Lightweight replacement Y is forced by the problem space to become as big as what replaced it. 4. We hate Y.

I'd guesstimate the hatred for Atlassian productions is about 75% simply the fact that anything that checks all the boxes necessary to become the enterprise standard will be something that is big and bloated and hated by the users, because Atlassian is merely the latest in a long line of systems hated by people.

Which is not to say anyone should change their mind about the product. Just bear in mind, there isn't anything better that, if it did somehow unseat Atlassian, wouldn't have exactly the same problems in 3-5 years. The problem is the problem space, not the solutions. I mean, sure, I'd like Atlassian to be faster and I suspect there's some room for improvement there, but even if they put a lot of work into it the problems would remain. The problem is that everyone thinks they mean the same thing by issue management, but when you sit down to actually see what that means, it turns out to be the leading bug tracker or wiki means you actually have to be a meta-bug tracker or a meta-wiki, and that's never going to be a great product.

[indeed30]

As my career progresses I find myself increasingly leaning towards opinionated tools that sell a methodology more than flexibility, for exactly this reason.

[ethbr0]

This is fundamentally a sales problem, more than a constant.

New large customer X wants feature Y. Your product does not currently Y. What do you do? It's hard to say "No." Especially when you have growth to maintain, revenue targets to hit, VC to please, etc.

To me, "opinionated" means "have a vision of what the product is and isn't" (that is strong enough to counter-balance sales pressure).

[terrortrain]

I completely agree with this.

At a few of the start ups I've worked at, "no" wasn't in the dictionary.

It was always a dumpster fire, the product had some many configurations and options. There were entire sections of the apps I didn't know existed. I think that all these features are ultimately what killed the start up.

At one point I (developer) had to go on a call with a customer to tell them no because the PM didn't want to disappoint the customer.

Learning to say no is extremely important for startups.

[atatatat]

Customized branch, supported at xxxx or xxxxx or xxxxxx per year.

[mattbuilds]

Yea I want tools to be similar how I write programs. Solve one problem and solve it well. If you need more functionality, write another small program for that problem and integrate.

Integrating can be tricky, but having one tool try to do everything usually means it does nothing well.

Ideally we will see more effort spent on straightforward, opinionated tools that allow integration. That’s my hope at least.

[azalemeth]

I hate Confluence infinitely less than I hate Sharepoint -- which is also mentioned in the article. Both of them market themselves as filling the same corporate overlord niche role. One of them even vaguely succeeds.

[prepend]

There’s a few products that I feel bad for the devs and people associated with. I really feel bad for SharePoint devs because it doesn’t seem like it should be as horrible as it is.

Like everything simple (let’s make a wiki tied to AD) is twisted around to make it complex and confusing so it’s lock-in forever.

The per user cost for SharePoint is like $100-200/year. Think about that for a minute. That’s really high for a wiki. And cheap for an enterprise knowledge workflow. But it sucks so hard if you want users to create, collaborate, and share info.

[CoastalCoder]

Not disrespecting your pain, but I'm guessing you never had to do serious work in Lotus Notes.

[prepend]

Good point. The last time I used Lotus Notes was 2010. I hated it, but it seemed to be constrained to its e-mail nightmare world. SharePoint, since it’s nominally web, gets stuck into everything.

Comically, SharePoint makes me tolerate Confluence and Salesforce more.

[atom_arranger]

Atlassian acquired Trello 4 years ago. Still seems to be doing better than Jira is, although I feel it’s maybe still slightly worse than when it was acquired.

I imagine if a company using Trello wants more features they probably just say “use Jira”.

[wly_cdgr]

There's no need for nuanced analysis. The root cause of the hatred for Atlassian products is that they are utter shit

[quacked]

Completely agree. Jira theoretically could be used to be good, but it's an absolute nightmare to use. Totally inconsistent and muddled UX. Awful graphic design. Worst of all, completely bugged-out word processing, which is the entire point of Jira

[gjvc]

the fact that the wysiswyg text editors are not the same between Atlassian products was the giveaway sign to me. They are clearly shipping the org chart, like everyone else.

[dbbk]

The editors are not even the same between screens in the same product. The task description field uses one editor for the Create Task screen, and a different editor for the Edit Task screen.

[quacked]

I hate them, but I almost can't blame the devs. It's extremely difficult to ship anything today at scale without justifying it to extreme growth-focused investors. I bet every single time someone has the chance to say "no, let's slow down and refine this", someone else points to the revenue and contract targets and hits "deploy".

[digitalsushi]

I'm not defending Jira but I heard someone once say that Jira is ugly cause it's a mirror and you're a corporate process

[quacked]

That is extremely true, but I think it's ugly on a screen-to-screen basis. Random text justification, no distinction between editable and non-editable text, various shades of boring/corporate off-white to distinguish sections of the screen, and literal bugs in the software, like you make a table and then when you save the ticket it changes your lower 5 rows to columns in a single row.

[axlee]

What's your preferred alternative for medium to large teams?

[quacked]

That is a good question. It depends on the circumstances and whether or not you're doing highly-regulated and auditable work (medical software, spaceflight databases) or more improvisational free-market stuff (video games, non-essential chat platforms).

Overall, I think my preferred method is to deliberately choose to implement about 15% of Jira's possible functionality but also rigorously define how that functionality can be used used so it's consistent across your entire organization. For instance, Jira has release versions, fix versions, labels, ticket types, summaries, custom fields, etc. However, most of those are really just "other ways to slice the data"., and total freedom allows people to create non-set-complete ways to slice data.

As an example, let's say that I have a list of 400 things--bicycle, pear, jar, cassette tape, ennui, Aristotle, 2. Our Chief Philosophy Officer wants to be notified on any tickets pertaining to philosophy, so he tells our division to tag all philosophy-related tickets as "philosophy" and then starts assigning his own grad students to analyze them.

Well, we just added the "philosophy" tag, implying "a type of label that discusses the academic content of the ticket". Do we have other tags that fit into that label type, like "history" and "science"? Where's the list of possible entries of that tag type? Where's the list of all tag types? Where's the list of all possible tags? What do they mean? Where are they defined? When do I use them? No one knows, because no one has the authority to know, we just keep growing and shipping or else we get the hose again.

By solving a momentary problem--Chief Philosophy Officer wants a set of tickets to look at--we have invented yet another fractious method for looking at an incomplete set of tickets that doesn't actually apply to every ticket, and our Jira ecosystem gets more unwieldy and less complete.

I would instead prefer to either turn the ticket tagging feature off entirely, or I would prefer that the Chief Philosophy Officer not get to dictate what tags are created and instead go through the Tagging Authority Team, which dictates what tags exist, how they can be used, and ensures that all tickets are sortable and categorizable, and well-defined, and self-consistent, and set-complete, and also they version their definitions so you know if a ticket was created under v1.0 of the Jira best-use architecture or under v3.6.

That's why I mentioned earlier that it depends whether or not your team is doing something highly regulated. Anyone who's gone through a detailed software audit from a governing body is thinking either "yeah, we had to deal with this problem" or "man, I should fix our tags". Anyone who can just bang out release versions on any schedule serving any customer would think "that is a ridiculously stupid waste of time, I love tagging anything and forgetting about it, because I only need to worry about the feature for X weeks before we're on to the next thing".

[gooseus]

Bitbucket is mostly fine, though we seem to be having trouble with it every week nowadays.

However Jira is the worst product I've been forced to use at work since Lotus Notes. If my hatred for JIRA had mass I would collapse into a black hole.

[dnautics]

Well yeah but maybe there's something to learn from it... Or at least prompt some soul searching about the question of "how do I build an enterprise product that doesn't eventually fall into the cesspool of shit"? Is it even possible?

[creshal]

As addendum to 1, this also means it's often seen as the technological hammer with which to get rid of organizational problems, without having to put management effort into solving them first. That can't not end in tears, no matter which particular hammer is directed at your thumbs.

[gregmac]

I think this is what drives a lot of the workflow usability issues with JIRA.

A bug not being tested fully, a developer working on a ticket that a PM didn't approve, a fix with no time logged... these are organizational problems. Yet the JIRA hammer lets you "fix" them by restricting workflow actions to certain users and making dozens of custom and required fields.

The result is a downward spiral: people avoid using it because it's painful and always getting in the way, which means no one puts extra effort in to link tickets together, write good descriptions/comments, or fill in non-required fields. The whole system becomes less useful overall, and in the worst case causing more workflow rules and required fields to be added.

It's sad, because JIRA can be good (though: slow). JQL is awesome if your tickets contain good data (after all, garbage-in garbage-out). It's very possible to have well formatted content that's easy to read. The "screens" customizations for transitions can make things faster by showing useful fields at just the right time. And the automations possible by integrating with PRs and builds can save even more time and prevent mistakes.

But all that can (and is) horribly abused to make something that is awful.

[ethbr0]

Well said. One of the better companies I've ever worked from had a strong "pull culture" for this reason.

Aside from the very rare exception, IT (and IT leadership) was prohibited from pushing tools onto users.

They built tools or sourced and implemented products, and users either adopted them or didn't. This seemed to create a much healthier adoption and feedback loop.

It's ironic that companies praise free market capitalism... and then internally implement command economies (and are flabbergasted by the resultant inefficiencies and supply/demand mismatches).

[dnautics]

> It's ironic that companies praise free market capitalism...

https://en.wikipedia.org/wiki/Theory_of_the_firm

Note that in "theory of the firm" language, there is a distinction between "markets" and "free market". The "free market" is broader, and subsumes the firm because you have a choice to participate/not participate in any given firm; but it is generally true that within firms you do not operate under market dynamics, and "theory of the firm" seeks to answer both descriptivist and prescriptivist questions about when firms do/should use markets.

[ethbr0]

Neat! Thanks for the pointer.

When set in that basic language, I guess my observation was that companies unnecessarily increase internal transaction costs by overly distancing internal buyers and sellers (which I guess in turn forwards into Managerial and Behavioural critiques and explanations, as to "why").

[kstrauser]

My main complaint against Jira is that it seems to poke the wrong parts of the brain for the wrong type of project manager. It's... fine... on its own, but something about it seems to call out to the hyper-detail-oriented micromanager that makes them want to make 23-step story status workflows. I've come to appreciate opinionated tools that want you to use them a certain way. Even if they prevent me from using them exactly like I'd want to, they also prevent the nightmare PM from using them exactly like they want to.

[ethbr0]

I understood PMs-from-hell when I finally realized that their work product is detailed schedules.

Whether or not that schedule reflects reality is immaterial. What matters is that it exists and is as detailed as possible.

Which essentially casts the PM as Borgesesque map-maker.

[a_c]

I can't articulate what I find deal breaking in these tools. I would love to see more contenders to jira. From my understanding people generally hate jira for its ocean of configuration and slowness. Would love to learn more what problem jira is not solving, and would love to try more alternative. I have used github issues, basecamp, trello, among others for project management. They are all okay. At the same time definitely not miles better than jira. In my case, project management is something has to be there, doesn't matter which tool to use (given that most of okay).

[PeterisP]

Think of it this way.

An organization has 5 weird workflow issues that they can somehow shoehorn into Jira. Trello does 4 of them better, but doesn't do the last one; Github issues does 3 of them better than Jira but does two of them in an opinionated way that differs from the company expected workflow. Etc. So, the other options are disqualified because they don't handle all the requirements and often eventually only Jira remains as an option.

Random things I've seen (not all in the same place) as a must-have requirements for a project management system:

* doing cost allocation between departments for time spent on tickets.

* doing cost allocation between departments for time spent on tickets subject to a weird set of criteria that no sane product would include out of the box.

* integration of user roles, permissions and attributes (e.g. what's being billed) from whatever is configured in company Active Directory.

* track time allocation of people in teams distributed in an organization, disqualifying any solution that won't integrate all the people in a multinational company and all the projects in which a particular person might spend their time.

* having automated CI/CD deployment be contingent on actions taken on that ticket.

* having automated CI/CD deployment be restricted to actions taken on that ticket following a very specific set of rules who can approve what and what needs to be reviewed. etc.

As you can see, these aren't really "project management" features but aspects adjacent to it, but those are things required from a project tracking system in larger companies.

In essence, it's not sufficient for a product to provide a feature in one way; the key requirement is to have a product that can have software support for your particular way of doing that business process; and a solution must fit all the boxes, because the company won't use one tool for half of the process and a different solution for other half - well, not unless the data is magically synchronized, which is a very very hard thing to do properly.

[jtdev]

Given these points (and point #2 in particular), I'm certain that project management using Google Drive + Google Sheets + Google Docs (or whatever cloud based office tooling you prefer) would be far more productive and cost effective than what Atlassian is selling.

[dangoor]

I deleted my original comment, because I realized after the fact that you specifically cited "project management".

I'd just say it depends on the size of your org. Depending on what the projects you're trying to manage look like, the Atlassian tools offer some features that _really_ help. Prior to adopting Jira, teams were using some combination of Trello and Asana. The lack of any shared structure between teams made cross-cutting projects very hard to reason about.

Jira definitely has warts and annoyances, but it has a solid API and the JQL language for querying issue data is incredibly useful.

[flarg]

You'd think so, but people and especially enterprise devs seem to discount GDocs as viable and themselves gravitate towards Atlassian. I've dropped enterprise web project mgt tools for my team's in the past and the amount of hate I experienced for going back to Excel and weekly status chats (where I fill in the Excel for them) is astounding, and yet Jira is rarely updated truthfully. Maybe that's why they do it, Jira is a great place to hide lack of progress without embarassment.

[ativzzz]

Hard disagree, particularly when non-technical people are involved. Most I've worked with are awful at organizing, labeling, and just generally managing large amounts of data scattered across a bunch of files (something we do daily as software developers, so understandable), and giving them flexibility and freedom in organization will result in a shit show