Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

241–250 of 530 posts

Re: Why Jira Sucks

#241
post #167
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…

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.

Re: Why Jira Sucks

#243

Earlier quoted context omitted.

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…

I agree with your larger point but pointing to GTD as evidence that the "core mechanics" work is questionable. Many of its biggest advocates have abandoned it. > Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an a…

That article is interesting, but really just talks about one guy's journey with GTD (Mann), and another guy's great-but-different proposal for higher-than-individual level changes.

I spent a little time trying to find an actual study, however non-rigorous, about GTD, and this was the only real contender: https://www.researchgate.net/publication/222552899_Getting_T...

I don't use GTD in any explicit fashion, but to throw my n=1 in the ring, the overall concept of personal productivity changed my life. Anything can be taken to a harmful extreme, and I was (at least) annoying for the first few years. But I grew out of it and kept the good parts, and I have no doubt that, for me, this sort of thing was hugely beneficial.

Re: Why Jira Sucks

#244

Earlier quoted context omitted.

>and what happens when JIRA does not reflect the actual priority as observed by devs? Why do you believe devs alone define the "actual priority"? This stuff is collaborative, and I've worked with many devs who don't have the first clue as to what needs to be built by when in order to keep the business thriving.

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

Re: Why Jira Sucks

#245

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.

... have you ever worked on a project involving multiple teams?

I say this as someone who loathes JIRA but still exists in the real world where you need to collaborate to design something.

Re: Why Jira Sucks

#246
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…

See also, a comment from someone who worked on JIRA: https://news.ycombinator.com/item?id=25212441

Re: Why Jira Sucks

#247
> Missing Easy User Interface to Edit and Update Confluence

There is no “easy” UI for this. The problem to solve is merge conflicts, and Atlassian (rightly in my view) clearly decided that real-time collaborative editing of the draft beats forcing users to do merge conflict resolution when saving changes. Wikipedia takes that latter strategy and it's a huge hassle.

Re: Why Jira Sucks

#248
Jira is a generic issue tracker for any industry, not a bug tracker for software development. That’s why in 2020 it doesn’t work for software any more.

And it’s slow. And the UI is awful.

Re: Why Jira Sucks

#249
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…

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

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.

Re: Why Jira Sucks

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

Now, maybe things got changed in the last five years, but something where Jira still shines IMHO:

  * Self-hosted, free for small teams, you get access to *every* release they made. All these cloud-hosted solutions sound nice until they close the shop.

  * Almost infinitely configurable. Going from Jira to enter-your-favorite-simple-tool feels like going from Emacs to the chalkboard. Your CEO likes workflow X, sure. Your designer wants workflow Y, no problem. Your plumber used to Z, done. Irreplaceable when you work with the teams from different fields.

  * Bazillion plugins, integrations, name it. You are still missing something, go and write a plugin in any JVM language you like. It probably will work for all Jira versions with small modifications.

  * Management, CEOs, even front-end desks like it. Easy to sell, no matter the price. I had a harder time selling Zimbra (which is free) to CEO than Jira, because every CEO knows about Jira :D
Right, it got slow over time (I believe the main reason is clunky UI), but you have to pay the price for all those features. If I'm Atlassian, I'd probably add some optional light add-on UI, as Jenkins did with Blue Ocean.
Post reply on HN