Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

201–210 of 530 posts

Re: Why Jira Sucks

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

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…

You can complete JIRA tickets just by using a commit title format, and I don’t buy that there is a better system for QA to report the bugs or feedback themselves...

Re: Why Jira Sucks

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

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 without some kind of review, but there are things like cleaning up some annoyance around a dev VM image that doesn't require ticketing. A smart dev will likely tell people they fixed it (especially so teammates can update their VM), and a smart manager might document that fix with a ticket for their metrics, but my experience, is that organizations that laud autonomy in these kinds of improvements tend to have significantly greater actual velocity than ones that don't. I've lived through an org that reprimanded any change that wasn't documented (or really dictated) and it creates an atmosphere of apathy and distrust. The same org over time finally had enough personalities who lauded initiative that it was transformative, and the apathy evaporated.

Re: Why Jira Sucks

#203
Is it Jira that sucks or the management methodologies that cause it to be such a dumpster fire? Scrum-style management is the norm now: it is increasingly difficult to escape it now. So this means project managers are chasing burndown metrics and the like, and organizing everything on boards that are tweaked to death.

Atlassian is basically the centre of the so-called "Agile" industry these days. Jira is just a reflection of it.

Re: Why Jira Sucks

#204

Earlier quoted context omitted.

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

>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 attempting to mediate and regulate that collaboration via JIRA is a bad idea. A common, and bad idea.

Re: Why Jira Sucks

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

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…

You can automate the same thing with JIRA if you use bitbucket. I even saw process automation with Github and JIRA. This is just an excuse I heard from devs 100 times.

Re: Why Jira Sucks

#206

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…

> Fixing a bug without filing a JIRA ticket is in itself progress.

When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it.

Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason)

When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.

Re: Why Jira Sucks

#207
Missing... missing... missing...

I disagree. What makes JIRA a pain is that it has too much. It tries to be a solution for every possible workflow and ends up being a slow, clunky, and confusing solution for all of them.

I personally think the best thing Atlassian could do is spin of JIRA into multiple apps which all use the same core, but have different interfaces designed for different workflows. Of course, that's much easier said than done with such a ubiquitous monolith as JIRA.

Re: Why Jira Sucks

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

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…

No, a git commit is not transparent to product, QA, devops, infosec teams.

Opening a jira issue to document a change that everyone should be aware of can take me literally one minute, and I've even assigned it to the sprint and version.

"Developers don't like JIRA, they love GitHub": these are some generalizations that can often be true. However, you can also automate JIRA using your VCS of choice. You somehow make the assumption that only GitHub git + GitHub issues can be automated.

Re: Why Jira Sucks

#209
post #82

Earlier quoted context omitted.

I was looking at the homepage reading text that explained the Picture Gallery ("when users can reuse images... more likely to...") and then the whole page refreshed with a completely different design. I was on the page for probably about 30 to 60 seconds. Firefox 84 on Kubuntu Linux, no relevant addons.

Hi! That’s just a video playing on a loop taking you through the various screens. The “image gallery” is just showing our work item screen and then it jumps to some other screens. Thanks for the feedback though! It may be that this isn’t clear enough

I see, thanks. I scroll with the keyboard, not the mouse, so I did not notice that the next screenful was entirely a video.

Re: Why Jira Sucks

#210

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…

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 'pile of documents' organization model because it has a better wysiwyg editor and inline comment system.

Post reply on HN