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

341–350 of 530 posts

Re: Why Jira Sucks

#341

Post by pm90 »

prepend wrote: post #321
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…

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 meant for.

I do agree with you that it’s not practical to spend infinite time on fixing a problem. But it’s not strange for an engineer to think that way; in fact engineers who are willing to dig deep and at least root cause the issues (if not outright fix them) are very valuable to have.

Re: Why Jira Sucks

#342

Post by jeddy3 »

xxpor wrote: post #241
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…

the problem is it takes me 2 seconds to run git log to see if a bug has been fixed, vs going to a web browser, waiting for JIRA to load, waiting for a search to finish, curse at search for being useless, eventually find the ticket, and then see if it's complete.

Wow.

For a manager, this could easily have been written as:

It makes me 2 seconds to look in our issue tracking system to see if a bug has been fixed, vs opening a terminal, find the project, curse at grep for being useless,...

Of course omitting steps in your favorite solution makes it look easier.

And how is testing/validation tracked in how you use git?

Most of us don't work in a vacuum without managers, testers, customers.

And for the record, I as a developer also hate Jira, but we have to look at a reasonable solution.

Re: Why Jira Sucks

#343

Post by nemetroid »

dpcx wrote: post #230
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…

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.

A proper commit message should always have the ”why” (and, if necessary, the ”what”).

Re: Why Jira Sucks

#344

Post by etimberg »

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

Re: Why Jira Sucks

#345

Post by musicale »

SideburnsOfDoom wrote: post #84

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…

Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.

Re: Why Jira Sucks

#346

Post by Jolter »

waylandsmithers wrote: post #99

What about the burn down charts? Every project I’ve ever worked on, features are finished, apps and websites are shipped, clients are happy and pay the bills, yet the burn down just goes straight to the right and never down. Sometimes right and up if people added more tickets during the sprint. We look at it at the end of the sprint and say ah well and continue on our way. Then sometimes a PM type decides it’s a prob…

That’s not really not a problem with the software though, is it?

Draw your burndown chart on paper and you’ll have exactly the same problem.

Re: Why Jira Sucks

#347

Post by kazinator »

Sorry, no; a bug tracking system can be missing all those things and still not exhibit that intangible Jira suckage.

Simply adding more things to Jira that are supposedly missing won't fix it.

Re: Why Jira Sucks

#348

Post by ccwilson10 »

nlh wrote: post #338
ccwilson10 wrote: post #310

[Current Atlassian employee here] This might be biting off more than I can chew, but if anyone has tangible ways they think Jira can be improved for non-tech team members I'd love to hear them. Happy to chat via email or Zoom about them and try to add some of the fixes into the upcoming roadmap.

Based on everything I've sorta-kinda-summarized here, the #1 thing you guys could do is speed up Jira Cloud. My company uses it and tolerates it, but at this point it now takes 8-10s to load a single issue from the board view, and ~5s to toggle the edit state. There is basically not a single action I can perform that takes less than 5s to execute, and some take more (backlog, etc. view take upwards of 30s to load a f…

Whew. At 8 seconds I'd probably call for the tool to be removed. I had a similar experience while at Atlassian at one point and then we found a way to speed up the (Jira Core) boards by ~5 seconds after changing some JQL for the board logic. That change should be in effect for your org but you'd need to use Classic Business projects.

Fun fact, next-gen might actually be a reason why your instance is running slower. A side-effect of NG can be the slowdown from each project with its own custom fields and that effect multiplied hundreds of NG projects across an organization. Then (I think), when loading your project it calls all the fields to see which fields it should show. Not an ideal rec, but I'd check out Classic projects and see if that speeds things up for you and your org.

Speeding up Jira Cloud is a top priority for Atlassian this year so you should see some improvements coming. I'm working on a new view right now in Jira and we've been able to load about 100 issues in ~1-2 seconds. It lazy loads, but we can flip through 500 easily once you've scrolled to the bottom. Should be able to get that in your hands this coming year.

Re: Why Jira Sucks

#349

Post by ypeterholmes »

debaserab2 wrote: post #316
gurkendoktor wrote: post #238

Earlier quoted context omitted.

> And developers are expensive as hell. Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with…

> I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super cl…

Redmine is great.

Re: Why Jira Sucks

#350

Post by Sodman »

SideburnsOfDoom wrote: post #84

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…

The biggest problem with Jira, is that they give you the gun and the bullets to shoot yourself in the foot, while trusting you not to do it... The reality is that most teams (or let's be real, managers) can't be trusted not to shoot themselves in the foot here.

Adding more features and more process in general is going to be a net negative for developer productivity. But how well Jira (or similar tools) works for you is completely up to how you use it. Most teams I've seen that hate Jira et al usually have an overly complicated process, with far too many "states" for a ticket, a million mandatory fields, multiple assignees, etc. This naturally results in people spending far more time in the tool, which is time they could be spending actually doing productive work. Conversely, teams that like Jira tend to have very few ticket statuses/fields. Standups are quick, sprint planning is quick, everyone wins. Unless your job was moving things around in Jira for 20+ hours / week... in which case you'll need to find something else to do.

Post reply on HN