Compounding this issue is how many clicks even "simple" tasks take because of their bizarre choices. Basic necessities like changing ticket status can't be done without opening separate pages, etc.
One you've actually managed to create a ticket and assign status, good luck finding it later. Backlogs inevitably evolve into infinite swamps that no one knows the full contents of. Not helping is the fact that the search is terrible. I often vaguely recollect some detail or test procedure that someone helpfully mentioned/documented in a ticket somewhere before closing. I successfully find maybe a third or less of those.
Also it's highly customizable, so any skills or knowledge from one company don't apply to the installation at any other.
> A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful
I use Jira daily, it's nowhere near this bad. It's not fast, but pages load in about 5 seconds.
> changing ticket status can't be done without opening separate pages
You select the new state from the drop-down and set it. This is available through a few different routes/views.
> good luck finding it later
Their search looks through title and description, what else do you want?
> Backlogs inevitably evolve into infinite swamps that no one knows the full contents of.
If you let them, of course. If you don't close the tickets, what did you expect to happen?
Edit: I did have the bad luck to discover it performs pretty horribly if you’re on a high-latency connection to the office. I think it makes a lot of round-trip requests.
Properly configured on-premise installations are usually quite fast.
> I think it makes a lot of round-trip requests.
It does, and that's the main issue
I’ve seen both good and bad Jira configurations. And I’ve seen them run on both good and bad hardware solutions.
There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly.
I submit that anyone who hates Jira probably has not seen a good Jira configuration. And anyone who loves Jira probably has seen a good configuration and doesn’t understand what everyone else is complaining about.
Jira is a real Jekyll vs. Hyde type of tool. In my experience, how you feel about Jira says much more about the type of configuration you’ve seen than anything else.
This has been done wrong by Atlassian.
I’m sometimes really jealous when I see fast self hosted public JIRAs and by the meantime, the instance I have to work everyday on atlassian cloud is both snail-slow and airplane-heavy.
And they are replacing it with JIRA Cloud that cannot be configured at all, and is unbearably slow.
I am not normally a "less features is more" kind of person. But with issue tracking, I am.
