Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

441–450 of 530 posts

Re: Why Jira Sucks

#441
post #331

Earlier quoted context omitted.

I’ve seen Jira be the source of truth for user stories related to changes. It was neat at first because you could track why something was changed and what it was supposed to do, and even have a user confirm it’s working the way they expected (I hate when bugs are closed because the dev thinks it’s fixed but it actually isn’t). The ticket would point to source or git log if you wanted more detail. Sadly it developed f…

Wouldn’t it have been easier to explain to the project manager that there were costs associated with documenting the minutiae, get them onboard and continue to use the system that has worked for you? (Genuine question, not a rhetorical one)

I thought so, but I wasn’t successful. I’m not sure how much was just someone new trying to change stuff and someone who really believes in writing tons of stuff.

I don’t think the problem was jira, it’s just in project management thinking that it is the most important part and the dev work is subservient or easy.

Re: Why Jira Sucks

#442

Earlier quoted context omitted.

A customer I am currently working with has a JIRA instance which literally, looking at the firefox network inspector right now, takes 13.04 seconds before it's done loading. It takes at least 10 seconds before the page will even let me scroll. I can't even comprehend how they have managed to get this poor of performance.

Does it keep reloading batch.js? Is it because the URL is changing or is it just not getting cached at the browser? Answering these questions is a first step to speed up Jira. See also my comment from 2018: https://news.ycombinator.com/item?id=18511497

This is like web optimisation 101. What you did is a clever workaround, but it shouldn't be necessary! Why isn't the Jira server sending compressed content in the first place? If those javascript files are static, they could even cache the compressed versions for extra speed!

Re: Why Jira Sucks

#443
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…

At the network? How would that work with people working remotely?

Re: Why Jira Sucks

#444
post #341

Earlier quoted context omitted.

I once worked with a developer on a relatively small team of 10 people or so (3 other devs) who said it was impossible and pointless to estimate effort for tasks. He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done. It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs…

You want devs to not care about anything but fixing technical problems though. At the end of the day: technical problems can have hard constraints that dictate the usefulness of your product and the people who have the skills to investigate and fix them should be dedicated to using those skills to fix such problems. Worrying about users, funders and other teams is what Product/Project and Engineering managers are mea…

The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.

Re: Why Jira Sucks

#445
post #365

Earlier quoted context omitted.

So... "shouting across the room" for a ticket which is so trivial it doesn't need to be documented is OK, but telling someone to "fuck off" for doing it is not? Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.

Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room. The best teams I have worked with tend to be more collaborative.

There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will get handled quicker because usually multiple people can take care of the task and the one who has free time first can handle it.

An atmosphere where interrupting people randomly is commonplace is almost never good for productivity.

> The best teams I have worked with tend to be more collaborative.

Collaborating doesn't require interrupting people in the middle of a task.

Re: Why Jira Sucks

#446
post #439

Earlier quoted context omitted.

> If devs aren't working on priority items Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.

Developers absolutely should not be deciding what is 'priority'. It's very unlikely they have access to the metrics, wider business strategy, internal and external stakeholders, necessary to determine this. That is the job of the Product Manager.

And, Developers absolutely should not be excluded entirely from deciding what is 'priority'. People at the cutting edge should have input.

Re: Why Jira Sucks

#447
post #434

Earlier quoted context omitted.

Why is this a problem? Was it difficult to create a Jira ticket? When last i used Jira, it took a few seconds to create one. Less time than it takes to write a commit message.

Not the person you responded to, but I'll take a swing. In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are in the middle of a sprint. you are not allowed to change the sprint. 2 weeks (or whatever) later you have a meeting, where you have to argue for your ticket being next. That probably doesn't result in success, but pretend it does. Then it gets assigned to some…

Great comment, and I'm glad you replied with these examples. The problems you describe are corporate software development process problems and not problems with Jira or bug trackers in general. It's a dysfunctional company welding their dysfunction onto Jira, and Jira gets the bad rap. Most of the time when people on HN complain "I hate Jira!" what they really mean is "I hate my company's inflexible software development process." Jira just happens to be the UI surface that this horrible process is exposed through, so naturally they take their hatred out on Jira.

Here are a few process examples I've seen (taken from real companies):

Company A: Bug tracker contains a handful of bugs and features, but you can pretty much commit whatever you want, whenever you want, without a ticket. Lots of work, major and minor, being done totally untracked through anything outside of git log.

Company B: Everything you touch requires a ticket, full stop. Ticket creation and assignment is a laborious process as you described in your comment. Sprint scope enforced ruthlessly. Sudden changes in scope and dependencies must wait until the next sprint.

Company C: Strictly one ticket per commit. But if you need to make the change, just create the ticket, document your change there, and close the ticket. No big deal. If you're not working on the right stuff, your eng lead or project manager will notice when they browse through the assigned and closed tickets.

Company D: Just like Company C, but without the "one ticket per commit" rule. You could commit whatever you wanted as long as you could point to a ticket that described what it was for, and you could use that ticket over and over and close it when you were ultimately done.

Company A was total chaos, and we constantly missed deadlines and chased quality problems. Only eng really had a clue about what work was done, in progress, or in the backlog. The eng leads simply kept it all in their heads and documenting/communicating was an afterthought. Company B was frustrating and bureaucratic, but we at least managed to ship most of the scope on time and with reasonable quality. Not great eng morale but management was happy with output. Company C was the best. Really easy to derive project status by just looking at the bug tracker. The "create a ticket" habit was drilled in to you during orientation and was just not seen as a big deal. Company D was kind of a mixed bag. Eng loved it, but it was hard for the managers to track progress because you always had all these "mega-bugs" open listing commit after commit after commit, and there was no indication of % completion.

I didn't mention the actual bug tracker for any of these companies, because it really doesn't matter. You can use any bug tracker to support any of those processes. There is nothing Jira-specific here.

Re: Why Jira Sucks

#448

Unpopular opinion: it doesn’t suck. Let me walk that back a bit - I have no experience of the cloudy version which unanimously seems to be derided as slow. Atlassian - you might wanna fix that. Like yesterday. But server (& datacentre) editions - best in class for my money. In terms of features, the Rally / Agile Central (did that just re-brand again?) rollup roadmap view is the only missing feature i crave. Atlassia…

I kinda agree. I am fine with using Jira. Now when I know the workflow I would not bother with another tool for the same things that we are forced to use Jira for.

That said I would rather to "issue tracking and planning" in a checked in text file and maybe have some bug tracking tool rather then working with Jira.

Re: Why Jira Sucks

#449

I'm surprised this doesn't mention things like the poor performance, or the fact that some screens expect text in textile format whereas others use markdown

It is probably written by some marketing team that hasn't actually used Jira. Who really cares about those bullet points they present.

The main issue is lag and clonkyness and forcing ppl into the cloud according to me. Not missing more custom workflow ...

Post reply on HN