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

301–310 of 530 posts

Re: Why Jira Sucks

#301

Post by [deleted] »

turbinerneiter wrote: post #187
SideburnsOfDoom wrote: post #172

Earlier quoted context omitted.

> Jira makes it easy to track what's actually going on. No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".

Exactly. What's going on is commits and merges. They live in GitLab. There is also tickets in GitLab, which all developers are happy to use. There is a wiki as well, which, gosh, is just markdown in another repo! Markdown you can build beautiful PDFs from! And websites! But nope, we need JIRA and confluence, because for some reason GitLab isn't good enough. Now the tickets are separate from the actual work, there is…

[deleted]

Re: Why Jira Sucks

#302

Post by wpietri »

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…

Exactly. Computers having infinite capacity is sometimes harmful. One of the things I like best about kanban approaches, especially with physical cards is that they discourage putting in too much. When I look back on previous boards (e.g., [1]), my main thought is we still had too much room. We wrote up and carried along so many cards we never got to. But even so, that's way better than something like Jira, because the limited board meant limited opportunity to distract ourselves with meta-work.

[1] https://williampietri.com/writing/2015/the-big-board/

Re: Why Jira Sucks

#303

Post by ccwilson10 »

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.

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

Re: Why Jira Sucks

#304

Post by dblohm7 »

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…

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

So much for Agile!

Re: Why Jira Sucks

#305

Post by p2t2p »

specialist wrote: post #293
p2t2p wrote: post #291

Earlier quoted context omitted.

> They don't. Funny. Can I get $100 please? Every team has their own process that is tailored to their needs, process is decided by devs, not managers, managers only do "I'd like to have this kind of visibility" requests some times and I yet to see those requests introducing any kind of burden, usually very miniscule things. We have very simple process in our team with two issue types for devs - task and bug. We have…

Sure. Post the video(s) and a Venmo account. > Sprint planning is about 30 minutes... That's like saying Santa Klaus is real. I want to believe you. I really do.

By the time we're in planning, only things to discuss is estimation and priority, it takes virtually no time. We have a whole hour booked and spend half of it to just hang out, pretty much the only time where the whole team is present in one meeting.

Re: Why Jira Sucks

#306

Post by ogre_codes »

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)

I haven't used GitHub for this, so I'll take your word for it.

The fact that there are a lot of ways to track these issues well was exactly my point.

You need some way of tracking these things. I've used JIRA and it got the job done. I've also used other tools which worked as well. What doesn't scale is not tracking issues.

Re: Why Jira Sucks

#308

Post by wpietri »

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…

You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices.

If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, everybody here knows that's not true.

I think the true way to optimal resource usage is not through ever-increasing process and managerial layering. Instead, it's through tight feedback loops where small cross-functional teams iterate closely with the people they're serving. Which is exactly how most good startups work. If you were really right about pursuing a financial optimum, the first thing (very resource-constrained) startups would do is get a copy of JIRA and hire some middle managers to carefully parcel out the work against precisely designed specs and timelines. That they don't should tell you something.

[1] https://en.wikipedia.org/wiki/Managerialism, and also see https://www.amazon.com/dp/B00A76WZ96/

Re: Why Jira Sucks

#309

Post by Hallucinaut »

SideburnsOfDoom wrote: post #198
jeff303 wrote: post #180

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.

I dislike Jira, but it's quite untrue that it's absurd that there needs to be context and a record of discussion for tasks. People leave, focus changes, memories fade.

It's not a unique occurrence that I wonder "why the hell is it done like this?!" only to find it was a decision I was part of with developers who had left in a least-worst-change trade-off. Jira or products like it help us avoid repeating the same mistakes.

Put another way, part of the art is not just the code, but the code that's not there. Jira/tickets are one way of managing that data.

And at other times, it's just a tool for bureaucracy, I get that.

Re: Why Jira Sucks

#310

Post by ccwilson10 »

[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.
Post reply on HN