Hacker News Reader

There are three problems I notice with JIRA, of which two are entirely the product's fault. The first one you already mentioned: abysmal speed. The second is how JIRA forces certain ways of working which are clunky or intuitive (or by extension, out-of-the-box workflows are difficult to change).

The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary. Most developers do not need this info, and do not have the power to easily change things. All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket. I would believe this is not impossible to avoid, but I do feel a simpler structure using labels, milestones and issue tracker is far, far easier and less prone to being misused. GitLab and Github can both do this as far as I know.

And sure, JIRA integrates nicely with other products (Bitbucket, Bamboo, Confluence). Other products have these integrations on a more modular level and still load faster and have small QoL differences over JIRA. Maybe big corps need a bit more, but JIRA seems to be too focused on managers and suffers from feature creep to the detriment of user experience.

> is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary

Omg, finally someone has said it, I thought I was weird. This is the imperative problem with JIRA, it is not made to help the developers but to satisfy management which is buying the software. +1 for this comment. I have seen its usage in 7 companies and in each and every case instead of simplifying developers workflow it was complicating it due to management wanting to have their data which, at the end, didnt bring anything for the product but were just enabler to make their cute graphs that enabled them to not be involved into development cycle (as they should be) but rather bring out statistics "out of their shoe - JIRA".

And this is also my only (ok, except the slowness which should be understandable for any web browser js application) comment over the JIRA, I dont care what the tool is, how much time it takes (at the end, I am not paying for it), but how much it diverges from the tool that SHOULD help the development while in its essence it mostly helps the management to track their data.

Pretty much. We can divert a little to support customers reporting issues, though I don't feel JIRA is much friendlier here compared to GitLab once you get the hang of both. The only one I see benefiting from this monstrosity is management and upper layers, and they indirectly pay for this through lower morale and retention rates. If you really need the graphs that badly, you might as well spend a few hundred man hours to write a script that imports data, run some data science logic and draw them. And maybe put all that info.

> All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket

that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted

That comes back to the earlier point I made: developers often not having the power to change this. Others (and myself) already mentioned this is not a problem of JIRA itself, but rather JIRA being predominantly sold to management types that do not relinquish control and overconfigure the system.

I would love to see the insides of what we have configured, and toss the junk out. It ain't happening in the next 20 years, and I sure as heck don't plan to stay that long at a company putting little value in the experience of its employees.

Native support for Markdown in comments would be a good win.

In the Atlassian ecosystem, the markup languages are constrained by the following equation:

   JIRA Markup != Confluence Markup != Bitbucket Markup

Also even just within JIRA it can be inconsistent - I realised that to make monospaced text you need to use:

- backticks when creating a Jira ticket, e.g. `hello`

- double curly-braces when editing a Jira ticket, e.g. {{hello}}

... or vice versa. I cannot honestly remember which way round it is. Of the complaints I have about Jira this is probably the least annoying - but it really shows how irritating the product is.

I haven't used JIRA recently, but as far as I remember the difference existed because they were rolling out a "new" editor, which was active when editing tickets, but wasn't available when creating new ones.

I remember this caused me some data corruption when editing a comment created with the old version of the editor using the new editor. It was a mess.

This honestly would not surprise me. I’m kinda glad there’s an explanation, but I’m also annoyed it’s a stupid one

Cannot confirm, I always create issues with {{...}}

"or vice versa. I cannot honestly remember which way round it is"

It's vice versa, and this may be a small thing but it's my top example of how little they care about usability or product quality!

One hundred percent - it’s such a little thing, but as a developer it says a lot about the code beneath the product

I have to very much agree with this comment. I thoroughly enjoy using JIRA and Confluence. The two go hand in hand very well.

As many others have mentioned thought, it is abysmally slow. At least their Cloud offering is, which is the core product we use at my job. I've used older on-prem deployments though and they were lightning fast. Seems that they're deprecating this solution by 2024 though.

I recently completed a JIRA survey, and slowness was my number one complaint. Hopefully the Product teams read through those surveys or peruse HN. Everything else about JIRA works great for our Software Development needs.

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.

Jira Cloud has a new editor that is Markdownesque. Type as if you're using Markdown, and it will do the formatting you'd expect.

From your description, it sounds like this would have Slack's problem (which resulted in one of the most upvoted HN threads of all time, https://news.ycombinator.com/item?id=21589647). I've tried Googling around a bit to find an example of Jira Cloud's Markdown environment, but couldn't find one. (I am certainly biased, though, by my strong loathing of Jira.)

The new bitbucket markdown editor works fine actually, so I’d hope they used that.

FWIW, I prefer Jira's editor to Slack's.

Yeah, and in the end, you can export it as a word or PDF document.

Holy hell, what a tragedy. I used to write markdown and have pandoc typeset a pdf in the company design. Now I have word.

> competing offerings.

Any suggestions for that similar synergy? Doc/Issue Tracker/Code base integration?

I use pivotal tracker. Not all the features of Atlassian, but I've completed several projects with it, and it doesn't get in the way.

I've used both jira and tracker across a few different spots and can confirm that Tracker is refreshingly lightweight.

To me, tracker is an easier user experience for focusing on a stream of stories. And a more streamlined experience for work assignment means more time writing code to solve problems.