3 ms·

There are three problems I notice with JIRA, of which two are entirely the product's fault. The first one you already mentioned: abysmal speed. The second is ho

There are three problems I notice with JIRA, of which two are entirely the product's fault. The first one you already mentioned: abysmal speed. The second is how JIRA forces certain ways of working which are clunky or intuitive (or by extension, out-of-the-box workflows are difficult to change). The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary. Most developers do not need this info, and do not have the power to easily change things. All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket. I would believe this is not impossible to avoid, but I do feel a simpler structure using labels, milestones and issue tracker is far, far easier and less prone to being misused. GitLab and Github can both do this as far as I know. And sure, JIRA integrates nicely with other products (Bitbucket, Bamboo, Confluence). Other products have these integrations on a more modular level and still load faster and have small QoL differences over JIRA. Maybe big corps need a bit more, but JIRA seems to be too focused on managers and suffers from feature creep to the detriment of user experience.

stiray 6y ago
> is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary Omg, finally someone has said it, I thought I was weird. This is the imperative problem with JIRA, it is not made to help the developers but to satisfy management which is buying the software. +1 for this comment. I have seen its usage in 7 companies and in each and every case instead of simplifying developers workflow it was complicating it due to management wanting to have their data which, at the end, didnt bring anything for the product but were just enabler to make their cute graphs that enabled them to not be involved into development cycle (as they should be) but rather bring out statistics "out of their shoe - JIRA". And this is also my only (ok, except the slowness which should be understandable for any web browser js application) comment over the JIRA, I dont care what the tool is, how much time it takes (at the end, I am not paying for it), but how much it diverges from the tool that SHOULD help the development while in its essence it mostly helps the management to track their data.
- BlargMcLarg 6y ago
  Pretty much. We can divert a little to support customers reporting issues, though I don't feel JIRA is much friendlier here compared to GitLab once you get the hang of both. The only one I see benefiting from this monstrosity is management and upper layers, and they indirectly pay for this through lower morale and retention rates. If you really need the graphs that badly, you might as well spend a few hundred man hours to write a script that imports data, run some data science logic and draw them. And maybe put all that info.
baud147258 6y ago
> All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted
- BlargMcLarg 6y ago
  That comes back to the earlier point I made: developers often not having the power to change this. Others (and myself) already mentioned this is not a problem of JIRA itself, but rather JIRA being predominantly sold to management types that do not relinquish control and overconfigure the system. I would love to see the insides of what we have configured, and toss the junk out. It ain't happening in the next 20 years, and I sure as heck don't plan to stay that long at a company putting little value in the experience of its employees.

stiray 6y ago

> is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary Omg, finally someone has said it, I thought I was weird. This is the imperative problem with JIRA, it is not made to help the developers but to satisfy management which is buying the software. +1 for this comment. I have seen its usage in 7 companies and in each and every case instead of simplifying developers workflow it was complicating it due to management wanting to have their data which, at the end, didnt bring anything for the product but were just enabler to make their cute graphs that enabled them to not be involved into development cycle (as they should be) but rather bring out statistics "out of their shoe - JIRA". And this is also my only (ok, except the slowness which should be understandable for any web browser js application) comment over the JIRA, I dont care what the tool is, how much time it takes (at the end, I am not paying for it), but how much it diverges from the tool that SHOULD help the development while in its essence it mostly helps the management to track their data.

BlargMcLarg 6y ago
Pretty much. We can divert a little to support customers reporting issues, though I don't feel JIRA is much friendlier here compared to GitLab once you get the hang of both. The only one I see benefiting from this monstrosity is management and upper layers, and they indirectly pay for this through lower morale and retention rates. If you really need the graphs that badly, you might as well spend a few hundred man hours to write a script that imports data, run some data science logic and draw them. And maybe put all that info.

baud147258 6y ago

> All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted

BlargMcLarg 6y ago
That comes back to the earlier point I made: developers often not having the power to change this. Others (and myself) already mentioned this is not a problem of JIRA itself, but rather JIRA being predominantly sold to management types that do not relinquish control and overconfigure the system. I would love to see the insides of what we have configured, and toss the junk out. It ain't happening in the next 20 years, and I sure as heck don't plan to stay that long at a company putting little value in the experience of its employees.