I fucking hate Jira
ifuckinghatejira.com
ifuckinghatejira.com
I'm going to stick up for Jira. I certainly don't "love" Jira, though I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now).
The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve. It's always taken on from the position of "well, it didn't make my specific use case easy", but never with an appreciation with some of the complexity that Jira needs to solve for other users at your company, never mind other companies.
Obviously some of the complaints (speed, stability) are very valid, but here's a question I think is just as valid: why don't you think some other company has come along and toppled the Jira crown? Certainly tons of them have tried, and while many have their supporters, they are almost equally likely to have their detractors.
The fact is, building a generic project management and tracking tool is a really difficult, hard problem. In my old age as a programmer I feel like Jira is kind of like our form of government: "Jira is the worst project management tool, except for all the others".
My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some internal specialist Jira admin(s) to make your changes.
Also, in the last couple of years it's got a lot better. It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
In detraction: configuring it can be a huge PITA. So many screens, concepts, and so much clicking. But when it's done it works, and I think most of the hassle is just inherent complexity from such a configurable tool (if you haven't Admined Jira: you can change almost anything).
Jira is organization poison, not just a reflection of what an organization is.
Came here to say EXACTLY this. I've used Jira across 3 companies, and in the first 2, I always felt like folks complaining about Jira were just being picky developers wanting the sun, moon and the stars, because Jira worked perfectly fine for me and my team (in fact, it was the backbone of our process).
Then in the third org, I felt like I was hit with a brick wall of every single issue folks complaining about jira point out. Needless workflows, Middle Managers wanting to "control" how stories/epics get closed, multiple levels of convoluted manual configurations, automated processes creating Jiras that for trivial non-issues which clogged notifications and team backlogs and brought jira to a crawl etc. Heck, at one point, the mess got so bad, that the company considered hiring a third party to "fix" our Jira workflows. And note that this was a <100 person startup!
On introspecting, I completely felt that in the first 2 companies, the organization was structured around "getting stuff done" and "keeping stuff as simple as possible, but no simpler" and that naturally flowed into how Jira was set up as well, while in the latter, the focus was entirely on top-down "process", and that showed in the Jira setup as well.
Honestly, I now think I can say a lot about a company's engineering/product culture just by spending 15 minutes on their Jira ;-)
once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.
Overall, we are very happy with Jira and it's worth the cost for the value it brings to the organization (still hurts the wallet, but it's at least justified).
...and then Atlassian comes along and rug-pulls on-prem Jira.
We only have ~80 users, so 1000-user-minimum data center isn't going to cut it for us. And there is an on-prem requirement, so no cloud option either (wouldn't want to anyway). And for that, I bitch. Fuck Atlassian and everything they do to appease their shareholders before the customers.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
My understanding is that the Cloud offering is the slower one, assuming you can dedicate a beefy server (but probably under $200/mo on hetzner or ovh for most businesses) to running your Atlassian stuff.
Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works.
I don't buy that it's a matter of competitors not being better. It is more about inertia.
The argument you have here could equally be applied to C++ or Cobol "Why is new code being written in these languages? Why is C++ so popular even when there are many other competitors? Certainly tons of languages have tried."
I currently work in a field that is disrupting existing products that were, no joke, written in the 90s in VB6. It can be super hard to sell our product to a lot of people, not because our product isn't better, but because they've been using our VB6 competitor since the 90s.
But I've seen tons of other examples in my career of companies making larger, more difficult transitions because they clearly felt the risk/benefit was worth it: moving from CVS/Subversion to git, moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres, yada yada yada.
I'm certainly not saying it's easy, but I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira", that many companies would make the switch. This hasn't happened, and honestly if you hear people complain about Fogbugz or Asana or whatever that it's probably an equal "per-capita" bitch rate.
At that level, there isn't much competition. It costs a lot to develop a product that does everything and throws in the kitchen sink. It doesn't make sense for a startup, Open Source project could fit the bill (bugzilla ?) but they'd still need a service providing company, probably some corporate backing for the contracts etc.
Basically, JIRA is the Microsoft (or Oracle?) of the field, and any other company wanting to fight that turf would need incredibly deep pockets with an upfront investment that would only be recouped way way down the line, if they ever make it that far, and fighting JIRA would mean lower margins than if they dominated the market alone. Overall that doesn't look like a sane bet in any shape or form.
Can't agree more. A few years ago, I joined a large healthcare organization to take a break from the startup grind. During my tenure, I witnessed the selection process of an issue tracking system and a chat platform.
They picked Teams for chat even though Slack ruled, and Teams was way behind in features. Why? Because it was the easy choice. They had the typical Microsoft stack just like every other large company, so go with Teams even though it sucked.
They picked Jira for issue tracking. Why? Because it was the easy choice. No one knew how to fully leverage it, and there was no way workflows would get buy in across the whole organization.
In large companies, especially non-tech ones, tooling decisions are driven more by laziness and CYA than what's the superior product.
I think the core problem with Jira is organizations trying to use it to solve complex organization-wide problems. It is an enormous time sink, and using Jira to rule the workdays of employees is the problem.
Anything much more complicated than a checklist is wrong. Jira is an attractor for middle management growth that gives people who don't need to be doing anything something to do, and adding complexity gives more opportunities for more people to not do very much and generally get in the way of execution. It is also a way to give people who aren't very necessary or very good at understanding the big picture something that they can do to do.
Take away Jira and tools that you can order other people to use and you end up with middle management that literally doesn't know what to do because they couldn't organize or ease productivity to save their lives. Jira becomes the thing being managed instead of whatever is actually to be done.
I think the problem is that Jira is optimized for productivity theater and top-down management.
When an organization deploys Jira it is usually because upper management thinks that it needs a deluge of task tracking so that everyone can stay perfectly "aligned" all the time.
This creates an annoying amount of make-work on the part of Engineers and their immediate managers, slows down velocity and the vast majority of the time spent on inputting data into Jira never results in anything actionable.
Jira is just a symptom of the disease though.
I would say building a good one is an impossible problem, because of conflicting needs both across and within companies. The primary job of Jira isn't to help work get done. It's to give managers and executives feelings of knowledge and control even when that makes everything worse.
You don't need fancy planning systems to get good work done. Indeed, I think it's the opposite. I've done many years of work with only index cards. E.g.: https://williampietri.com/writing/2015/the-big-board/
As Poppendieck has talked about, we live in a "Tyrrany of the Plan" age, but that's not necessary and it often makes things worse: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
I think this has happened because of the rise of managerialism, where management becomes a self-justifying caste. : https://en.wikipedia.org/wiki/Managerialism
This is a lot of hearsay which tends to devolve into a debate of "we absolute need this!" vs "no you don't, see X".
>Obviously some of the complaints (speed, stability) are very valid
I don't think people defending it fully grasp just how important speed and stability are, or at least live in a corporation where Jira was optimized better than the average corporation does. Given not everything is the fault of Jira, but when Jira is expected to be the place you go to all the time and it is that slow, it becomes very impactful to morale.
>"Jira is the worst project management tool, except for all the others".
This doesn't work until big corps actually try something different, but pretty much all of them push back on the mere idea of trying alternatives. If you can't invest a few months trying a different system, you can't judge it. And since those few months are seen as a "great risk", no manager is going to push the issue any further, even if Jira's costs per developer could easily run into the hundreds (or thousands, for 6-figures) a year on morale loss and time loss alone.
And this is the crux of the matter. Management likes concrete numbers. Management likes mimicking what other successful companies do. Management does not like fairly abstract things with great risks. Management does not like big risks with abstract rewards.
It worked flawlessly — in fact I haven't been at a place that was as well organized since. And it all came down to one thing: everybody understood that there is only email and that if it isn't an email it will be forgotten and fall in some crack, so you better make it an email, that has a propper subject, is searchable, etc. That meant everybody was writing emails with nearly military rigour, while the asynchronous nature of the electronic letter always reminded you, that you just needed your emails done and then you were fine. Depending on your position you had multiple (shared) inboxes that corresponded to the tasks. Of course there were some old emails, that were more of a "if anybody finds the time and will" type and sometimes emails from the guy from the day before had to be done etc. But all in all it was surprisingly pleasant to work just with email.
The point of the story is: You can turn any tool to shit if people use it in a bad way. And you can make anything work if people use it in the right way. Most problems with communications are people-problems, not tool-problems. Sure certain tools may lend themselves to certain behavior more than to others but ultimately a team can decide how they wanna communicate effectively and which behavior produces chaos and problems.
Jira is the way it is because Jira ISN'T built for developers.
Devs may have to use Jira, but they're not the ones who have to pay for it.
I wrote about this a while back:
"Who is Jira’s target customer? It’s certainly not the poor developer who struggles to add a link to his bug report. (I’m still mad at them)
Take a look at Jira’s site and see what they emphasize:
Those pages glamorize having an overview of what work your employees are doing. It’s a tool made for managers. Especially higher level ones. The VP won’t be filing work items, but they’ll be very interested in the insights those dashboards offer.
Jira spends all their software cycles building new features for that VP, ignoring what you and I might consider critical user bugs."
Source: https://www.zainrizvi.io/blog/never-focus-on-the-user#jira-s...
This is key. The problem with Jira is less about Jira as a tool and more about how we approach project management.
I've seen some teams thrive with Jira. I wouldn't say they "loved" Jira but they had a light weight project management structure that let them get work done and enough control over Jira to set it up to stay out of their way. They didn't give Jira credit for their ease of working because it was their processes that were good. Jira just gave them a way to not have to write everything down on paper.
I've seen other organizations create a horrible project management structure and then use Jira to "enforce" those structures in ways that magnify all the worst aspects of what they are doing. In those situations it is usually more politically palatable to blame Jira rather than the management processes. Those type of organizations usually blame the tool while hoping that a different tool will force the organizational changes that are needed to make life better.
Before I got to use Jira for the first time around 2006, everything I used before was crap, either in-house solutions out of CGI scripts or crap like ClearQuest.
Stuff like Trello just seems too basic for typical enterprise workflows that overlap sprint planning, with project roadmap, milestones and change requests, mapping of tickets to source code, pull requests, documentation,...
If I have decision power, I will always pick the Atlassian product suit versus the competition.
Because the people who get to decide whether or not to use JIRA aren't the people who it causes the most suffering for.
But the flaw is in assuming it's a problem that should be solved in a one size fits all way. In my experience the pain points come from top down process that's at odds with the reality of the work.
I feel totally the opposite. If you've ever had to administer Jira at a large company than team-managed projects are the bane of your existence. If you think, there's even a small chance that your company will grow to 300+ engineers any time in the next several years then do yourself a favor and turn off team managed projects entirely or else you'll face a painful migration away from them.
Though I will generally defend Jira as a product for many of the reasons you said.
No, I have a really good understanding of that. My problem is that Jira, in actual implementation, tends to be how some parts of the organization (often Product) tries to exert fine grained control over other parts of the organization (design, qa, development, operations, etc.) by micromanaging the process.
Also, sometimes your organization is just not that complicated. I've been in startups using Jira with dozens of states, with complicated transitions and approval steps, that would have been over kill in medical companies I've worked at.
This is pretty much the core of it. I use Jira daily, but my exposure to it is the tip of the iceberg in terms of what it can do.
I think what most people forget is that this Jira is basically an ERM but for development-focused organizations. (Where the resources are time and people instead of processes and inventory.) If you've ever seen the complexity (or price tag!) of a real ERM, Jira actually looks very reasonable.
That said, smaller companies and teams should definitely use simpler tools that are more appropriate for their scale. Hire a Jira consultant and make the switch only when you're big enough to justify it.
I came here to say precisely this. In addition to Jira, I've used Clubhouse, Trello, monday.com, and GitHub Issues. Jira sucks slightly less than the alternatives I've used.
I really wish Jetbrains Spaces was around when the organization I work for was doing the "everyone under one umbrella" migration.
Prior to Jira, we had one team using GitLab issues, one team using Redmine, one team using Borland Star (with a tight limit on licenses), and one team using Excel.
I personally would have gone with Redmine over Jira... however that also would have tied me to doing a lot more setup work, upgrades, and care and feeding of the system compared to the relatively turn key setup of Jira.
I believe the best workers (at both the management and IC level) are not going to want to waste a significant chunk of their professional lives in Jira world and the worst workers just want to keep their paycheck coming every month so they will just submit to it and keep cashing their checks. The organization will thus rot and converge on the lowest common denominator employee, which is indeed what the tool kind of promised: fungible, low skill workers with predictable (low) output.
Jira, the software, is far from perfect, but when one talks about hating Jira, they are really talking about the people who use Jira. The same people moving over to a competing product that offers the same feature set perfectly implemented would still leave people hating it. The software itself doesn't matter that much here. It's a people problem.
So, why do people cling to a project management style that everyone hates? There is a lot of friction. Nobody wants to be the guy who pushed for an alternative that turns out to be just as bad. "Nobody ever got fired for buying IBM", as they say. You know that IBM will deliver a failure, so everyone is ready when it does fail. If you hired Mom and Pop, you are doing so expecting them to be better than IBM, so when they fail equally there is a buildup of blame to go around. That's not a comfortable position to be in.
I would suggest that winds of change are in the air, but it is indeed a slow process to find a critical mass willing to take new risks.
Trello was a much better solution to the problem, that's why Atlassian made sure to buy it and is now hard at work ruining it.
Why haven't cowboys found a different way besides horses to get around? They're not interested in what those under their asses think or feel.
Jira sucks big time, and there are better tools now. The reason no one "toppled the Jira crown" is just inertia, specially management inertia who are the ones deciding what tool to use. For the same reason we're still mostly using petrol for cars, not because there aren't better options, it is because it is not easy to change.
Yeah that problem is that in many places management sucks and can't trust their developers to get shit done, so you have to put metrics on it to bring down anxiety brought about by incompetence.
There are large open source projects that don't use jira; the extreme complexity of managing a distributed team with all sorts of interests -geneally even more complex than what a company has to deal with- is empirically doable without jira.
When an organization pivots to using jira it is a sign that their managers are no longer capable of respecting the programmers that work for them. If an organization starts out using jira, that means they never were.
To be charitable I'm sure there are a few corner cases where a manager came up through the ranks and "only knew jira" but that really means they don't understand open source IC, especially in the era of GitHub and gitlab issues.
(Btw GitHub issues is absolutely the thing that is slowly replacing jira)
Your insight is the same reason why people hate boarding selection for planes, or McDonalds breakfast ending at 10:30am or fill in the blank.
The problem being: "how to create BS data and metrics to satisfy a bureucracy"?
I suppose its a necessary evil for an organization of a certain scale, but for whatever reason, I've chosen to work in teams that are small enough that we can dispense with JIRA all together.
Jira is often the domain of PMs, management, and other leadership; if you have bad people / product leaders, you're used to Jira being a source of great stress.
It's not because I hate Agile, Scrum, or even Waterfall (although I do hate SAFe). I just know these tools all suffer from similar drawbacks, and somebody will ultimately codify all our organizational problems into the tool. Then, rather than spend an hour a week of their own time, they'll create a new mandatory field and ask thousands of people to spend an hour a week each populating that field.
I claim something more specific. A totally powerless workman who's afraid of his bosses blames his tools.
An individual in the face of indomitable authority blames anything else.
Jira is a wonderful proxy for all the bureaucracy and *managers you hate. So hate Jira, because you're powerless to change anything that matters.
For customers, their own specific use cases are the only ones they should care about.
I don't know why there isn't a good solution to the problems Jira attempts to tackle, but that's no reason to get philosophical. It's OK to hate every existing option.
But the simplest things are baffling in Jira. Any issue-tracking system that requires the users to learn some obscure syntax (or even to use SQL to refer to its internal data structures is a failure.
Because of this, it is basically jello. It is everything, and it is nothing.
It makes nothing simple, and encourages people to overachieve with the tool. If you overachieve with the tool, you will underachieve on what it is you're really trying to do.
This is why much simpler tools are better. They are usually free, or at least a lot less expensive, and they come with constraints that you have to live within. Usually those constraints prevent you from going tool crazy, and guide you to actually focus on getting work done instead of doing performance art with Jira.
If you can get away with less structure than JIRA affords then congratulations for not having a budget or timeline but the rest of us need some deniability. Every other problem in the world of software projects is human and can't be solved with tickets.
JQL and bulk edit are just warming up at 1,000 tickets.
But...
If the UX wasn't garbage I'd defend it, too. It has a lot of nice features and integrations. But the UX changes they have made in the recent past (few years-ish), made it worse, for me.
And, in my opinion, the reason some other company hasn't come along and toppled it: critical mass. It's the same reason Epic is king in the hospital IT world. The UI/UX can be garbage (and it's so much worse with Epic than with JIRA), but organizations will still stick with it, because it's what they know.
Do open source projects of any size use Jira? If not, do they use a basic knock off? The few not-so-big ones I've contributed to seem to get by without it, but maybe I just don't have enough exposure with these. If the open source world can be semi-productive without Jira, I think that's telling. The interested student can decide the details of what it's telling.
https://www.broadcom.com/products/software/value-stream-mana...
What is that problem exactly?
Jira's "director level" UI is miles ahead of its competitors.
Jira cloud in our organisation is also reasonably fast, the front end can be a bit janky sometimes, but overall considering the complexity of the application, it's not too bad.
JIRA is a lot like agile though where everyone is using a different version ranging from this works fine, to this is a dumpster fire.
Just like you won't get fired for using React in your project, you won't get fired for using Jira. It will support whatever your workflow is (and I don't mean only software development, but things like hiring or office management). If the built-in features are not enough, you will find a plugin that meets your needs.
I think long-term it's important to use a tool that give you this flexibility.
But yea, I agree, they are trying to solve a huge problem. And good on them for it. I still dislike the results though, and that's ok. We still use it.
I'm at an early startup and we use Jira; it's great because I'm an admin and I can make Jira reflect whatever I need it to reflect.
It's also highly compatible with compliance nonsense -- if you can say, "Every change to code is tracked in Jira" (the decision process not the literal diff) the auditor's eyes glaze over and they just move on.
1. It's extremely slow.
2. It's difficult to predict the effect of making any kind of change.
3. The permissions system is so convoluted, I can be the admin of a board, and yet not have permission to see a ticket on it.
4. It relegates the conversation to a second-class UI element, when this is the most important part of any project management system.
5. Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time.
6. Every Jira setup is so different, trying to compare a piece of work from one area of the organisation to a similar piece of work elsewhere is useless.
7. The UI is extremely buggy. I can add a mandatory field to a ticket, then when I try to use a shortcut to create a new ticket, it won't work because I can't fill out that mandatory field.
8. There are random side-effects when one person does something on one bit of the system, and VOILA everybody's workflow is broken, with no obvious warning that would happen.
For your specific example of not being able to see tickets as admin, I imagine that feature was added for teams where sensitive information is stored in the ticketing system for things like user reported issues. User reported issues often has PII or other personal data and while developers need to see that information, admins often don't. When I worked at a bank, any remotely sensitive columns in the database were either inaccessible to developers by configuration or by encrypting them to and from client code when the DB didn't support column level permissions (while Sybase could manage column level permissions, Mongo and Elasticsearch didn't at the time).
Have you used the bulk issue change tool? The UI isn't necessarily very user-friendly but I would not label it as requiring a lot of time, I actually feel it works quite well for this use case.
I'd like to add another point:
#. There are too many "views" or ways of visualizing the work that needs to be done, ie the plan view and the kanban view, my issues etc.
If I'm not looking at the 'right' view I'll miss something and maybe get in trouble from project management.
For me a particularly frustrating aspect is the way the UI moves around a lot. I’m quite anxious to click anything until all the loading spinners have stopped in case I click the wrong thing. Then I could be taken to a page or feature I’ve never seen before.
Also it’s really annoying when I try to copy something from a ticket description but it starts editing the whole description field.
EDIT - I'd also like to add that as a developer, once I finish my ticket I assign it to a QA. Then I can never get back to the ticket. I'd like a really easy way to see all of the tickets I've ever completed. But completed tickets aren't assigned to me, they're assigned to QA.
I have a very specific complaint: the ease which all sorts of custom fields can be added for _everyone_. Sales will want to add a field to hold their contract status. Lo and behold, engineering now has it. It can be done in the proper way, but it seems that doing it at a global level is easier since that's how multiple Jira installations at multiple companies were configured.
All I want is a ticket, with a title, description, assignee, the current status, an easy way to transition, and comments. That's it. Let my project _opt out_ of any global customization if making global stuff is unavoidable.
Also, the newest Jira UX is... terrible. Tickets should not be THAT easy to edit. How often do we want to change a ticket's description, or title? I'd say, not often. If we do, there's really no harm in having an "edit" button. Old Jira versions had one.
The biggest issue I have with jira is it's so dead simple for braindead process zombies to cram another field, another label, another required text box, 4 new transition states, 20 difference confusing priorities, etc. Then, require everyone to follow through with this (with 90% of the time putting some form of "not applicable" in the boxes they added).
It is built for anal retentive "rule enforcers" to jump in and chastise you because you checked box 4a but didn't fill out sub box 3c.
FFS, I have an easier time filling out my taxes than some project's jira setups. (And I live in the US).
- For a while, the side pane when you open an issue would just be blank.
- Setting a ticket's epic makes me want to tear my eyeballs out. The button has the tiniest hitbox, the suggestion list is always wrong.
- Bulk operations are just a PITA
- the search box is always description. I'm almost always filtering on other criteria, and so, have to suffer a page load.
- and every page load is long and slow. Loading my backlog page is 186 requests, 4.4 MiB on the wire, and takes 9.4s. For one page.
- UIs that have drag & drop, but don't support simultaneous scroll are annoying. I have to wait for the view to move at JIRA's speed, which is ofc., slow.
- it encourages "sprints" and "agile", which in turn encourage "process" over just getting shit done.
This is a common antipattern that doesn't get talked about enough. It's very common in the era of interactive ads, websites with 3rd party web UIs layered on top, lazy loading, and just "rich" UIs in general. A user needs to be able to trust what they are about to click. This is fundamental.
I also get annoyed at the subtle ways the top-level Issue composer is different from the comment composer, most frequently with the top-level composer’s refusal to allow image embedding/positioning. You can only add images to a new Issue as file attachments displayed as a row of tiny thumbnails under all the Issue text, so I will frequently create a mostly blank Issue and then write what I want to say as the first comment where I can embed images and talk about them inline.
In the interest of also saying something nice, I think it’s cute how the JIRA logo seems to be a Jera/“j” rune :)
https://wac-cdn.atlassian.com/dam/jcr:e348b562-4152-4cdc-8a5...
It’s not about any single feature being missing, it’s just terrible the same way Vista was terrible
That's not JIRA, that's your organization's crappy workflow/customization. That's the problem... JIRA is a tool that encourages setting up elaborate yet dysfunctional workflows.
Regarding your actual problem, just create a tickets.txt in your home directory and store your list of completed JIRAs and whatever else is important to you there.
on edit: once you have a query you like save it as a personal filter and it will show up somewhere in the UI, because Jira sucks who knows where (changes all the time), but you can of course also make personalized dashboards and place the filters you have made on to that dashboard with a widget that runs the filter.
on second edit: evidently I earned someone's downvote by not being adequately anti-jira despite having put in that Jira sucks, but really the comment to which I'm replying ends with:
" I'd also like to add that as a developer, once I finish my ticket I assign it to a QA. Then I can never get back to the ticket. I'd like a really easy way to see all of the tickets I've ever completed. But completed tickets aren't assigned to me, they're assigned to QA. "
which, using JQL, is real easy.
+1. Absolute garbage interface.
Can be solved by creating a custom person field called “Developer”. Then you can customize the Status transition for your In Progress status to automatically set that field to the current user or maybe the issue assignee.
For better or worse, Jira is quite powerful and flexible. But it’s not always simple to setup.
I recall even wasting time ensuring that Jira recognized correctly that a PR was merged.
They've had server-side-rendered features that while slow, contained the slowness to the backend and bundled it into one single slow request - once you waited for that, you had a fully-working page in your browser. Since it was all on the backend, your browser remained responsive while waiting.
Nowadays however there's no longer a single operation to wait for - they've split their pile of shit and offloaded it to your browser. You have to wait for the backend which is slow, but then you also have to wait for megabytes of JS to load & execute in your browser, all while the page moves around and your CPU is pegged at 100%. And God help you if you click on something by accident, as "undoing" that means waiting for another load. To add insult to injury, everything is clickable and triggers some actions, even elements that represent content and that you wouldn't normally expect to be clickable (nor would want to - let's say you wanted to copy the text).
Recently they've added another annoyance - in Bitbucket they've done some changes with regards to diff rendering and obviously have to let you know. They do so via a persistent floating popover in the bottom-left of the screen that you have to manually dismiss and the dismissal status seems to be contained to the browser - if you switch browsers or use private mode you have to deal with it continuously.
My experience with Atlassian products has actually deteriorated despite CPU speeds, browser performance & network connections improving. I used to have a mostly positive opinion of the company 5 years ago but that's no longer the case.
I don’t like Jira, though I can its positive points, but Bitbucket is just the worst tooling I have ever had the displeasure to work with. I can’t believe a single developer in Atlassian actually uses that.
> company behind it and its engineering practices. Their mediocrity goes beyond Jira.
100% agree. Bamboo bitbucket, confluence, Jira all of them made my development workflow worse.
- Giant forms with dozens upon dozens of nonsensical fields (preferably with abbreviations as names, like "IFE App.") half of which are required so you just stuff random words in them to make it shut up
- Thousands of tickets that would probably take 30+ software devs 100+ years to implement
- Can't find your project because your project's name is nonsense (also preferably with abbreviations)
- Task descriptions have hundreds of words of nonsensical boilerplate but don't actually say anything at all
- 50 different ways each to say "Finished", "Started" or "Abandoned"
- Workflow state transitions reminiscient of the outdoor maze in The Shining (crazy man with axe optional)
I feel like the company I'm working for has a reasonable attitude towards Jira, and they recently just batch closed all tickets that were older than some date in many projects. So you'd have to actively re-open tickets you had created to keep them alive, if needed. Great decision IMO.
It's an interesting exercise to be forced to deal with old tickets you've created. It gets you thinking.. "well, this thing should probably be done at some point, but then if it's actually important we'll probably think of it again and can re-create the ticket then". Might give you experience that encourages you to be careful when creating new tickets too.
Jira is the worst. I routinely lose data in jira, like saving errors. Dragging and dropping attachments sometimes causes the page to crash and reload. Everything in the UI moves around or obscured behind some tabs. I want to be able to file a network of issues all at once, something Radar did great. Jira workflows are much to complicated, and their flexibility just increases your administrative hell. I can go on and on.
I filed a bug against Radar for this behavior, and developers from other teams added comments expressing surprise that the tool was crippled in this manner. I think a year later, someone said, "Yep, our team got bit by this today again. We assumed this was fixed years ago."
This fundamental flaw may explain why some widely-encountered bugs in Apple products don't get fixed, or at least fixed in a timely manner. A dozen Radars could be filed for the same defect, but if they aren't phrased the same way you'll never find all the dupes. So dumb.
Still... I could construct queries based on status and product more easily in Radar than in Jira.
The only things I need it to do are: (1) record an archive of comments describing the progress on the issue's resolution, (2) be able to store attachments, (3) be able to cross-reference other issues. Maybe I have a really low bar? But it seems to do those without much problem and in my case it doesn't seem to be slow.
I'm an engineer, I'm a problem solver. I want to add a task, move task to "doing" and then "done" and that's it. But Jira is not created for me. Jira is created for SAFe expert who wants to create workflow so complex nobody understands it. Jira is created for Scrum master who wants to create 25 reports to show their boss how beautifully our burndown looks sprint after sprint. Yes, Jira doesn't force anyone to do this stuff, but it enables it, because Jira is created for process managers, for people who just report things.
But that's not me. Jira is not for me and the best I can do it to use it as little as possible.
Unfortunately, what happens is a company adopts it from the start, and then it grows into an impossible-to-use forest where there's no meaningful way to bring things back to actually usable, and everyone is miserable.
I'd rather pick any other ticketing system which has things done in one way than waste my life configuring jira
After struggling along for 2-3 months, we moved over to Clubhouse (now called Shortcut) and the difference in speed and overall experience is night and day.
I hope it was a widespread issue.
I loved using "basic" JIRA, mentioning issue IDs in places to clearly reference a web of "why this bit of code is the way it is", so someone digging into source code can self-answer stuff like "why not do X". (e.g.: because it caused a bug for Y)
Now there's stories, and boards, and sprints, and agile, and the worst part is that they all interact like crap. Why do "tasks" and "stories" exist? Why not the old: New Feature, Bug, Improvement? At least with those you could always see at a glance what that issue is.
At some point, our infrastructure engineers changed something that made it difficult to login to Jira without the web interface (I don't remember what that was exactly - SSO or something...), and I wrote a Puppeteer script that would login to Jira [in a headless browser] and grab the token and use it to authenticate with go-jira.
I thought about cleaning up my elisp experimentation and making a proper Emacs package. Sadly, a few month later COVID hit the US and a bunch of us got laid off. At my new job, we don't use Jira, and I never made the package. And I don't miss Jira. And I don't hate it anymore (I think). But yeah, fuck Jira all the same.
I think I can see one more reason for the name.
1. Don’t use it
2. Do a manual process
3. Get buy in and deliver actual value
4. Run into scalability issues
5. Now automate which could be Jira but now you know what value your process is achieving
6. Don’t let Jira be the end in itself. Focus on the value of the process and tune that
https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
- Shoving political messaging into git terminal messages - Renaming "blame" to something else without notifying the userbase ("annotate"? It's been a while) because, despite "blame" being a git term, its usage hurt someone's feelings (yes, seriously, even though no proof or elaboration has ever been provided) - Not fixing a bug for 6+ years where, if someone's typing a comment and accidentally hit the escape key, the entire post gets deleted with no option to recover it (I'm not sure if this ever actually was resolved)
That said, for a while, Jira had a lot of good things going for it. But by now, enough competitors have popped up with similar offerings that are easier to use without all of the unnecessary self-importance buried within it.
For a Jira alternative specifically, I've been using Linear.app for the last 8 months and enjoying it overall
That said, which competitor has a visual workflow editor, to which I can add custom statuses/transitions, which are applied based on various conditions/validations? And custom screen/field configurations? And custom resolutions? And time tracking? And apply security/permission schemes across all these things?
I get it, Jira sucks, I agree, but what's the go-to competitor?
Jira exists to check every checkbox so you feel serious remorse if you pick anything else, but in terms of day-to-day productivity, it doesn't do too well. "Nice to look at" and "Fast" aren't checkbox items for managers. They're eventual problems for someone to solve when they notice engineers never touch the bug tracker.
At my current org, my advice to use Linear was overruled in favor of jira, and I'm pretty sure I'm the only engineer that regularly touches jira.
(I intentionally write "jira" in all lowercase because I like to call it JIRA, but jira's built-in text editor unconfigurably autocorrects "JIRA" to "Jira". That's the feature they spent engineering time on? Fuck them.)
You started to ask hard questions but you hit nail on the head.
Jira is bad because it's slow and doesn't telepathically adjust itself to everyone's needs.
Perhaps the author can buy ifuckinglovejiragotocompetitor.com to provide us with the answer.
----
[0] - https://linear.app/
it is kind ironic, yet pretty typical and very telling, that the slow as hell Jira is tightly associated with Agile
It's a joy to use
----
[0] - https://taskade.com/
Yup.. at least fake agile... where every "sprint" is the same length and features aren't customer-oriented.
It was mostly the Scrummy culture that seemed like a bit of a waste of time.
I wasn't a big fan of the wysiwyg editor. This seems to address mostly non-technical people. I would always go for "Markdown with preview" (HackMD split-screen, or GitHub issue tabs, or Discord apply-formatting-to-codes).
I also don't like that it isn't an integrated part of a pull request system. GitHub/Gitea issues inter-linking with PRs in the same namespace is... golden. With the right habits, you can become an effective time-traveler.
If your team has an append-only doctrine to information, like most tech debt mills in the industry have, JIRA will become an extension of that ever increasing pile of unmaintained, disgusting, revolting monolith of excrement that captures every activity in software development.
Nothing can be done about the gigantic monolith of soul crushing chaos therefore we need to embrace it, at the expense of our sanity. Nothing can be done about the hopeless hoarding of irrelevant, duplicate tickets that distract people from work.
JIRA makes it very easy to create new tickets, and much harder to close them. So naturally it becomes a virtual sewer. JIRA is about being able to present a large amount of information to easily impressionable people so that so some people can justify their job.
"We're starting the migration to Jira. The next sprint will be entirely in Jira. Honestly, I kind of missed it."
She replied: "That's the real test of a tool. Not 'would you recommend it to a friend?', but 'if you were to start a company, would you use it again?'"
And - I would and did with Jira. If you know the tool well, and your company doesn't have stupid technical workflows and human processes, it's just great. Too many people suffered from using it wrong or suffered from using it with the wrong colleagues.
I think it really depends on how Jira and the overall workflow is taken care of. For our part, it has been a pretty good experience and the DevOps team used the APIs pretty well and wrote their own tools.
To be honest, I don't have used many other tools, but it seems like our company has made a good choice in configuring the whole system "just right".
- One of them resigned soon after the migration.
- The other barely uses it today - in fact, he found other tools for his team because Jira is too cumbersome.
The rest of us are left holding the bag because "Jira is the industry standard".
A quarter pounder with cheese is an industry standard too, but that doesn’t mean you should give it preferential treatment. Industry standards are often more like consolation prizes than a special experience.
It feels like there isn't a strong unified product vision for Jira. It's just trying to solve everything. It's all "just configurable." That likely is a selling point into Enterprises who need some level of flexibility.
But for a lot of situations, people just want something that works well out of the box.
I often wonder what the 37signals guys would do if they ever decided to tackle this problem. They don't always hit the mark, but I give them a lot of credit for self-curating and having a strong product vision for what they ship.
Wouldn't they build Basecamp?
In comparison I feel like Jira hides stuff from me, that the UI is excessively slow, that it's easy to get wrong and add oodles of mandatory fields..
2. Atlassian has a terrible way of managing feature requests priorities, not unique to them, but they definitely have an impact on many developers, which is why they (deserve and) get the huge shaming
3. I managed to move my company from Bitbucket to GitLab, for many reasons, but the main reason for me was that I simply couldn't manage the settings using their APIs, they have a very weird concept of APIs
4. They send people to fill in tickets and on Uservoice, but rarely do they actually listen to reasonable requests (tickets I still get notifications: Bitbucket user public SSH keys and Archiving projects in Bitbucket)
5. So the issue is not this or that product, it is that Atlassian doesn't have the real end users in mind, just the paying users, the end users can suffer, but not many people will resign over a product used at their company, so nobody really fights the company over it, and thus Atlassian keeps getting paid for terrible products that get new terrible interfaces from time to time
Edit: line spacing
What is it's fault is their REST API. In theory it's a well architected API. Follows REST principles. You can tell they read the whitepaper. But you have to jump through a ton of hoops to get any data beyond surface details.
Example: Want to find what epic a User Story is part of? It's a custom field. Which one? depends on how your instance has evolved over time. You'll have to scan through all the fields to find the field id.
This is what happens when an API isn't designed to fulfill a particular need but instead is meant to be infinitely customizable. Ergonomic APIs are impossible.
Comment := (name, time, text)
…and everything else is culture or auxiliary tooling. It’s a schema as old as Web 2.0 and it works because most people just want to talk to each other and search for stuff they think or know is there.
100% of the time I just want to announce either what I want to do, or comment on something that’s in progress. The communication and progress tracking are the most important things for keeping me and my team aligned.
What does Jira get wrong? Bureaucracy. Modern day online triplicate form filling disguised as “agile” is still pen pushing.
Pro-forma for bugs is friction — I should be able to file a bug without having to think about how to categorise it. Have another tool / view for nagging me about that, not the create-bug workflow.
Epics / stories / tasks / sprints / bugs: what if I make a task when I wanted a bug? What if made a spike that’s really a task? Why does this matter so much at the top level of the “task” entity — it should just be a tag on a task and nothing more fundamental than that. Let me modify the structure of my task tree myself.
Clutter, of course. Jira has 15 fields of stuff per issue that could just all be tags once we’ve spent the first week shaking out what kind of patterns are appearing in our own team’s workflow.
Projects: why is it a three stage process to move an issue between projects, and why should the issue id change when it moves? What if a piece of work is small but spans two projects? Tagging not taxonomy please.
Jira feels like it was designed for contributors and teams with zero discipline. Tech teams with any kind of serious hiring bar and leadership structure should have zero problem with trusting their staff with being succinct and meaningful with communication, including with how they track tasks. If you need Jira to enforce this, then I feel sorry for you as I pass you by to join a different team who know how to and want to work together without form filling.
> A useful task manager will be somewhat opinionated. It will almost, but not quite, do what everyone wants, and will annoy everyone equally with the few things they think it does wrong. A tar pit of a task manager will claim to be everything to everyone after customization, meaning that a few people will think it's heavenly and everyone else will despise it with the heat of a thousand suns.
Most of the problems with jira are the people using it.
"Most teams would be better off using a shared spreadsheet for task management than they would using Jira"
Rings true to me to this day.
We have at least three people employed who's sole responsibility is to pester people about ticket status, apply bulk changes in Jira, define conventions, and ultimately make life harder for individual teams who wanna follow their own processes. As an EM, my higher-ups would rather have me ensuring ticket status is perfect to the T instead of pairing with and assisting my engineers.
I kid you not, we have directors of engineering who spend half their working day making bump/nudge comments on tickets.
“There’s only two types of people that hate JIRA: 1) those that haven’t tried any of the alternatives or 2) those that didn’t have a dedicated team to configure and maintain JIRA for them”
There are tons of real issues like ages old bugs or weird design decisions years ago that make something that feels very sane feel impossible to deliver.
All in all my point is that most of these rants are against knowledge of features/design and misuse by colleagues.
Nobody really loves Jira, and we've gotten our Product, Design, Sales, and Customer Success teams using ClickUp and everyone is really happy so far (especially with the speeeeeeeeeeed. OMG coming from Jira it's a breath of fresh air).
We are chasing the dragoon of having a single tool and everything in one place. So far the eng team seems amenable to give it a shot (although we're going to transition slowly).
Are we crazy?
My past managers had a great time with Jira. But if I have to migrate or create tasks in Jira the only efficient and effective way I have found is paying for a desktop license. It doesn't suck -- that much.
Otherwise, it is a destroyer of productivity for its users. It is also a source of lock in, that is usually unnecessary.
I find Github projects to cover most if not all of the needs, for instance, in an efficient manner. Most managers though also don't/shouldn't care about the micro tasks of a project, so an excel sheet has done that job.
The consequence of who the Jira customer is, is its lack of efficiency and chaos. It is too customizable and fails to preserve any form of usability to offer that customizability. I have seen Managers being joyful of achieving the "ultimate Jira," only for everyone in the team to have to learn to abide by the new process, only so that 1-2 people can keep track of tasks and velocity without hitting github or gitlab.
You get great statistics, but if I have to spend 1/5 of my workweek on petting Jira, you lose that.
Managers love Jira, that is why it keeps coming up. You need one new manager to come in, say they know Jira, and using it will solve all of the company's velocity issues, to end up with people writing articles of how they hate Jira.
And the stuff that can be done is often so comically painful it's mind-blowing. Trying to do something as seemingly simple as create a useful saved search in JIRA is so painful I can't imagine its creation was not an act of sabotage.
I don't mind using Jira as a verbose platform which aims to map project state and helps communication BETWEEN all participants, but this is rarely the case, especially with all those pseudo-agile practices that are part of mainstream software development.
Another part of the hatred may come from the fact that it's an overcomplicated tool for a moderately simple task. This complexity is standing in the way most of the time. I just want a simple board for a simple project with simple issues/user stories/whatevers and update their state which gets reflected on the board. For additional features i want to install/write a plugin and that's it. If I need a manual for software in 2022 it's either trash or something far from mainstream (in which case complexity and/or lack of ux might be acceptable).
I wonder if the performance we got out of Product Studio had more to do with having a locally hosted instance, vs. running in the cloud, and I wonder if teams that host their own JIRA/Confluence/Bitbucket servers have a better experience. I do find that one of the major gripes people have with planning tools is that they break flow, and I wonder how much of that comes just from the amount of stamina required to maintain focus while waiting for all the spinners.
I believe a lot of the hate comes from the input rather than the software; aka what others are putting in. If you've got a really bad PM/BA your experience with the platform is going to be negative.
As far as everything else what are the alternatives? Most other platforms are horrible or lacking features.
And a good PM is to Jira as lipstick is to a pig. It might give the pig redder lips, but that won't make anyone want to kiss it. Even with the best PM Jira still had severe usability issues and bugs that atlassian shows no interest in fixing.
Asana seems to be a good balance between the depth of data developers want to track and the high-level task management every other team wants.
* Jira sucks big time, and people hate it.
* There are no other tools that do what jira does, that doesn't also suck.
* After trying Jira alternatives that suck worse, folks move away from the Jira sucks camp to no-longer minding using Jira.
E.g creating lots of fields with overlapping meaning. Creating very basic/lame status-flows but not enforcing it. Or creating very hard to follow status flows. Or misreading the data from tickets status history. Or never trying to learn how to use it but find the guy at (my) table, to create the queries, dashboards etc. (and then misuse them). Or the devs who were complaining about missing info but creating one-liner comments as well (if at all). Or the devs who are not searching for duplicates, similar issues and/or link them so it can be tracked.
It is far from perfect, and JQL is so far from being intuitive, but I can live with it - until there is a better alternative that is capable AND I have to use that.
If you are working on enterprise software it's probably bad. Even if your sales and stock are doing well, your software is still probably very frustrating to end users because they have no say in how it's made. The only users who do are admin, governance, legal, or other non-productive user. Their voices get heard and they tell the Director/VP/CTO they are happy and then the software gets renewed and seats expanded. Nowhere in there is the end user who is beating their head against a wall consulted.
Enterprise software is bad and it's worst for people who make software because we know it could be good.
But in the past I've been exposed to BMC's products, which were, at least when I was exposed to them 10 years, horrible. And going further back, Lotus Notes, which even in the early aughts wasn't up to basic standards of UI from the 1980s.
Could Jira be better? Sure. But I think a lot of the complaints about Jira might only be relevant to the way their instance of Jira happens to be set up. Setting up a proper workflow that meets the demands of the organization is not an easy thing to do.
Now, I've never administered Jira, and maybe that's not good, but as someone who's used it for about 10 years, I'm fine with it.
The truth is that there's very few project management tools out there that offer the flexibility to run individual projects the way an individual team wants to. When you're an agency with hundreds of projects in the system, that's invaluable. I researched 2-3 dozen competitors to find a better solution and there just wasn't. Other than maybe Redmine and its derivatives, which the team basically dismissed for being too outdated.
ETA: I should clarify that I'm using Jira Cloud and we don't have many issues with speed (at least today, anyway. Maybe in a few years, who knows)
The complaints on the site generally criticize Jira from a technical standpoint, but it's important to realize that every "technical" shortcoming is based on a perceived organizational need: you never need the feature just for the feature itself.
So yeah, Jira is far from my favorite software -- it's bloated, slow, and embodies many product choices that make no sense to me -- but it's also possible to hate it because it doesn't support <obscure feature X> in exactly the way your organization has been doing it since you were working with spreadsheets, and that's not Jira's fault.
Many of the competitors don't fully understand this. They offer importers for Jira, but not an *exporter to* Jira. It's a pretty hard sell to even consider something else if I know I'm going to be stuck there. I wrote the tools for FogBugz to Jira migration and it took a stupid amount of time to do.
FYI: FogBugz provided a Jira exporter but it was abandoned (much like FogBugz as a whole), and was totally unusable for the migration.
The poorly optimized performance of JIRA almost makes me believe they don't even use their own product. Perhaps performance is on the backlog of the backlog.
I feel like this thread comes up in one way or another every few months but in a place where people almost have a hellbent desire to reinvent wheels nobody has reinvented this one in say...go or rails or whatever.
Why? Because for all of the hate jura actually does what it does pretty well when it's working and for most people and most businesses that aren't your homelab it works just fine provided you pay someone to maintain and administer it.
Also I'm pretty sure Jira saved my friend's marriage because he used the free version to coordinate finishing up their house.
Lastly while JQL has limited capabilities, it's better than having a bunch of API endpoints.
That being said it still baffles me how badly some UI elements are done there. Especially the menus would benefit greatly from some caching or preloading.
The people who decide which software gets adopted internally generally care about the latter, and thus Jira is selected, and thus Jira grows to their needs - where complexity is often a bonus, and poor day to day performance a minimal concern.
We're currently evaluating alternatives and what a transition plan may look like for ~5k issues with attachments/comments/mockups etc. Any products out there with a built-in JIRA migration tool?
How can it be proper to show me the outcome of applying JQL to a db query but refuse to show me the JQL because of an ownership/acl problem.
Want automation? Chain tasks but it has no "this" or "self" so that last thing you made? Have fun reconnecting to it.
So many options but no way to flatten them and define a template with specific ones: some are baked in and some can't be easily specified as important to float to top.
Still no clean way to uplift org to confluence with native support
Confluence is terrible but that’s a different product.
Edit: weird that an honest description of personal experience with Jira was downvoted to zero.
Does Jira suck? sure maybe, but my personal experience suggests that everything else sucks equally as bad if not worse, and I know where all the buttons are in Jira.
From that perspective it's easy to hate it, but you hate the actual use of the tool not the tool itself.
Currently i enjoy more sane use of it. Simple workflow. You get in, read the ticket, clicky a button, get out. Slowness in that regard is very tolerable.
All the reviews I see on that site seem to be upset that it might require training, or that their project's admins have made it a nightmare. It's not a nightmare out of the box.
On my "hate" list: Jira, Asana, Zenhub &/or Github Issues, Trello.
[0] https://www.zdnet.com/article/atlassian-estimates-cloud-outa...
I can rant about Jira, but it's about the horrible UI. It's buggy. The settings system is a mess. It's not intuitive. Even clever people need hand holding to figure out what's going on. Things randomly break for no apparent reason.
The gray text. Cmon, we have a roomful of ppl and 1 monitor.
Subtasks fuck up the whole layout. And appear above everything.
Suggestions that only include the 1st N values from a list. You have to know what youre searching for.
Can't preview fakeSprint until it's started.
No easily-available view of each developer's workload.
Are GitHub Issues the answer? I have only tried those for small open source projects and not big enterprise projects.
It's _far_ from perfect, but Gitlab Issues is a damn sight better than JIRA IMHO...
Yes that should be ridiculous.
I was similarly shocked when people bitched about confluence. First, do you have a better alternative? Second, do you undrstand the nightmare before jira and confluence?
This one caught me off guard. I know of no other free GUI for git that's as easy to use or install.
Anyone who's coped with VersionOne will nope back to Jira in a hot second.
And never built the thing.
Some of these made me chuckle.
That said, it's certainly not the Right Answer for everyone. But unilaterally hating on it is just kinda childish.
You create a kanban team-managed project and it'll pretty much be a Trello board. If you want sprints or a backlog or reports you can go into the project features page and flip a switch.
That is all.
Atlassian, please don't sue me.
If you're old enough to remember before Atlassian came along - just how was it better? Spreadsheets? Trax?
You don't want structured workflow? Don't work in a company with more than 5 people.
"I am an accountant and hate ERP" .. tough shit, for real.
Even when working on 'buckets of tasks/bugs' where Gantt charts don't make sense, a locally customized version of Bugzilla or other bug tracking software(i.e. Phabricator or whatever) worked very well.
There is a generation of engineers that has only known Agile, 2 week sprints, and shitty software to manage it. After having used Jira at two companies for the last 4 years I can say it is one of the worst pieces of software I have ever been forced to use and lowers productivity from multiple angles.