Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

261–270 of 530 posts

Re: Why Jira Sucks

#261
post #185
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…

Its a poorly optimized Angular app IIRC

I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.

Re: Why Jira Sucks

#262
post #257

Earlier quoted context omitted.

> someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed…

> If I did, they would likely tell me to fuck off because they are busy with some other task. Great team dynamic if one of the members is blocked or has an issue because of something that another person wrote, and they get told to fuck off.

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.

Re: Why Jira Sucks

#263
post #153

To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…

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…

[deleted]

Re: Why Jira Sucks

#264
post #153

To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…

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…

I've not used JIRA in the long time, but in general I find source coontrol with issue tracking to be highly useful for working out why a particular change was made, several months after the fact, even if I wasn't the developer responsible (or even in the team).

Re: Why Jira Sucks

#265

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…

> All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted

That comes back to the earlier point I made: developers often not having the power to change this. Others (and myself) already mentioned this is not a problem of JIRA itself, but rather JIRA being predominantly sold to management types that do not relinquish control and overconfigure the system.

I would love to see the insides of what we have configured, and toss the junk out. It ain't happening in the next 20 years, and I sure as heck don't plan to stay that long at a company putting little value in the experience of its employees.

Re: Why Jira Sucks

#266
post #224
post #174

Earlier quoted context omitted.

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…

The original poster in the thread we're in:

"Fixing a bug or delivering a feature where you haven't documented the process ... is as good a running a web site nobody visits."

Re: Why Jira Sucks

#267
post #255
post #249

Earlier quoted context omitted.

My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.

Nice. This would likely solve a huge chunk of push back against JIRA.

Yes, I'd also enjoy jira if the company would pay someone else to use it for me.

Re: Why Jira Sucks

#268

Earlier quoted context omitted.

You are an assembly line robot.

Do you prefer to... not have all the details in front of you for a task you're about to work on?

Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you.

As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company, etc.

edit: anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone

Re: Why Jira Sucks

#269

Earlier quoted context omitted.

How do you prefer to gather the context for something that may have been hashed out months or years ago by different people?

The idea that a task can and should be "hashed out months or years ago by different people" is part of the JIRA mentality. And it is absurd.

[deleted]

Re: Why Jira Sucks

#270

To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…

Every single job I've worked that used Jira, also used google sheets to "map" actual work to Jira work. It has always blown my mind. All the meetings to update the google sheet, and then to update Jira, and then to ask why the two aren't in sync. It feels like I'm taking crazy pills. Why are we using a manual tool (google sheet) to keep track of the work, that's in our work tracking technology? What?
Post reply on HN