Why Jira Sucks • Hacker News Board

Re: Why Jira Sucks

#321

Post by prepend » Thu, Dec 31, 2020, 8:48 PM UTC

tootie wrote: post #153

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 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 does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard.

After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes.

It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams.

This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on.

This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.

Re: Why Jira Sucks

#322

Post by ccwilson10 » Thu, Dec 31, 2020, 8:49 PM UTC

specialist wrote: post #315

ccwilson10 wrote: post #303

Earlier quoted context omitted.

Welp... fun fact, every team (even the non-tech teams) uses Jira so I'll happily send over my venmo account :p

You can split the prize money with u/p2tp2. I legitimacy want to see this. Hire some film students, have them embed with some teams for some sprints, post the footage. If Atlassian really does walk the talk, why aren't you already bragging about it? I just peeked at Atlassian's YouTube stuff. Nicely produced. So that's something. I'm not even going to move the goal posts, or play No True Scotsman. Show how any team a…

Good point, not sure why we don't make more of a fuss about it. I think there should be some content about how our HR teams use Jira coming out soon so that could be a good first step.

Ironically, I was part of the group that just did the first ever official Atlassian Twitch stream the other day! Seems like an easy way to fire off content without needing a lot of approvals and checks. I'll chat with some people on the marketing side to see how hard it would be to just walk through our own setups. Saw this in a comment somewhere, but confirming we have a culture where process and setup are determined mostly on a department-by-department basis (at least for the non-tech side of the house). Our Marketing org generally works in an "agency" model where there are teams responsible for specific marketing disciplines (SEO, Video, Branding, etc etc).

Just on a side note, I'm happy to walk you through how we use it personally — Zoom, email, or whatever. Always trying to learn how we can make Jira better and try to share advice where I can.

Re: Why Jira Sucks

#323

Post by [deleted] » Thu, Dec 31, 2020, 8:50 PM UTC

tootie wrote: post #153

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 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

#324

Post by Supermancho » Thu, Dec 31, 2020, 8:52 PM UTC

Terretta wrote: post #176

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…

Have you read David Allen’s Getting Things Done and looked at that system? You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward. Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING. These core mechanics work . Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown str…

> You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do.

Stuff you might or might not complete is basically, everything. That's not a meaningful category list.

> These core mechanics work.

They work like a water-filled car coasting downhill. It looks like it's water-powered (or JIRA-powered) but it's just the gravity well of "looking busy" for the most part.

Maybe the in-car water fountain could be considered water-powered in practice, but that's a derail. Management gets approximations from JIRA because that's what they want, but JIRA doesn't provide it. A tool with a dependency graph could do much better.

Re: Why Jira Sucks

#325

Post by prepend » Thu, Dec 31, 2020, 8:52 PM UTC

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."

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 from a tiny, quick, useful note to a documentation slog when a new project manager joined and wanted a long description of everything typed into the ticket. So I ended up killing Jira altogether.

Re: Why Jira Sucks

#326

Post by threeseed » Thu, Dec 31, 2020, 8:54 PM UTC

TimTheTinker wrote: post #275

ogre_codes wrote: post #197

Earlier quoted context omitted.

> And I've also never worked anywhere that had a better option than JIRA. Agree with most of what you say aside from this bit. I find most similar systems are in the same ballpark in terms of being able to track what I care about. Mainly: - Is the ticket ready for me to work on? (Do I have the designs I need to work it?) - Who is working on a given ticket right now? - Am I done with a ticket? - Is the ticket ready fo…

GitHub does all of this very well. "Ticket" => GitHub issue "status" => current column on GitHub project. This includes "is the ticket ready for me", "am I done with a ticket", "is the ticket ready for QA", "did QA reject the ticket", etc. -- each of these is a column in the project board. "who is working on it" => assignee(s)

It only does it well if you have extremely basic needs.

It doesn't support custom attributes, workflows, approval hierarchies, statuses etc.

There is a reason ZenHub had to be invented after all.

Re: Why Jira Sucks

#327

Post by sam_bristow » Thu, Dec 31, 2020, 8:55 PM UTC

dig1 wrote: post #250

Why do I get the impression that either Zapel or clubhouse sponsors this domain? :) Anyway, from personal experience of working with large, distributed teams and (later) leading team that included developers, designers (who had no idea what software development workflow is), and electrical engineers, I have to say that still there is no replacement for Jira. And I'm saying that after trying dozens of alternatives. No…

Atlassian is in the process if killing off the self-hosted Server versions of their products.

It used to be really annoying that the plugins were split between Server and Cloud. You'd find the prefect plugin for your task and then find it was only available for Cloud or Server.

Re: Why Jira Sucks

#328

Post by Tomis02 » Thu, Dec 31, 2020, 8:55 PM UTC

LeonidBugaev wrote: post #283

For us Jira became the only option for scaling engineering. Do not bother about if you have less then 3-4 teams. But if you scale, essentially it is the only solution we found which can fit everyone needs, and give deep enough insights about engineering metrics. And obviously Jira can be very light or very complex. It gives you a lot of building blocks and it is your choice how to use it.

What kind of engineering metrics? Do you have any examples?

Re: Why Jira Sucks

#329

Post by GoldenStake » Thu, Dec 31, 2020, 8:55 PM UTC

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…

Slow, unresponsiveness, and worst of all lagged resizing caused my biggest daily annoyances in Jira. Several times a week, I click a task, and just want to click the link to an associated epic, or something. But that link keeps dipping and dodging my mouse.

I joined another team which used Asana, and it's much better, although certain things can still be slow.

Re: Why Jira Sucks

#330

Post by pm90 » Thu, Dec 31, 2020, 8:58 PM UTC

Kwpolska wrote: post #295

xxpor wrote: post #241

Earlier quoted context omitted.

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.

Let’s face it, most git logs have one-liner commit messages that may or may not describe the issue at a very high level. Even if you have long commit messages, they still are less likely to contain extended discussions about the issue (which can be useful many months later), and cannot be edited. In many places, commits are expected to have the Jira/bugtracker ticket number in the commit message, so that if I find th…

Except when the linked ticket is just a title with no content.

However, I would argue that even some of that metadata is better than no metadata. At least the ticket can provide some clues for anyone who is investigating a change.

I feel like GitHub issues are good enough for this purpose; unfortunately GitHub charges a per user license fee meaning that most non engineers don’t get access by default reducing its usefulness.