I feel like hating on Jira is the pastime that is now passed down from each generation of programmers to the next.
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".
Yeah I've been defended Jira here in the past, too.
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 doesn't just reflect, it drives convoluted unhelpful bureaucracy. The tool drives the organization to look like the tool wants it to, which is disorganized half broken "organization" with silly overcomplicated rules that give people something to discuss enthusiastically instead of the actual work that needs doing.
Jira is organization poison, not just a reflection of what an organization is.
It's not a neutral tool. Jira makes micromanagement easy and trusting people hard; you can use it for good, but you're working against the grain of it the whole time. Everything is default deny (issues can only go through approved transitions, by default regular users can't change the available transitions), the default issue forms have way too many mandatory fields, and a bunch of reports that only micromanagers want or need are front and center in the UI.
"My opinion is that Jira reflects the organisation that manages it."
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 ;-)
The central problem with JIRA is that, once you've gotten beyond the overly customizable functionality and difficult-to-reason about permissions, and once you've managed to avoid organizations that go too far off of the deep-end and once you've finally found a happy simplicity in a kanban-ish board,
once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.
Yes, we switched to Jira from a piece of abandonware (simple php based bug tracker) several years ago. Jira is kinda slow sometimes, but not horrible. And yes, like you said, once you get it configured it works great.
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.
This applies to all enterprise software. It’s also called Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
> 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?).
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.
> why don't you think some other company has come along and toppled the Jira crown?
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.
I disagree with this. Absolutely, once Jira (or any particular project management tool) gets it's "tentacles" into a sizable enterprise, it's very difficult to dislodge.
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.
Jira's core positioning is huge companies with complex organizations that will be willing to adjust tooling to their needs. Sure small and middle size companies can be happy with it too, but they're far from being the main profit center.
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.
Crowns don't come from inherent value. They come from monarchy.
Jira holds the crown because so many are convinced the "industry" in which it leads is worthy or valuable.
What value does a monarch provide? Order. Structure. Authority. Corporate environments value these because - art its core - that is what "Corporation" is: a new system of governance.
Most of the complaints about Jira can be turned to Corporatism itself.
>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.
eh. I've experienced a number of painful tool and platform shifts in my career that basically came down to "it's cheaper" so I don't buy that companies are unwilling. If someone provides the feature set that is some combination of cheaper and better, then the only thing you really need is a migration path (Jira import tool in this case), and you'll be able to make some sales. Make enough sales and you start looking popular and that can provide its own inertia. The fact that this has not happened is, to me, evidence that nobody has done it better so far.
We start new companies all the time and nothing has been able to replace JIRA past the 5-10 engineers who know exactly what they are supposed to do stage.
It isn't that surprising that a programming language has inertia, it has lots of 'mass' so to speak -- programmers have to specialize in the language, and an ecosystem of libraries has to be built. It is more surprising to me that an issue tracker like Jira does. Surely people aren't specialized in... Jira-ing or whatever.
You mean as hard as when Git obliterated every other VCS within the span of a few years? If products are better, they get adopted. How do you think every single company in the world started to develop for iOS between 2008 and 2010? When the upside is obvious and the path to transition is well-defined, there is very little friction.
Doubtful. Unless you are working for a shitty company in the first place, bad tools essentially just get skipped and disused by autonomous teams and none of this matters. If the company 'embeds' a product in place of a workflow, that's not something a product is ever going to fix, that's an organisational problem.
>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.
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.
Agreed, it’s like a big flashing neon sign that promises middle management a stage on which to act out all their worst impulses. It’s the exact opposite of “keep it simple and communicate with each other like humans.”
If a company is trying to use JIRA for more than state communication they are doing it wrong IMO. Planning goes into calendars, ephemeral stuff goes into chats and calls, and code and code-level issues goes into repositories. I have seen plenty of attempts to make a product like JIRA the 'interface' between some management person and 'the subordinates' and it never works, simply because trying to place an 'interface' there in itself doesn't work.
> I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve.
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 optimized for productivity theater and top-down management
Hit the nail on the head.
I don't hate Jira.
I hate working for companies and with "micromanagers" that prioritize bs metrics over improving customer satisfaction, and busywork over impactful projects. And these kinds of people / companies always use Jira.
> building a generic project management and tracking tool is a really difficult, hard problem
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"
I mean, as a single individual, in some circumstances, sure.
If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that?
Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.
I agree, but wish/think this can change if the product is good enough.
Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it.
It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.
Yes this is exactly right, it’s all about top down feeling of control. You can very easily manage even a large organization with just basic Kanban boards
>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.
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.
I worked at a company once (not programming, more like an online shop) which did everything via email. And I mean everything. Tickets, issues, orders, repair requsts, refunds, you name it.
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.
> why don't you think some other company has come along and toppled the Jira crown?
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."
Yep. We often talk about enterprise software, and how it's often bad and, has superfluous features and almost no UX design because it is made for buyers rather than for the real users. Well, guess what. We're the users now.
Which is funny because 99% of what project managers seem to be about is making sure work gets done. So the first thing they do is deploy a hurdle to this by ensuring they use a tool which is time consuming and confusing for the people who do the work (usually developers to use) and enforce it's usage.
JIRA is so slow and the UI so clunky the project managers where I work use some type of spreadsheet upload mechanism with XML spreadsheets to automate the cruft creation. It's fun to watch.
> "Jira is the worst project management tool, except for all the others"
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.
I feel like a lot of great programming talent has been wasted by very smart engineers who felt the pain of their current ticketing system and spent years building countless startups only to end up with something occasionally marginally better than Trac (2004).
Back in 2008-ish a lot of projects I came across tried to use Redmine because their company had a sucky JIRA or sometimes even Mantis implementation. Redmine turned out to be highly unsuitable in a matter of a few months and after trying out a few options that are mostly just tickets+kanban boards, it turned out that the simplest 'fix' was just setting up an individual JIRA just for the team so it could be used properly instead of some heavy handed top-down "use this tool in this specific way" approach. Once more teams started to do it, the 'company-wide' JIRA essentially just contained managers and a few product owners and it got deleted in a year or so.
Afterwards, all the 'team JIRAs' got merged into a normal JIRA again, but this time everyone had full control over their own projects and boards, problem, solved.
Same here, I really don't get the cargo cult hate against Jira.
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.
I think the problem is not what it does or solve. I have used jira in 8 companies, maintained an instance in 2 of them and I have never seen a fast one nor figured out to make them fast.
Any single click you do on it reminds you of the time when people were waiting literally minutes to be able to do anything when booting windows on a laptop with 5400rpm hard disk.
Whatever help it is for your company, it makes you pay for it with billions of swears.
>Same here, I really don't get the cargo cult hate against Jira.
That's funny, because I've always thought of Jira's most ardent defenders as a cargo cult. As this comment section indicates, Jira can do no wrong. It can only be done wrong. Cult.
I think those of us who have had to suffer through ClearQuest, Lotus notes etc have an entirely different scale on how bad things can be compared to those who appear to really really hate Jira today. I'm not a fan of Jira but atleast it loads, eventually.
Your point is admirable but its also short sighted. You're right that building a one size fits all tool is a large task and it's easy to complain about something hard.
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 couldn't agree with this more. What people hate is not Jira but the organisational thinking that it facilitates. I've used jira in other contexts and it's been mostly a joy because the processes it modelled were happily simple.
> I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now).
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.
I upvoted your comment because I believe it's a perfect example of what I was trying to point out: it is impossible to please everyone with a company-wide project management tool, but the fact remains that it is a necessity.
For all the people bitching about how Jira makes it hard to work like they want to work, their are folks like you who will complain that Jira makes it to easy to get around a company-wide standard.
To emphasize, I'm not saying either side is right or wrong, I'm just saying it's impossible to build a project management tool where large subsets of people won't complain about the exact same set of features that another subset of stakeholders likes.
Yeah. My employer has company managed projects on by default, and there are several features which still haven't been re-implemented from OG team-managed Jira, particularly around workflow automation, that have tickets from 4 years ago saying "we're looking into implementing this in the next year!"
> 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.
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.
> The fact is, building a generic project management and tracking tool is a really difficult, hard problem.
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.
> "Jira is the worst project management tool, except for all the others"
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.
> why don't you think some other company has come along and toppled the Jira crown?
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.
It's not that I think is a particularly good or bad implementation of project management software (though I think as others have pointed out, in its effort to be all things to all people, I think it has converged on a lowest common denominator solution). I reject the concept of general purpose project management software. I think that at best these tools are primarily surveillance tools for middle management. They disempower workers and make them fungible. The workers are evaluated on tool points rather than the actual value they create (sometimes these may be alignment, but often they are not). At worst, I think they actually lower product quality because of the poor incentives that are inherent in a system that rewards closing issues and creating "features".
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.
I'm not sure that is quite the right take. When someone says "Jira" they are referring to the style of product management that Jira enables, not the specific tool. Like how "Google" is used to refer to web search, even if one actually uses Bing.
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.
> 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.
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.
A few years ago I worked for a company that used https://shortcut.com/ (at that point, it was named clubhouse I think). I loved it. I think that tool can do everything Jira does in a much better and saner way. It looks a lot more organised, more flexible, more polished, more performant and it doesn't look like it will force you into full SCRUM if you don't want to. You even get to use the same syntax (markdown!) everywhere. Last time I had to use Jira I needed to keep in mind the syntax for writing links in the issue description was different than the syntax for writing links in comments. Tell me that's not some top level suckery.
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.
> the organization-wide problem Jira is trying to solve
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)
>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
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 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.
The problem being: "how to create BS data and metrics to satisfy a bureucracy"?
I think the issue is that because Jira offers the hope of a tractable customizable management process, it invites management to put in more process to improve their visibility of a project. This should not result in micromanagement, but it usually does. From a programmer's vantage point this is lose-lose, because your day to day tasks are weighted down by Jira-related bureaucracy, and your mastery of your schedule is continuously threatened by managers peering down from above to ask questions about this and that individual item on your work list.
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.
Additionally, people's associations with Jira are not strictly related to the software itself.
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.
I was asked during a merger, which work management tool do you think we should keep/use? I replied, don't ask me, I'll hate it anyways.
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’m not sure what “the usual complaint” about Jira is. It sounds like you perceive the usual complaint to be about feature bloat. You only briefly mention speed, which is the only complaint I had about using Jira as an IC developer. From the perspective of an IC I think all these systems are incredibly similar. Jira is the only one that was, very simply, ridiculously slow. As in 5-10 seconds to load any page.
> It's always taken on from the position of "well, it didn't make my specific use case easy"
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.
You need SOME kind of tool to provide a repository of issues and assignments, and Jira could probably be fine.
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.
The problem with Jira is that it is checkbox software, designed to sail through the checkbox procurement processes that large organizations have. "It checks all the boxes!"
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.
JIRA is the medium that cranky devs interact with disinterested managers. It's just a vessel for data and metadata. And as far as I'm concerned it's one of the best at doing what it does. There's no tool I prefer to JIRA. Asana is a joke by comparison. TFS is just Bad JIRA. Issue trackers like Trello or GitHub issues are fine for creating a dumping ground for ideas but not for organizing.
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.
> Issue trackers like Trello or GitHub issues are fine for creating a dumping ground for ideas but not for organizing.
There’s an argument that you should use an issue tracking system for tracking issues and not planning. Features and stories don’t necessarily neatly subdivide into tasks and issues. Issues don’t always neatly fit into a story or feature.
I really, really love Shortcut. Unfortunately our org is looking for a traditional Gantt chart, and Shortcut is a bit lacking in that.
However, up to this point in our company, it's been great. It's very deliverable-centered. Stories are the deliverables and are the centerpiece of the flow.
Tasks just make up a to-do checklist for a story - there's no endless wrangling about that is a task, there's no credit for doing a task (shitty devs can't game the system). Shortcut feels like it hits a nice spot between the monster that is Jira and too-basic tools like Trello. Shortcut is made for developers.
You must have been using some alternate-universe Jira. The Jira installations I've had to suffer with fall over bulk editing a handful of issues. I've never seen a "bulk edit" like feature implemented as poorly as it is in Jira. It shouldn't take 15 seconds to complete a simple bulk edit of a handful (single-digits) of issues.
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.
I don't use Jira. I'm aware of what it basically is. We're small, we use a pin board, 3x5 cards, and a drawer.
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.
For really large, complex enterprises managing a complex portfolio of products with dependencies between them I have found Rally to be a little better than Jira. It isn't any simpler or faster than Jira, but it's better at tying the whole enterprise effort together.
I'm on the same page as you, I don't love Jira either, it's not something I think about in the conversation of "software/services I enjoy using" - but I think it's _fine_.
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.
I think the answer to your question is that it's because the complaints aren't actually mostly about the tool, but about the processes the tool targets. Jira competes both with different tools and with different processes that use neither Jira nor its competitors.
I agree. I routinely explore JIRA replacements b/c of various JIRA annoyances, but none of the ones I find will hook into our process as neatly as JIRA.
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.
I get paid for developing plugins for Jira since 2014. One can complain about UX and speed of this software, but I saw it being the hearth of businesses of all kinds and sizes.
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.
the funniest thing to me is that you used a throwaway to defend Jira .
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.
And SAP, and Oracle, and every other over-complicated thing that causes more harm than good. OK, many other such things may be even worse; but it's definitely in that category.
Jumping on the "Jira isn't the problem" bandwagon, 99% of what people hate about Jira now is that the people who manage it make Jira hard to deal with.
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.
Does Linus use JIRA on that little project called the Linux kernel? Why is git with good readmes and clear pull requests not enough project management?
If you're not doing PR's you are just LARPing software development.
I don't hate JIRA, I hate "IT" employees that can't program.
No Linus uses Bugzilla [1]. Have you ever used it? You'll be begging for Jira once you've used Bugzilla.
Also Linux doesn't use pull requests. GIT doesn't even know the concept of a PR. You are supposed to generate a patch with 'git format-patch' and submit it to a mailinglist.
The Kernel isn’t managed solely through patches and README files. There is often a lot of up-front communication and documentation.
My takeaway is that the planning and the issue/bug-tracking and the patch submissions are three seperate somewhat independent processes. There are no managers trying to group all the tickets into patches and patches into projects in some sort of neat (but illusionary) hierarchy.
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.
9. The text editor is still busted and I just don't understand why. It's one of the most important parts of the UX, please please fix it. Writing any kind of nicely formatted long form posts is a lost cause.
Amusingly, it used to be great! When I first started using JIRA, it was just markdown. Then they introduced their WYSIWYG editor, but at least they still had the button to see the raw markdown and you could still edit the raw markdown (but the GUI made terrible markdown so if you wanted to use markdown you better start with that and never touch the GUI).
And then I guess at some point they just removed the markdown part?
I make an effort to write detailed comments about what I did, what I discovered etc. This is really helpful to reproduce the issues, and a few months down the line it helps to clarify exactly what happened.
JIRA text editor is FUCKED. Try adding bullet points after a code insertion. Does not work. I have to first create all the bullets, then step through them and write out whats on my mind. For more complex stuff, I just write in my code editor. How can you fuck up the most basic functionality?!
My gripe for the text editor—if you navigate away from the page, by an accidental click or keypress, all your text is lost. This kind of thing was solved 15 years ago; it's table stakes!
Definitely this 100% I proposed for company game night: Predict where the Jira cursor goes next in response to right arrow. There’s so many possibilities: right left up down, teleports, disappears. My favorite is when the cursor splits into two at two different seemingly unrelated locations. Two cursors?? How do you even do that in a text area?
The worst thing is that I nod along in agreement with all 9 points, and still find myself easily preferring a pragmatic well set up Jira (yes a unicorn) to juggling things around 25 trello boards or a siloed top down micromanaging corporate hellscape overconfigured Jira.
But the last time I enjoyed using Confluence was in the 1.x days with non wysiwyg wiki markup. Confluence been truly awful for a while now - eg why can't I ever find what I'm searching for?
In defense of complex permissions, this often ends up being necessary to avoid single points of failure. For example, if someone can turn off the setting preventing force push to the master/main branch, that person should not be able to commit code thereby requiring more than one person for a commit to be force pushed in practice. Even better would be to require a config change like that to be approved by more than one person, but that can be difficult to implement compared to adding in narrow permissions. Even if you just prevent force pushing in general, another common bypass would be disabling CI for certain commits (such as in cases where the CI infrastructure is down and the commit is necessary to fix some ongoing incident). Yes trusting developers is always going to be necessary to some degree, but that doesn't mean absolute trust is required all the time.
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).
I don't understand why I can't see a ticket on my board because some team in another company once requested a seemingly unrelated feature. It's trying to be too many things to too many companies all at the same time, and thus ends up as an unusable mess of complex settings.
> 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.
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.
This is a solved problem. The most efficient way to search Jira is to type random characters into the search bar until you find the ticket you were looking for on page 3 of the results.
Find the person in your organization who knows JIRA. After he doesn't manage to find it, open outlook and search for it in the notifications@jira folder, where you would most likely find it
I just wrote the search query to our PM, since I was unable to find anything myself... I don't understand why just couldn't use, IDK, a shared spreadsheet, even that would be more productive (from my perspective)
I wish the comments were more specific about which features they don’t like.
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 wish the comments were more specific about which features they don’t like.
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.
> 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.
It's very useful for when the user submits a ticket with "My computer isn't working" as the title and "excel is broken" as the description.
I had a similar thought: Jira is very customizable; if people hate something that is so customizable then part of what they're hating is the organizations customization of it.
I've seen the same thing at multiple companies. Someone comes up with a Jira workflow, it doesn't match the needs of some people, but the company wants to standardize on that workflow, so now people are stuck using a stupid workflow that doesn't work for them. I've also seen a bunch of stupid custom fields on every single ticket. Is this Jira's fault or the organization's fault? You complain but the word from your immediate manager is that the team is already in hot water so escalating complaints about the Jira configuration isn't going to help, etc.
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, we had tickets in done states that just roll over to the next epic, like they were still open. Nobody knew why, and it went away with nobody making any fixes to anything.
- 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.
All valid criticisms, especially the slowness and heavy page sizes. Another perspective on 3 of your points though (and a free quality-of-life tip!)
> For a while, we had tickets in done states that just roll over to the next epic, like they were still open. Nobody knew why, and it went away with nobody making any fixes to anything.
I almost guarantee someone forgot to set the resolution field when creating a workflow transition, noticed and went back and fixed it.
> Bulk operations are just a PITA
Agreed that the UI is jank AF, but it works reliably on the order of tens of thousands of tickets at a time.
> 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.
Almost every operation you want to do this for can also be done by right-clicking and “move to.” There’s “move to top of backlog”, “move to sprint x”, “move to top of column”, you can also ctrl/cmd click (or shift-click) to select multiple issues.
> 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.
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.
The Vera functionality in Jira likes to move me ahead in a test sequence, so each time I touch something in a long test sequence I have to make sure I’m on the right test step.
This is something browsers should solve. If the thing you clicked on wasn't there 0.2s ago then you didn't intend to click on it, so just ignore the click. And add an API for twitch games to turn this off.
Everything turning into an edit action when I just want to click a link or copy a bit of text is super annoying! Also is thinking you're in a text field, typing out something and realizing you've done a whole bunch of random actions because of all the hotkeys.
The #1 thing I want out of every project management thingy I've used is the ability to have direct links to a ticket/issue or list of tickets/issues load as a basic HTML page, that's either read-only or uses a "save" button rather than persisting edits instantly. Provide a link to the full-fat version of the page, on the off chance I want that.
I just want tickets to load instantly (trivial, if you're not loading an "app" with it), not use hundreds of MB of memory and tons of background processor cycles (ditto) so I feel like I can't just leave it open, and not to have to worry I'll click in the wrong place or accidentally trigger some hotkey thing and screw something up.
Let the PMs have their version of the site with live-edited everything and janky (because Web) drag & drop galore and a whole universe of hotkeys and combos. I just want a fucking web page with the info I need.
The composer in general. I often have to intersperse log/code lines with prose, and there’s no telling what the Formatting menu will do. Some times selecting a formatting will apply to selected text, sometimes not. Sometimes it will apply when choosing a formatting then pasting text, some times not. Some times it seems to apply to a selection as well as everything after it. It does support Markdown with backticks for monospace, but that’s a lot of manual editing I would rather not do.
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 :)
Not being able to embed images in comments sucks. It's not always clear which images people are talking about when they all get dumped in to the "attachments" section.
It’s like trying to describe why a McDonalds $1.99 burger is bad, to someone who just lists ingredients and insists it has just the same mayo, cheese & patty as a $12.99 burger does.
It’s not about any single feature being missing, it’s just terrible the same way Vista was terrible
> 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.
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. "
> I'd like a really easy way to see all of the tickets I've ever completed.
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 can't help but wonder what PM tools Atlassian developers use. Surely it can't be JIRA? Maybe they have some browser extensions that make the interface less frustrating.
Yes, but also Jira the tool with it's horrendous UX, janky markdown (which is also different from Confluence's wtf), memory foortprint, slow loading, slow everything, controls moving from under your cursor just as you're about to click them...
Honestly, it's a horrendous piece of software however you look at it.
This is true. I too would rejoice to see Jira die in a fire; but the fact is that if that happened, another tool would be used instead, and the same dysfunctional management processes would just re-emerge.
What I really hate is not Jira itself, it's the company behind it and its engineering practices. Their mediocrity goes beyond Jira.
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 think calling Atlassian mediocre is a bit generous. Confluence is a steaming pile of burn garbage that still can't get basic thing's like SVG working[1]. Atlassian can't give a darn, they have their captive market and they are just riding the gravy train now. The last good thing they did seems to be to buy trello, but they will likely turn it into garbage if the rest of their portfolio is any indication of what to expect.
> The last good thing they did seems to be to buy trello, but they will likely turn it into garbage if the rest of their portfolio is any indication of what to expect.
Either that (turn it into a "JIRA Light", with just a little less of the annoyances?) or just kill it off altogether -- either way, it eliminates the competition from what Trello used to be.
Which was of course precisely why they bought it, so them doing that was actually not at all a good thing.
That diff message is really annoying indeed, but that is not the only thing that leaves in the browser session. I have set up my browse to be wipe clean every time I close it, and a lot of things like PR notification for update also live in the session. So if I reopen the browser all the PR are marked with blue circle.
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.
In my experience, Jira is the dog that begins to resemble its owner. If you are working in a toxic, dysfunctional organization, Jira will reflect that:
- 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)
> - Thousands of tickets that would probably take 30+ software devs 100+ years to implement
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.
We've automated this in our propriety system. After an amount of time with no activity, change requests expire and someone can resubmit if they're still valid, otherwise they close after a number of days. They also get a notification in advance in case they want to investigate validity before expiration. Has worked well for us since our software is decades old and the number of change requests are substantial.
Closing issues without actually fixing them is depressing. It may be beneficial overall.
There could be alternatives e.g., label such task as "fun" and hide them all the views by default, then allow developers to spent say 10% on any of "fun" task of their choosing (no expectations).
It may help with burn-out for some devs and the issues that are worth fixing according to at least by some devs are getting closed eventually.
One I found particularly annoying was having too many hierarchical levels for taks. Something like : Client, Contract, Deliverable, Product, Release, Change Request, Requirement, Task, Sub-tasks
I came from Apple (and their excellent Radar issue tracking tool) to a company that uses Jira.
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.
Also ex-Apple here. Radar does suffer (to a lesser extent than Jira) from a profound defect, though: Searches are "exact match" for whatever text you put in the title. To find a bug YOU filed, you have to remember the exact words and sequence you used in the title. Did I say "resize window" or "resize a window?"
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.
That seems weird... is it too hard to feed everything into an Elasticsearch index? Even with default settings and some decent hardware you'd get good stemming and relevance ranking pretty easily.
I'm sometimes kind of surprised at how often I see people say they don't mind it. It's by far the tool I like the least out of everything I've used at any job I've ever been in.
Same, I check into Jira once per day, max. It's useful to give an overview of what everyone is working on in the "Kanban" meetings twice weekly. I use quotes because we really don't follow any strict rules or structures, everyone just kind of does what needs to be done to keep things moving forward.
It's a tool for the boring part of software engineering- I don't expect it to spark joy. I wish it were faster, scaled the full width of my monitor, allowed external editors, etc. Overall it gets the job done well. Everything else that I've used is horrible which makes it the best in my experience but that's still not saying much.
I only use Jira for defect tracking and not project planning. In that regard it seems to be only slightly worse than Github/Gitlab's issue tracking. It'd be kinda nice if it supported Markdown but it's not a big deal.
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.
It's quite easy to have a minimized exposure to jira as a developer. I hate its guts but if my interactions are limited to writing a few tickets and changing statuses then its awfulness is more somebody else's problem and it doesnt bother me nearly as much.
If it's set up properly, it's easy for developers to browse the tickets, log work on them, and update their status - and that's all they will need to do. So, from their perspective, it's fine. However, getting to that point is unnecessarily difficult, and if you fail, that difficulty spills over into the developer experience.
I've used Jira in my last 3 jobs. I tried to like it, I tried to tolerate it, now I just try to spend as little time using it as possible.
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.
Readit News
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.
https://en.wikipedia.org/wiki/Conway's_law
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.
Crowns don't come from inherent value. They come from monarchy.
Jira holds the crown because so many are convinced the "industry" in which it leads is worthy or valuable.
What value does a monarch provide? Order. Structure. Authority. Corporate environments value these because - art its core - that is what "Corporation" is: a new system of governance.
Most of the complaints about Jira can be turned to Corporatism itself.
eh. I've experienced a number of painful tool and platform shifts in my career that basically came down to "it's cheaper" so I don't buy that companies are unwilling. If someone provides the feature set that is some combination of cheaper and better, then the only thing you really need is a migration path (Jira import tool in this case), and you'll be able to make some sales. Make enough sales and you start looking popular and that can provide its own inertia. The fact that this has not happened is, to me, evidence that nobody has done it better so far.
Doubtful. Unless you are working for a shitty company in the first place, bad tools essentially just get skipped and disused by autonomous teams and none of this matters. If the company 'embeds' a product in place of a workflow, that's not something a product is ever going to fix, that's an organisational problem.
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.
Hit the nail on the head.
I don't hate Jira.
I hate working for companies and with "micromanagers" that prioritize bs metrics over improving customer satisfaction, and busywork over impactful projects. And these kinds of people / companies always use Jira.
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
I mean, as a single individual, in some circumstances, sure.
If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that?
Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.
Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it.
It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.
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.
Generally speaking any organisation, given enough time, can establish processes that are better than JIRA with a certain amount of luck.
However, that's the best case scenario.
It's a standard distribution. Sometimes a 100 person project gets by fine with email. Sometimes it all goes to shit.
A tool like JIRA is, on average, a lot better than doing it via email only.
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...
JIRA is so slow and the UI so clunky the project managers where I work use some type of spreadsheet upload mechanism with XML spreadsheets to automate the cruft creation. It's fun to watch.
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.
Afterwards, all the 'team JIRAs' got merged into a normal JIRA again, but this time everyone had full control over their own projects and boards, problem, solved.
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.
Any single click you do on it reminds you of the time when people were waiting literally minutes to be able to do anything when booting windows on a laptop with 5400rpm hard disk.
Whatever help it is for your company, it makes you pay for it with billions of swears.
That's funny, because I've always thought of Jira's most ardent defenders as a cargo cult. As this comment section indicates, Jira can do no wrong. It can only be done wrong. Cult.
This is essentially it.
The developer facing UI of Jira's competitors is MILES ahead of Jira.
Jira's "director level" UI is miles ahead of its competitors.
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.
For all the people bitching about how Jira makes it hard to work like they want to work, their are folks like you who will complain that Jira makes it to easy to get around a company-wide standard.
To emphasize, I'm not saying either side is right or wrong, I'm just saying it's impossible to build a project management tool where large subsets of people won't complain about the exact same set of features that another subset of stakeholders likes.
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.
There’s an argument that you should use an issue tracking system for tracking issues and not planning. Features and stories don’t necessarily neatly subdivide into tasks and issues. Issues don’t always neatly fit into a story or feature.
However, up to this point in our company, it's been great. It's very deliverable-centered. Stories are the deliverables and are the centerpiece of the flow. Tasks just make up a to-do checklist for a story - there's no endless wrangling about that is a task, there's no credit for doing a task (shitty devs can't game the system). Shortcut feels like it hits a nice spot between the monster that is Jira and too-basic tools like Trello. Shortcut is made for developers.
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.
Deleted Comment
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.
Also Linux doesn't use pull requests. GIT doesn't even know the concept of a PR. You are supposed to generate a patch with 'git format-patch' and submit it to a mailinglist.
[1] https://bugzilla.kernel.org/
My takeaway is that the planning and the issue/bug-tracking and the patch submissions are three seperate somewhat independent processes. There are no managers trying to group all the tickets into patches and patches into projects in some sort of neat (but illusionary) hierarchy.
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.
And then I guess at some point they just removed the markdown part?
I make an effort to write detailed comments about what I did, what I discovered etc. This is really helpful to reproduce the issues, and a few months down the line it helps to clarify exactly what happened.
JIRA text editor is FUCKED. Try adding bullet points after a code insertion. Does not work. I have to first create all the bullets, then step through them and write out whats on my mind. For more complex stuff, I just write in my code editor. How can you fuck up the most basic functionality?!
But the last time I enjoyed using Confluence was in the 1.x days with non wysiwyg wiki markup. Confluence been truly awful for a while now - eg why can't I ever find what I'm searching for?
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).
I don't understand why I can't see a ticket on my board because some team in another company once requested a seemingly unrelated feature. It's trying to be too many things to too many companies all at the same time, and thus ends up as an unusable mess of complex settings.
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.
It's very useful for when the user submits a ticket with "My computer isn't working" as the title and "excel is broken" as the description.
I've seen the same thing at multiple companies. Someone comes up with a Jira workflow, it doesn't match the needs of some people, but the company wants to standardize on that workflow, so now people are stuck using a stupid workflow that doesn't work for them. I've also seen a bunch of stupid custom fields on every single ticket. Is this Jira's fault or the organization's fault? You complain but the word from your immediate manager is that the team is already in hot water so escalating complaints about the Jira configuration isn't going to help, etc.
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).
We use jira as a way to track ongoing tasks, we use subject, description, comments/attachments, and assigned to.
- 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.
> For a while, we had tickets in done states that just roll over to the next epic, like they were still open. Nobody knew why, and it went away with nobody making any fixes to anything.
I almost guarantee someone forgot to set the resolution field when creating a workflow transition, noticed and went back and fixed it.
> Bulk operations are just a PITA
Agreed that the UI is jank AF, but it works reliably on the order of tens of thousands of tickets at a time.
> 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.
Almost every operation you want to do this for can also be done by right-clicking and “move to.” There’s “move to top of backlog”, “move to sprint x”, “move to top of column”, you can also ctrl/cmd click (or shift-click) to select multiple issues.
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.
Absolutely trash.
I just want tickets to load instantly (trivial, if you're not loading an "app" with it), not use hundreds of MB of memory and tons of background processor cycles (ditto) so I feel like I can't just leave it open, and not to have to worry I'll click in the wrong place or accidentally trigger some hotkey thing and screw something up.
Let the PMs have their version of the site with live-edited everything and janky (because Web) drag & drop galore and a whole universe of hotkeys and combos. I just want a fucking web page with the info I need.
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...
https://en.wikipedia.org/wiki/J%C4%93ran
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.
https://www.atlassian.com/migration/assess/journey-to-cloud
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.
Honestly, it's a horrendous piece of software however you look at it.
Dead Comment
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.
[1]: https://jira.atlassian.com/browse/CONFSERVER-1762
Either that (turn it into a "JIRA Light", with just a little less of the annoyances?) or just kill it off altogether -- either way, it eliminates the competition from what Trello used to be.
Which was of course precisely why they bought it, so them doing that was actually not at all a good thing.
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.
There could be alternatives e.g., label such task as "fun" and hide them all the views by default, then allow developers to spent say 10% on any of "fun" task of their choosing (no expectations).
It may help with burn-out for some devs and the issues that are worth fixing according to at least by some devs are getting closed eventually.
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.