Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

161–170 of 530 posts

Re: Why Jira Sucks

#161

JIRA is a bit like linux. It only really sings when you have a skilled admin to set it up and maintain it. I have used a whole bunch of ticket/project managing tools in a number of different orgs. By far the most useful is JIRA. taiga.io comes close, but lacks the admin interface and multi project overview that jira has. Trello is ok, but terrible for large teams, or large projects. Subtasking is a pain and there is…

My smaller team settled on Asana and I really like it. It's much more approachable than JIRA, and while not as powerful, much more so than Trello. Subtasks/relating tasks to other projects is great and I can easily see a birds-eye view of my upcoming pipeline (referencing tickets on other projects) at any time.

Re: Why Jira Sucks

#162
post #153

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…

> 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 eyeball the ticket.

Re: Why Jira Sucks

#163
post #153

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…

> If devs aren't working on priority items

Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.

Re: Why Jira Sucks

#164
Jira sucks but it's not because of these reasons. In fact if you fixed each item here, it would be worse.

Jira sucks because it is unopinionated and infinitely customizable. As a result, everybody who believes they've discovered the perfect project management setup (spoiler: they haven't) is empowered to cook up their vision via an inscrutable set of customizations. This leads to a bunch of inconsistencies between projects and endless bikeshedding. I imagine all this dynamic configuration is also the reason their cloud hosted version is so painfully slow.

Re: Why Jira Sucks

#165
post #15
post #13

Great article. As you are likely not native English, just as a tip you can actually simplify a lot of statements by removing the word ‘the’. As one example: > When the users need the features from Jira and request them to configure the plugins for many application scenarios, which contribute to the overall complexity of UIs. Becomes > When users need features from Jira they request plugins, which contributes to UI co…

Are both equally correct?

No offence but I couldn’t understand the example without the correction.

Re: Why Jira Sucks

#166
post #87

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…

100% this. JIRA is bad because it encourages managers to use it to do stupid things, not because it’s inherently bad software.

We can say laptops are bad because they let people create bad software too. Jira is far from perfect but there isn’t much that solves what it can in an integrated manner.

Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?

Re: Why Jira Sucks

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

> 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 a record of the fix that's easy to find, track the conversation around it, and be able to reference it 6 months or later. Documenting how it was fixed and tested and verified is very useful. Having a place for a manager to eyeball tickets before they are working is not the value of the system.

Re: Why Jira Sucks

#169

Earlier quoted context omitted.

I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.

You are an assembly line robot.

This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.

Re: Why Jira Sucks

#170

Earlier quoted context omitted.

I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.

You are an assembly line robot.

Do you prefer to... not have all the details in front of you for a task you're about to work on?
Post reply on HN