Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

Post reply on HN
Print view View original

221–230 of 530 posts

Re: Why Jira Sucks

#221

Post by Karunamon »

Lazare wrote: post #119

There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone , but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all ? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, b…

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible.

When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning off the permission checks, you replace all of this communication with the equivalent of 'return true'.

Unless you're running a multi-department enterprise-wide Jira ($deity have mercy on your soul), you're better off eliminating permissions entirely and controlling access to the instance at the network. In other words, if only your developers need access to it, do not add your developer user group to the various site permissions, set the permission to everyone instead, and ensure only your developer's subnets can touch it in the first place.

Re: Why Jira Sucks

#222

Post by runarberg »

avel wrote: post #208
runarberg wrote: post #194

Earlier quoted context omitted.

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…

No, a git commit is not transparent to product, QA, devops, infosec teams. Opening a jira issue to document a change that everyone should be aware of can take me literally one minute, and I've even assigned it to the sprint and version. "Developers don't like JIRA, they love GitHub": these are some generalizations that can often be true. However, you can also automate JIRA using your VCS of choice. You somehow make t…

See a nibling comment. In short: GitHub is developer friendly by default whereas JIRA is not. Ideally automation is set up in a way that QA, devops, infosec, customer service etc. get all the documents they need generated and cataloged automatically. It a) saves headaches from the developer and—more importantly— b) prevents pesky developers from making mistakes during the process (e.g. mis-categorize, etc.).

Re: Why Jira Sucks

#223

Post by aldanor »

Philip-J-Fry wrote: post #196

The one thing that annoys me is that even after all these years of JIRA they still haven't fixed their shitty WYSIWYG editor. I can't count the number of times I've written something and then end up with random asterisks all over the place because it failed to figure out what is bold or what's in a list or whatever.

Plus you have to learn their stupid formatting rules no one else uses, e.g. to insert code.

If it's so targeted at developers, why not use a monospace editor in markdown with easy code highlighting instead of the abomination they have?

Re: Why Jira Sucks

#224

Post by marcc »

d23 wrote: post #174
marcc wrote: post #167

Earlier quoted context omitted.

I don't think the comment was implying that a manager has to eyeball the ticket to make it worthwhile. The comment said there's value in documenting the process, and I agree with that. We use a ticketing system to track work. It's not Jira. But we do have a requirement that all work is tracked in that system. It's not so that a Product Manager or Engineering Manager can chime in and micromanage; it's so that we have…

It's just so obviously an absurd statement to say that if a bug is fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all. A huge portion of the day to day work of software engineering happens without explicit documentation of every decision for every change for every line of code. Life continues, software is built. The necessity for documentation exists along a spectrum, and t…

Who is claiming that if a bug fix fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all?

That's not my intent as the parent here, or the point I'm seeing or picking up from this thread. There's value in documenting in a system (Jira is one choice), but I know that I'm certainly able to see value in building a system and a process and then trusting that developers use them when appropriate and know when they are not adding value.

Re: Why Jira Sucks

#225

Post by fmakunbound »

It's so fucking SLOW.

I'm sure it has something to do with Angular or modern JavaScript development, somehow.

I'd rather poke my eye out than navigate around in Jira.

Re: Why Jira Sucks

#226

Post by bdavis__ »

eplanit wrote: post #126
Lazare wrote: post #119

There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone , but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all ? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, b…

It's the mainframe app of our time.

nah. mainframe apps are very snappy with that text only interface.

Re: Why Jira Sucks

#227

Post by ozim »

JIRA does not suck, it is people who are using it. The same with programming languages and frameworks.

We all suck just accept it and try to improve yourself and others point by point in that new 2021!

Re: Why Jira Sucks

#229

Post by BlargMcLarg »

stiray wrote: post #137
BlargMcLarg wrote: post #94

Earlier quoted context omitted.

There are three problems I notice with JIRA, of which two are entirely the product's fault. The first one you already mentioned: abysmal speed. The second is how JIRA forces certain ways of working which are clunky or intuitive (or by extension, out-of-the-box workflows are difficult to change). The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make managem…

> is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary Omg, finally someone has said it, I thought I was weird. This is the imperative problem with JIRA, it is not made to help the developers but to satisfy management which is buying the software. +1 for this comment. I have seen its usage in 7 companies and in each and every case instead of…

Pretty much. We can divert a little to support customers reporting issues, though I don't feel JIRA is much friendlier here compared to GitLab once you get the hang of both. The only one I see benefiting from this monstrosity is management and upper layers, and they indirectly pay for this through lower morale and retention rates. If you really need the graphs that badly, you might as well spend a few hundred man hours to write a script that imports data, run some data science logic and draw them. And maybe put all that info.

Re: Why Jira Sucks

#230

Post by dpcx »

runarberg wrote: post #194
tootie wrote: post #153

Earlier quoted context omitted.

I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…

A git commit is a "how," not a "what" or a "why." That's where JIRA comes in (if used properly). I don't love JIRA, but (IMHO) when it's used properly, it's a great tool.
Post reply on HN