Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

311–320 of 530 posts

Re: Why Jira Sucks

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

> I feel that Jira's configurability makes it like desktop Linux 20 years ago.

Totally. A tool that's optimized for everybody is optimized for nobody. Jira for me is in the class of "false consensus" products. Since everybody has to manage work and get things done, there's an illusion that people mean the same thing by that. But the way people and teams work and the kind of work they do varies so greatly that there will never be one perfect work management tool.

Re: Why Jira Sucks

#312
post #210

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…

I haven't used gitlab's wiki specifically, but the reason why you would use something like confluence is because you get a wiki with a wysiwyg editor, so less technical people can use it without having to learn markdown and there is less friction to making docs. It's not specific to confluence. Hell google docs would probably beat confluence in a corp if they let you make a wiki structure out of it vs. it's current '…

I'd argue that Markdown is easier to learn than confluence wysiwyg, and also more useful in the long run. Especially as there are many GUI Markdown editors with buttons and preview windows, that give you best of both worlds.

Re: Why Jira Sucks

#313

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…

What really sucks is the cheeryleading and evangelism for it almost like a cult by the very people who are not responsible for resolving issues. Side channeling by email/phone with expenditure of social capital to devs in the know is quicker with our mutual wink wink agreement to file and close the Jira ticket to appease the higher ups above. Absolutely ludicrous.

Re: Why Jira Sucks

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

What they described isn't different of how it worked in my previous two companies that used Jira...

Re: Why Jira Sucks

#315

Earlier quoted context omitted.

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

You can split the prize money with u/p2tp2.

I legitimacy want to see this. Hire some film students, have them embed with some teams for some sprints, post the footage.

If Atlassian really does walk the talk, why aren't you already bragging about it? I just peeked at Atlassian's YouTube stuff. Nicely produced. So that's something.

I'm not even going to move the goal posts, or play No True Scotsman. Show how any team actually using JIRA, like a Twitch stream or something, and I'll cheerfully send you $100.

Forgive me, but I'm struggling to accept that anyone creating and maintaining and supporting JIRA and Confluence could abide by them. Sure, I've worked on crap products before. In anger, under protest. I never accepted it.

Re: Why Jira Sucks

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

> I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true.

I kinda feel this way about every project management tool, be it a personal or professional one. You're always chasing the dragon for how clean it was when you originally configured it.

Re: Why Jira Sucks

#317

Earlier quoted context omitted.

You are an assembly line robot.

I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots. Yes I'm an assembly line robot and…

Totally. I actually don't know how people that work in big enough organizations can possibly not like Jira (or a tool like it).

I would go crazy with the amount of things I would have to remember, their status, how to prioritize, how something was previously done and when, etc.

Re: Why Jira Sucks

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

Jira is typically not slow. It's usually the plugins you have installed.

Some plugins like big picture even have their own databases that need to be updated separately from the plugin, and can cause performance issues.

Start jira in safe mode and check the performance. Then check your plugins one at a time until you find the culprit.

They also have some nice built in tools that often help you find the source of these problems.

It's a product, but it's also a platform, and sometimes the stuff that is built on the platform causes the platform to buckle.

Re: Why Jira Sucks

#319

Earlier quoted context omitted.

It depends on your organisation size and structure, but probably you want to run the bug fix through some triage first (meh management overhead, but needed if you have many bugs to make sure the "important" ones are fixed), then code review (well, that doesn't happen in jira, but probably should be (automatically) reflected there to have one place to look later) and after fixing probably should be routed to the docum…

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

Re: Why Jira Sucks

#320

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.

heh you would be surprised. I literally closed a ticket from 2014 this week which had a lot of relevant information and prior discussion. Without the record of it somewhere I would of had taken much more time.

I also always search jira for a particular issue that I am having to see if someone else has already solved it or a reason for it not to be solved. Sometimes it works quite well saving me a lot of time.

Post reply on HN