There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow.
Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone, but from my point of view I have a simple process for evaluating tools:
1) Can I use it at all? 2) How many of the features I want does it have?
I'm pretty sure Jira would score great on the second question, but since it hard fails the first, I'll never know. And it's been slow for so many years now, I assume they have no interest or ability to fix it. And their slow drift towards cloud installs over letting people self host isn't helping them either since, embarrassingly, their cloud instances seem to be even slower.
(Incidentally, there's a lot of competition in that space, but I've been pretty happy with Clubhouse. I wouldn't mind a few more features, but it's good enough. More importantly, the UI is clean and snappy, and that hides a multitude of sins.)
Do you know that this post is actually breaking the JIRA ToS? Seriously, it's in their ToS that you can't complain about how slow JIRA is...
> Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products
> Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone
My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think.
You don't like that the ticket form has 50 fields you don't need? No problem! All you need to do is to convince your manager to contact support and tell them to track less data about your progress. I bet your manager will love that.
And once they got the foot on the door, who is going to convince the company to migrate away from them?
>My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think.
That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.
I honestly wish it was that simple for us but convincing management is a fairly sales-driven approach and our marketing model is heavily self-serve. We do have a product called Jira Align that's targeted closer to what you're describing. I'd attribute more of the spread to the concept of "Jira is the defacto" fwiw.
Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself.
Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".
As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible.
When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning off the permission checks, you replace all of this communication with the equivalent of 'return true'.
Unless you're running a multi-department enterprise-wide Jira ($deity have mercy on your soul), you're better off eliminating permissions entirely and controlling access to the instance at the network. In other words, if only your developers need access to it, do not add your developer user group to the various site permissions, set the permission to everyone instead, and ensure only your developer's subnets can touch it in the first place.
It is a fundamentally poor design for permission checks to require additional network round-trips. A user's group memberships need only be evaluated once when they log on, with a refresh every few minutes at most.
Access control lists can be easily cached, and then most access checks can be performed entirely in-memory.
Instead of evaluating the full ACL every time, an additional trick is to take the cryptographic hash of the ACL and use that as a cache key. This both deduplicates the ACLs (which tend to be repetitive), and also allows (ACL,UserId) tuples to be efficiently cached.
This way, a page with even a hundred controls becomes effectively a hundred hashtable lookups the second time it is viewed, and even the first time it is opened the overhead is no more than a millisecond.
If turning off security makes a noticeable difference like you said, Atlassian has done none of these basic things. It indicates to me an incredible level of negligence.
About 6 years ago I maintained the LDAP integration code for Atlassian Crowd, which is/was reused by Jira (& Confluence).
Jira (both Cloud and Server) does cache permissions, heavily. Jira effectively has a local cache of user and group relationships for all users who have access to a given blah.atlassian.net Jira, and caches lookup results in a shared cache too. It's complicated by having well over a hundred thousand active Jira sites spread over several hundred stateless servers, which does make effective caching a bit trickier.
AFAICT Jira Cloud's slow feel currently stems largely from the front-end, amplified by the debacle that is modern front-end engineering. It's tricky to get 300+ engineers to ship fixes and enhancements in a multi-million line codebase over 15 years old on a good day. Feature creep in design systems, constant ecosystem churn, and poor build tools all conspire to make it that much harder to prevent performance regressing.
But even knowing all that - yeah, I wish that Jira's performance was 5x better too :)
Disclaimer: am still employed by Atlassian but all views are my own, things may have changed a bit since I haven't touched any Jira code in ages, etc.
The permission performance issue I was commenting on (apparently) resides in the back-end code of the on-premises Jira server.
The front-end code issues other people have raised seem like the type that could be solved by simply turning on Gzip or Brotli compression for static JavaScript content in the web server.
All of this seems to be incredibly basic tuning to have been overlooked, especially given that every public discussion of Jira mentions its slow performance!
As for the Jira Cloud: I just did some quick experimentation. I spun up a free-tier account and created an empty issue. This is the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, high-performance client link, same region as the Atlassian PaaS server, etc...
At least here, most of the traffic is coming from a CDN that enables compression, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of.
Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form!
This required 1.2MB of uncacheable content to be transferred.
With the cache off, a total of 27.5 MB across 151 files taking 33 seconds is required!
The total text displayed on the screen is less than 1 KB.
The page took 4.35 seconds of CPU time on a gaming desktop PC with a 3.80 GHz CPU and a gigabit fibre Internet connection.
A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds!
Is no one responsible for performance at Atlassian?
It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit, every time I...
A customer I am currently working with has a JIRA instance which literally, looking at the firefox network inspector right now, takes 13.04 seconds before it's done loading. It takes at least 10 seconds before the page will even let me scroll. I can't even comprehend how they have managed to get this poor of performance.
Does it keep reloading batch.js? Is it because the URL is changing or is it just not getting cached at the browser? Answering these questions is a first step to speed up Jira.
This is like web optimisation 101. What you did is a clever workaround, but it shouldn't be necessary! Why isn't the Jira server sending compressed content in the first place? If those javascript files are static, they could even cache the compressed versions for extra speed!
Yes, it's slow as balls. I run my own Jira for ~100 users and, despite throwing as much hardware at it and its PostgreSQL database as possible, it's still extremely slow clicking around and trying to use it. Database operations that would have been fast against simple MySQL 15 years ago on a single core server take seconds. What is it doing that makes it so slow?? The PostgreSQL server has most of the working set of data cached into 64GB of memory, for pete's sake, and still it's not enough to make it fly.
Cloud Jira is unusably slow in comparison, too, and when the Atlassian server licenses are not available any more (soon!) and we're forced with having to migrate, I'm not sure what to do. Bite the bullet and just accept the abysmal performance for an easy migration, pay through the nose for the Data Center license, or get people running on a new tool?
Slow, unresponsiveness, and worst of all lagged resizing caused my biggest daily annoyances in Jira.
Several times a week, I click a task, and just want to click the link to an associated epic, or something. But that link keeps dipping and dodging my mouse.
I joined another team which used Asana, and it's much better, although certain things can still be slow.
> there's one huge one: It's slow. Really, really slow
This is spot on.
Its the same reason I hate Sharepoint - every implementation I've used was always incredibly slow, so I would only ever use it when my arm was forced.
I miss old school "legacy" style apps that cached stuff so moving around the app is quick.
Even simple apps like slack suck these days as it always takes a few seconds to move around windows, why the hell can't it cache things? IRC clients in the 90s did about the same amount of stuff and they never lagged swapping servers or channels.
I would guess because in slack the history can change when irc is basically a read only log. Slack has threads, edits, deletes and emojis etc. that will change the history so you can’t cache it
This is my biggest gripe. It's slow and clunky. Confluence is also terrible (slow and clunky). Mkdocs, which is markdown powered, is much better for documentation.
My remaining issues with jira are not with jira at all. Jira can fix its slow ass software, it's feature backlog and I can use mkdocs over confluence. Jira can't fix poor project requirements and management.
How fucking dumb are you if you can't even write a bug report? It's what happened, what I expected, and a how to reproduce bullet list.
Atlassian has been losing money in every quarter for quite a few quarters. But its market capitalization has been generally increasing so shareholders who sold their stock probably made money.
I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.
Unrelated, but... we've got a jira input field that keeps moving the cursor to the end of the input field on each keypress. Perhaps that all do that(?), but it's noticeable when I'm pasting in a URL and want to change the beginning part of the URL.
Example: server-abc.example.com, need to change to server-def.example.com - changing the A then moves the cursor to after the .com, which is also beyond the end of the input box, and thus invisible.
Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone, but from my point of view I have a simple process for evaluating tools:
1) Can I use it at all? 2) How many of the features I want does it have?
I'm pretty sure Jira would score great on the second question, but since it hard fails the first, I'll never know. And it's been slow for so many years now, I assume they have no interest or ability to fix it. And their slow drift towards cloud installs over letting people self host isn't helping them either since, embarrassingly, their cloud instances seem to be even slower.
(Incidentally, there's a lot of competition in that space, but I've been pretty happy with Clubhouse. I wouldn't mind a few more features, but it's good enough. More importantly, the UI is clean and snappy, and that hides a multitude of sins.)