Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

411–420 of 530 posts

Re: Why Jira Sucks

#411
Everyone in our company hates redmine. We were doing great before when we used trello, but managers want to track and feel they have control of the projects.

Re: Why Jira Sucks

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

>...what they do internally bears no resemblance to that sage advice

You've gotten me really curious now. Got a link or a blog or something I can read about that?

Re: Why Jira Sucks

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

It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit, every time I... What’s the opposite of “delightful”?

Lightful?

Re: Why Jira Sucks

#414
post #346

What about the burn down charts? Every project I’ve ever worked on, features are finished, apps and websites are shipped, clients are happy and pay the bills, yet the burn down just goes straight to the right and never down. Sometimes right and up if people added more tickets during the sprint. We look at it at the end of the sprint and say ah well and continue on our way. Then sometimes a PM type decides it’s a prob…

That’s not really not a problem with the software though, is it? Draw your burndown chart on paper and you’ll have exactly the same problem.

Well it's at least an indicator something has gone terribly wrong. Your project management software, one of the flagship features of which is reporting - now tells you essentially "no work is being done". Somebody in management panics, the team is told to get its act together and some variation of "improve the numbers". Yet features are getting shipped and clients are happy. The two most frequent (bad) options teams take to get out of this are:

1) Ignore the burndown chart / any other reports. Everything is fine on the business side, so let's just accept that the reports are broken and not spend time trying to fix them.

2) Have everyone invest more time into using the system (usually on an ongoing basis), so that it produces the correct looking down-and-to-the-right chart.

The problem is that with #1, the software is arguably not producing much value, if any. The problem with #2 is that you're spending extra energy and effort to make the software happy, even though outside of the software it seems like your team is working well, shipping features and keeping customers happy - all of which are more important than a pretty graph.

Re: Why Jira Sucks

#415
post #352

Earlier quoted context omitted.

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…

The constraint for the org I work in is that GitHub has a per user license fee that makes it difficult to justify getting a license for everyone in the org since we have a lot of non developer staff. But everyone has access to confluence/JIRA. Does Gitlab also have similar license restrictions?

GitLab is an Open Source software that we host ourselves, no BS pricing scheme that silos the company unnecessary.

Re: Why Jira Sucks

#416
post #185

Earlier quoted context omitted.

Its a poorly optimized Angular app IIRC

I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.

Typing in the description field of a ticket lags and spins up the fans on my laptop. It's doing something wrong.

Re: Why Jira Sucks

#419
post #85

I am reading this comment thread and honestly I don't know that I agree. I think JIRA, like most tools, is as good or bad as you make it. I've been at numerous companies using JIRA that don't seem to have most of the issues referenced here. The only thing I've ever felt like JIRA really lacked in was in a good UX for embedding code snippets or other technical details into issue comments. Native support for Markdown i…

As a PM, all I really want out of the tools that I use is to be inspired by them. If I have to use it daily, it better have ideas for me to borrow. Jira does not inspire. It's what software looks like when it has no opinion. I hate it.

Re: Why Jira Sucks

#420

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…

Its Jira combined with outsourced or contract developers that only care about getting that feature added. Our app is a mess, loaded with technical debt and hugely difficult to support and use. 90% of devs dont care, they do add their one piece of new functionality and move on to the next one or next project.
Post reply on HN