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

391–400 of 530 posts

Re: Why Jira Sucks

#391

Post by buttscicles »

enra wrote: post #272
silvestrov wrote: post #40

1. It is dog slow. 2. It is dog slow. 3. It is dog slow. ... When my team had an important as-quickly-as-possible sprint, we dropped Jira and switched to Google Docs as it was much easier and faster than Jira. My conclusion was that Jira doesn't do much for developers that can't be done in some Google Docs/Sheets.

Working on a much faster issue tracker: https://linear.app We build it so that almost everything you do in the app instant (<100ms)

Linear is the real deal. Love the keyboard shortcuts & speed.

Re: Why Jira Sucks

#392

Post by bombcar »

pigeonbacon wrote: post #233
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…

Do you know that this post is actually breaking the JIRA ToS? Seriously, it's in their ToS that you can't complain about how slow JIRA is... > Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products https://www.atlassian.com/legal/cloud-terms-of-service JIRA sucks

This is phenomenally hilariously bad, but quite common (I believe Oracle has a "no benchmarks" clause).

Re: Why Jira Sucks

#393

Post by eddieh »

aard wrote: post #377
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…

I fully agree that the problem is the "JIRA mentality". Specifically, that a developer should be managed with a task list instead of giving them roles/responsibilities in the organization and letting manage the tasks themselves. Sadly, almost all project management tools fall into this trap. A whole different type of tool is necessary to get us out of this rut.

The irony is that I always had my own task list that I kept in parallel to Jira that allowed me to break a Jira issue down into subtasks, subsubtasks, down to any depth of n(sub)-tasks. The best part was that there was no "process" for my task list. It was always just TODO and DONE. Nobody had to review my list or approve it and I could delete and add entries as needed with zero friction.

Re: Why Jira Sucks

#394

Post by tootie »

aqme28 wrote: post #219
mdoms wrote: post #162

Earlier quoted context omitted.

> 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. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eye…

Elaborating on your point. When has JIRA actually been effective as the documentation for a bugfix? JIRA in its most effective will just tell you whether we agreed to do this work and the state the work is in. It is not "documentation."

We have an automated process where emails to our support distro go to JIRA and Slack via Zapier. No user request or bug report gets lost. Issues with insufficient info get followed up on by an ops/support person. All feedback and actions go into the ticket. Something that can be worked around is documented and resolved. True bugs get logged to the dev backlog and linked to the support ticket. Works like a charm. The users can see the ticket history without really learning much about JIRA. Devs in know exactly how the issue was reported and triaged. Probably 3/4 of issues are resolved without a dev ever being roped in. And no user ever wonders what happened to their request.

Re: Why Jira Sucks

#395

Post by closeparen »

ajkjk wrote: post #289
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 disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't kno…

Commercial artistic endeavors are deadly serious about schedules and coordination. Broadway and Hollywood have some of the most intense and impressive project management in the world. They couldn't survive without it.

But it does look pretty different from tech project management. Department heads are not treated as task monkeys. They are treated as being potentially myopic about their own pieces of the puzzle, and given support on integration with the rest of the production.

Re: Why Jira Sucks

#396

Post by SideburnsOfDoom »

grendix wrote: post #244
SideburnsOfDoom wrote: post #204

Earlier quoted context omitted.

> Why do you believe devs alone define the "actual priority"? This stuff is collaborative, I do not believe that, of course it is collaborative. Some things are emergent, some are not. Some can be neatly broken down into fixed length tasks, some cannot. Some are planned, some are not. Some are top-down, some are bottom up. Some are obvious business function items, some are leftfield ideas. I'm just feeding back that…

It's kind of weird how the subtext to every conversation in this topic is bad management, yet nobody wants to come out and say it.

You're not wrong, but also "we shape our tools, and thereafter our tools shape us". ( Marshall McLuhan )

JIRA tends to shape management into bad management. That is the grain of the tool.

Re: Why Jira Sucks

#397

Post by rightbyte »

jakevoytko wrote: post #188
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…

> 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 responsible for budgets. As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based ar…

> When the only project language you have is trees, it's difficult to talk about forest.

That was so wise I am almost crying. The "local maximas" hurt my engineering soul. It is inferiating in the long term.

Re: Why Jira Sucks

#398

Post by firepoet »

josephg wrote: post #375
orzig wrote: 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.

That would be great. On a client project a few years ago I effectively bullied the product owner into doing that. We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and…

That is such bad Agile. No wonder people have such bad feelings about it. :-(

Re: Why Jira Sucks

#399

Post by keithnz »

contravariant wrote: post #141
polote wrote: post #133

Earlier quoted context omitted.

Any better software to replace it ?

I don't know if better software can replace stupid management but I've been quite happy with Youtrack. That said you can do some extensive micromanagement with that as well, though it requires some coding to do the truly intricate stuff, which just might be enough to prevent the managers from getting any funny ideas ;-)

it's weird why youtrack doesn't come up more often in these types of discussions. It's pretty good, and interestingly enough they now have a "lite" ui mode to simplify it. It's not perfect though, but I've found it hard to find anything better.

Re: Why Jira Sucks

#400

Post by ajkjk »

maccard wrote: post #387
ajkjk wrote: post #290

Earlier quoted context omitted.

This is not how it happens in my experience. The other developer, who sees their teammate's daily updates and code reviews, would just say "oh this was fixed yesterday". The manager trying to assign work is a tedious redundancy here; the engineers do a better job of owning the problems if the manager goes away.

I work on a team of 70 developers (directly) and another 50 or so work on a shared code base between our project and others, and I make daily modifications to that shared code. all those developers are spread from PST to CET+1. Bugs that get fixed are sometimes done by domain knowledge holders on he base team, and those fixes are large fixes that get done on a different release schedule to mine. Its an utter waste of…

It really depends on the situation. If you have a small team that owns their own codebase, then people will generally know what's going on. In a large codebase with multiple branches it's going to be messier. If everyone's sharing a bug tracker it should be easy enough to claim bugs you're working on.
Post reply on HN