Why Jira Sucks • Hacker News Board

Re: Why Jira Sucks

#331

Post by pm90 » Thu, Dec 31, 2020, 9:00 PM UTC

prepend wrote: post #325

aqme28 wrote: post #219

Earlier quoted context omitted.

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

Re: Why Jira Sucks

#332

Post by kabes » Thu, Dec 31, 2020, 9:01 PM UTC

Jira sucks because middle management wants to be able to look at stats about stuff like estimated vs achieved points to get a fake feeling of control and hide the fact they are useless powerpoint generators.

Re: Why Jira Sucks

#333

Post by tomphoolery » Thu, Dec 31, 2020, 9:02 PM UTC

Is there a better product out there that can communicate what the development team is doing to non-technical people?

I like Jira when I don't have to use it. For example, setting up GitHub automation so that changes from Git will cause tickets in Jira to transition to the next stage. Or, automating a transition from "Pending Estimate" when a Jira user assigns story points to a ticket. The automation features in Jira are far beyond anything I've ever used before (one might even consider it an "IFTTT for project management"), and on most teams I've been on, very much under-utilized. I can even automate starting the process of development when design is finished, as when the design ticket is marked "Done", the development ticket it's linked to will change to "Pending Estimate", as it's now possible for a developer to estimate how long it will take to implement the given design.

Re: Why Jira Sucks

#334

Post by debaserab2 » Thu, Dec 31, 2020, 9:03 PM UTC

specialist wrote: post #280

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…

> ...you haven't documented the process... How does JIRA help with that? I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA. My $100 bet: They don't. While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.

I can't speak for Atlassian dogfooding, but I don't find this to be a very true statement:

> While Atlassian has great confidence for how you should run your projects

JIRA really doesn't. It's extremely flexible, which I think is where it earns a lot of it's bad rep. You can really map your entire mental model to it's statuses and workflows if you want to (but you shouldn't).

The teams that I've been on that have had success with JIRA are ones where JIRA only encompasses the minimal amount of process as possible to represent the status of an story/bug/initiative with as little extra added as possible. The other key thing I've noticed is using it as consistently as possible so it can actually become the central repository (found a bug? make a bug ticket. have an idea thats starting to take shape? make a story ticket. fix a bug? put the ticket number in the commit). Seems like common sense, but usually needs to be strictly enforced, especially with individuals that are on the fringes of the development process (such as subject matter experts).

Re: Why Jira Sucks

#335

Post by pm90 » Thu, Dec 31, 2020, 9:03 PM UTC

coredog64 wrote: post #319

milesvp wrote: post #202

Earlier quoted context omitted.

I think you might be missing another dimension, in that it depends on the size and type of bug. "See a problem fix a problem" is a common mantra in physical work type environments I've been in. You don't wait for a manager to tell you to pick up a debris that's fallen in a forklift path. You clean it up. This doesn't quite translate as well to software, you certainly don't just want to make production code changes wi…

Typically how I've seen this work in high-functioning environments is that devs aren't scheduled at 100% according to JIRA. They have time set aside in their schedule for work of this nature. They'll fix the bug, create a JIRA for the commit/PR, and get on with things. The coworkers on PR reviewers and get their notification that way or in standup. If it's more than 30 or 60 minutes they might log some time against i…

On a team I was on, there was a rule that we simply wouldn’t bother documenting 1 point JIRA tickets as then the documentation itself would likely take more time than just making the change.

Re: Why Jira Sucks

#336

Post by ci5er » Thu, Dec 31, 2020, 9:04 PM UTC

waylandsmithers wrote: post #101

Does anyone here get to use Basecamp? It looks awesome and I’ve read up on their Shape Up process but have yet to find any organizational support for it in my professional experiences.

The ui is a little non-intuitive, but good for small teams. For repetitive process work or small distributed teams, I also like Azendoo or even Asana (which has the reports that managers crave)

Re: Why Jira Sucks

#337

Post by kevsim » Thu, Dec 31, 2020, 9:06 PM UTC

wyck wrote: post #132

kevsim wrote: post #82

Earlier quoted context omitted.

Hi! That’s just a video playing on a loop taking you through the various screens. The “image gallery” is just showing our work item screen and then it jumps to some other screens. Thanks for the feedback though! It may be that this isn’t clear enough

Some constructive advice, your homepage is messy, the ratios and spacing are really off and makes it hard to digest and focus on your features. This will directly impact your actual product. Please don't be insulted , I've spend 20 years in design/branding and want you to succeed but this homepage isn't doing it, you need a brand book with some strict guidelines.

Not insulted at all! Very useful feedback.

Re: Why Jira Sucks

#338

Post by nlh » Thu, Dec 31, 2020, 9:06 PM UTC

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 few hundred issues).

This is just not OK. And we're using hosted, Next-Gen. No fancy customizations.

Every. Single. Click. takes 5s+ to register a reaction. I'm on a gigabit internet connection and have a 16" MacBook Pro with all the dials turned up (eg it is NOT me).

Re: Why Jira Sucks

#339

Post by ryanbrunner » Thu, Dec 31, 2020, 9:08 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 definitely used issue tracking systems to look into why a bug was fixed a particular way - if a fix is non-intuitive, including the issue # in the commit messages can give you a lot more context than just a commit message.

Re: Why Jira Sucks

#340

Post by ccwilson10 » Thu, Dec 31, 2020, 9:09 PM UTC

probably_wrong wrote: post #138

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…

> Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think. You don't like that the ticket form has 50 fields you don't need? No problem! All you need to do is to convince your manag…

I honestly wish it was that simple for us but convincing management is a fairly sales-driven approach and our marketing model is heavily self-serve. We do have a product called Jira Align that's targeted closer to what you're describing. I'd attribute more of the spread to the concept of "Jira is the defacto" fwiw.

Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself.

Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".