Serious question, why does anyone still use Jira. It's a huge pita and everywhere people are essentially forced to use it, they hate it.
It's become clear case of too many knobs.
In defense of Jira. It is a tool. Some people may say desktop linux is clunky and slow and difficult. But on linux, everything is up to the user. You can choose from at least 10 window managers, make your own from scratch, or fork and modify your most preferred.
Jira, is like linux. If you don't like Jira, it's either slow (will address this next), or its really that you don't like the organization processes of the team or organization you are a part of. Because properly configured, Jira reflects the working decisions you have made as a team.
As to being slow. I only had this issue once with a small dev shop self hosting in a closet. At a large enterprise with over 10,000 engineers using Jira, not including the non-engineers using it, it was always lightning fast for the self hosted version.
People didn't like Jira and started using Trello. So Jira made a Trello style view. People moved to Asana. Jira made an Asana view. Jira is everything, and if you don't like it, it either doesn't fit your use case ( yes its expensive and can take a lot of thought or time to set up properly ), but its likely more that you don't like your Jira that you are being _forced_ to use.
(On the other hand, I have many bones to pick with confluence).
> As to being slow. I only had this issue once with a small dev shop self hosting in a closet. At a large enterprise with over 10,000 engineers using Jira, not including the non-engineers using it, it was always lightning fast for the self hosted version.
Contra-point: I use Jira for <1,000 users, it's hosted on a single instance (128G mem 64vCPUs), with a seperate database server and it takes 30s to load my backlog. (And I'm not exaggerating, truly, each page load takes 1-30 seconds, direct ticket views to to kanban board).
I looked at running multiple servers, but it seems like our license doesn't allow that. Which is another issue with Jira, it's licensed on the server level.
Check your database integrity, you probably have some bad indexes in there. Which brings me to the major point about why atlassian products suck.. you have no support if you are not within a current version. If you were like a shop I was once at, where you can’t upgrade every 3 weeks then develop a DB inconsistency that prevents future upgrades but don’t have the manpower to address it so then you end up 2 years behind and the inconsistency is now 5000 objects in the past that requires deep massaging. Atlassian support is still MIA, and I’m not talking about where the Heat play at. You find an obscure thread that mentions data loss so you balk at the idea and go another 6 months into upgrade debt when you hit a show stopper. Jira won’t start because of that inconsistency that is now 7200 objects in arrears. You go back to that forum post and attempt the steps. You have to manually repair the inconsistencies. 3 hours later jira starts but now calls are rolling in about missing links. You spend the next week addressing the known issues then let it fall to the back burner.
Nope. Fuck jira. Let’s not talk about the hell that is Confluence. If you must use it then don’t self host it, let them deal with managing their garbage product.
FWIW, in my experience a big factor of this is poor configuration, especially around permissions/ACLs getting out of control. That and deranged addons.
Something is seriously hosed with your configuration if it takes up to 30 seconds to load an issue, especially on your specs which can probably support 5000+ users. Multiple servers won't fix your problem...probably should have support eyeball your configuration.
Those all seem like valid points. Especially about $$. I am wondering if JIRA can't handle the equivalent of a monorepo, with one giant project. Was that the situation?
Also, I don't intend to defend JIRA from a cost or infrastructure perspective, just as a tool.
If you are shopping around for a ticketing system might I offer this generic minimum spec sheet:
* Items should all have a unique identifier that can be used in the developers workflow
* Any item should be able to be a sub-item of another item.
* It should be fast enough to not waste development time (time spent in tool).
If your ticketing/work/bug system doesn't allow those (and I believe GitHub issues might not), then you are doing your team a disservice.
The reason I usually turn to JIRA, is that somehow it manages to be everything to everyone. I was managing a small team at a startup, and the developers only looked at the detail view and the kanban view. Almost any "update" to JIRA happened via including a ticket number in a git commit, branch, etc. However, the QA team, had some crazy pipeline that happened after the engineers deemed it done, and those two workflows didn't affect each other, and worked seamlessly. Product, had an entirely different workflow before engineers even saw a ticket. Then after grooming, and sprint planning, the team set a goal of how which tickets would be done and in what order. Engineers would go back to their desk, and just use JIRA for viewing the details and commenting on things usually for product/design. Also, if I wanted to cut a release of something (at the time we did weekly deploys, even though master was always considered deployable at any time), and I could click a button in JIRA to make a release that automatically knew what had changed from git. All of those tickets got updated to `released` automatically from the deploy.
You may not need JIRA. But a lot of engineers have put a lot of hours into a marvel of software that does way too many things. Its an amazing tool. But you may not need a multi-tool such as JIRA. You might just need a hammer.
(Lastly out of curiosity, have you contacted their support about optimizing your performance? I am curious before I choose self-hosting in the future.)
Switch to Phabricator which is open source and you won't look back. JIRA truly is a crappy product designed to sell to managers who they wine and dine in order to sell, not based on how good or fast it is.
Wow. Phabricator has really evolved since the last time I looked at it. I will consider it for my next team.
As per wine and dine:
1. I have never interacted with a human being from Atlassian ever.
2. I don't think this is as effective for selling software anymore. This has been replaced by user conferences. Most people who can buy things that involve being wined and dined have can expense a nice meal when traveling for work. Many times a sales person may wine and dine you so they can wine and dine themselves.
We have cloud JIRA (Attlasian hosted) and it is awfully slow. And it is always changing the interface so I have to click around that laggy interface every time to find what I need.
In the same time most often users will as to add new features to “already clunky” system. It will always make me wonder - where is logic? Yes it ca be super custom designed but in 95% it’s over engendered.
The question is "why do organiations use processes that are complex enough to require it".
I couldn't imagine doing the process I use at work in something less complex (github issues, trello, ...). We tried that in a simpler system and it is a web of hacks, manual steps, emails...
If the complex you need is complex, then a complex and configurable system might be the easiest way of managing it. Everyone should of course first consider whether a complex process is actually needed - but for the sake of discussion, let's say it is (No one who has a simple process would be considering Jira, and contrary to popular belief I don't think complex systems breed complex processes. I think complex organizations do).
Do you have multiple teams, with people switching between teams. Do teams have different processes in different teams? Do you have hierarchical planning where a management team plans on a higher level what features go in what major version and different product teams break it down into managable chunks? Do you have managers that need to report statistics to various stakeholders?
All of that can be emulated in any system. But if you start emulating it in a simple system, then all that's missing instead you need to add to the system with emails, a wiki describing which email to send to what person after generating the monthly report or whatever.
I think the mistake that is often made is that these systems are seen as tools for a development team of 4-8 people who would otherwise use a whiteboard. They aren't. In fact, I'd recommend that any team use a simpler tool to manage their progress if they want to. Why not post-its on a whiteboard if you are colocated? All that's left after you complete an iteration (sprint, release, whatever) is to fill in the issues from the whiteboard back into a system and be done.
These systems aren't supposed to get in the way of developers. If they do, don't use them. But you need a central source of truth for questions like "what was the cause of that bug 9 years ago?". I use info like that daily. It's not going to be found in the trashcan under the post-it whiteboard.
The strength and problem of Jira is that you can model the most absurd organisational processes with it.
There are a bunch of oddities in the UI that don’t help it much (like having 4 different interaction patterns for sorting list items), but the biggest issue by far is needless complexity and foot guns added by the org/admins. For this, I wouldn’t blame Jira/Atlassian.
I’ve managed Jira workflows for 3/4-digit users on even larger instances and I run my own self-hosted Jira as a private task manager (If you’re already concerned about waste of resources and bloat in Electron apps, better not try this at home). When configured properly, I prefer Jira over all the other tools* in it’s domain that I administered at some point in time.
The most annoying thing on a daily basis for me with JIRA is how slow it is. It seems like a cloud hosted one and a self hosted one are are equally slow. By slow I don't mean abysmally slow, but every action typically takes 500-750 ms. And if you use it regularly, that makes doing stuff a chore.
> The most annoying thing on a daily basis for me with JIRA is how slow it is.
I can't comment on the cloud offering, but I agree that the performance and resource consumption of the self hosted Jira is not great either.
To me it is not quite slow enough to negatively offset its usefulness.
Perhaps I am also too used to working with even slower web applications to really take note of anything < 1s ;)
Again, to double down on my previous point: where it can get very slow very fast, is for ill configured systems... i.e. when running unnecessary permission checks on very large groups.
In general UIs should always respond in 100ms or less.
For lord's sake GMail takes a full 3s which is slower than any desktop client took in 2000. Somehow people think it is okay to make your page slower because "ooh aah AJAX" and "oh I can just add a spinner" or something ...
Back when I used pine it just loaded instantly! No spinner, no splash screen, no progress bar needed.
And don't give me that "oh but it's in the cloud" crap -- the cloud isn't an excuse to be slow when I have a 300mbps downlink with sub-10ms ping times to headquarters and datacenters of these companies.
So it's not just me. I never used it professionally, but a handful of open source projects decided to use it. It felt like a slow, convoluted process to just open a bug report.
Creating a bug report with Jira can be as simple as filling in a summary and a (optional) description, then click submit. If you use issue collectors, you may not even need an account in the system or directly access the Jira application to report the issue.
The choice is to adopt a crap product like Jira and use it to model your existing flows or buy an SAP or NetSuite product and have it govern your business.
Serious answer: there's a relative dearth of project management tools that have anything approaching useful reporting and analytics, and the requirements of the organization outside of engineering often require that that reporting exists (if not in the pointy-haired boss "measure the productivity of your individual engineers" sense, at least the "tell me when big project will be done and how many resources you need" sense).
GitHub issues and Trello have more or less just abandoned the idea of being able to do any useful analytics or reporting, tools like Pivotal Tracker have some but require that you work in exactly the process they dictate, and the other big ones that have reporting generally are even worse than JIRA.
This is a huge thing. Also, if Jira doesn’t directly support your specific workflow, the API and Export functions provide a lot of information to do this for you.
This reporting gets useful once you have a stable team and you want to identify issues in your process and back your theories up with data.
Let’s say you struggle to meet expected delivery dates (based off estimates), have a look at a chart of your cycle times. Do they take longer than a week, with a wide variance in when they get delivered? Maybe you’re not breaking down work enough, or you’re getting blocked (committed too early).
Check a chart of the number of tickets in each status every day, that might tell you that things get backed up waiting for review or deployment, so discuss that.
Simpler tools don’t really provide this information. Is it always necessary? On greenfield work with a smaller company, almost certainly not, but as your product and company gets more complex, having access to this, and presenting it to your team, gets more valuable.
I’m always looking for better tools. For informal projects Trello or GitHub issues works, but if I ever have to track anything, it isn’t easy.
I went from MSProject and ClearCase to Jira in the mid 00s and thought it was so much better. I’ve gradually changed to hate it, but can’t find a better tool.
The alternatives I’ve tried have been way worse in terms of complication, cost, and specialized training required. I work with people who use MSTeams and it makes me yearn for Jira. I’ve used GitLab, but it’s cost is too high for non software projects.
It’s weird how this seems so simple that there would be a clear default tool that just captures user stories, routes them among people, and gives reports.
I similarly tried Trello and Github issues (created about 1,500 issues so far just on GH) and it is not easy to work in any of them. Trello is great until you have lots of tasks, Github is developer-centric and not product-centric, thus too unstructured. Finally decided to do one more task management tool. Saying the truth, there is so huge competition in this space right now, that I would think 10 times before making something like this nowadays, knowing how difficult to implement it despite seeming simplicity. It becomes more and more complex if you want to offer revision history, "undo" functionality instead of constant "are you sure you want to delete" etc. But I like what we did so far (see project name in my profile if you want to try it). Actually, I still don't know the other tool which is focused on creation of actual "stories" and not just small text description and lots of tags.
> I work with people who use MSTeams and it makes me yearn for Jira.
What do you mean by this? As far as I can tell, stock MS Teams and stock Jira are designed for very different goals—they don't fall in the same category.
Phabricator is amazing and fast compared to JIRA, and better yet is open source and can be quickly tested in Docker or deployed using their official Helm chart.
I disliked JIRA and we switched to Microsoft DevOps about a year ago. Now I really miss JIRA. DevOps is so painful in comparison, especially doing really specialized things like, you know, tracking work items and answering questions like "what's done; what's outstanding". sigh.
Most likely they are just hate being forced into something or Jira isn’t actually used correctly as in just a vanilla instance without integrating it into the organization no custom scripts, no plugins nothing.
Jira is an extremely powerful tool when used correctly by an organization and the entire Atlassian suite as a whole is pretty awesome.
If you essentially write all your organizational processes into Jira workflows it’s a whole other universe all of a sudden everything is behind a single paint of glass and all technical and non-technical processes are in a single place in a single a coherent workflow.
We have everything from the first steps of the project through its entire lifecycle in Jira it’s not just a place for bug reports.
We use Jira at work. We register issues in it, we got Fisheye integrated, the SQL-ish search makes it reasonably easy to find issues. The custom dashboards makes it reasonably easy to have a good overview over my issues.
My previous serious exposure has been MantisBT and Bugzilla. Out of those I vastly prefer Jira.
So what's with the Jira hate? Seems clear we're not doing something a lot of other people are with our Jira.
Jira is customizable, so one user might have a vanilla experience while another one might have one with enough issue fields to make an airliner cockpit blush with envy and complicated multistep workflows.
The latter tends to be horrifically slow from what I understand.
Jira supports the kind of software management that has become ubiquitous in our industry. So one "needs" tools to create burndown charts and the like. This is now a multi-million dollar industry, and Atlassian is all-in for it.
For us it's purely cost. My company looked at the alternatives they wanted, and they cost significantly more. Everyone complains about it, but the cost savings is worth the pain to them.
Jira, is like linux. If you don't like Jira, it's either slow (will address this next), or its really that you don't like the organization processes of the team or organization you are a part of. Because properly configured, Jira reflects the working decisions you have made as a team.
As to being slow. I only had this issue once with a small dev shop self hosting in a closet. At a large enterprise with over 10,000 engineers using Jira, not including the non-engineers using it, it was always lightning fast for the self hosted version.
People didn't like Jira and started using Trello. So Jira made a Trello style view. People moved to Asana. Jira made an Asana view. Jira is everything, and if you don't like it, it either doesn't fit your use case ( yes its expensive and can take a lot of thought or time to set up properly ), but its likely more that you don't like your Jira that you are being _forced_ to use.
(On the other hand, I have many bones to pick with confluence).