6 ms·

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

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)

jtdev 5y ago
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.
- flarg 5y ago
  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.
- deleted 5y ago
  [deleted]
- dangoor 5y ago
  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.
- ativzzz 5y ago
  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
wly_cdgr 5y ago
There's no need for nuanced analysis. The root cause of the hatred for Atlassian products is that they are utter shit
- quacked 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
      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".
  - axlee 5y ago
    What's your preferred alternative for medium to large teams?
    - quacked 5y ago
      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".
creshal 5y ago
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 5y ago
  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 5y ago
    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).
    - 5y ago
jerf 5y ago
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 5y ago
  As my career progresses I find myself increasingly leaning towards opinionated tools that sell a methodology more than flexibility, for exactly this reason.
  - mattbuilds 5y ago
    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.
  - ethbr0 5y ago
    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).
a_c 5y ago
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 5y ago
  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.
kstrauser 5y ago
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 5y ago
  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.

jtdev 5y ago

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.

flarg 5y ago
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.
deleted 5y ago
[deleted]
dangoor 5y ago
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.
ativzzz 5y ago
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

wly_cdgr 5y ago

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

quacked 5y ago
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 5y ago
  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 5y ago
    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 5y ago
    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".
- axlee 5y ago
  What's your preferred alternative for medium to large teams?
  - quacked 5y ago
    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".

creshal 5y ago

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 5y ago
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 5y ago
  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).
  - 5y ago

jerf 5y ago

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 5y ago
As my career progresses I find myself increasingly leaning towards opinionated tools that sell a methodology more than flexibility, for exactly this reason.
- mattbuilds 5y ago
  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.
- ethbr0 5y ago
  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).

a_c 5y ago

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 5y ago
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.

kstrauser 5y ago

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 5y ago
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.