Why all the Jira hate? I’ll tell you why | Hacker News Reader

Why all the Jira hate? I’ll tell you why

andykelk.net

18 pointsgitgud18 comments

My 2 big problems:

a) It . is . so . incredible . very . slow, it . takes . 7 . seconds . to . load . a . page . when . hosted . on . atlassian.

b) Search is bad. It might be possible to find issues I have commented on 1-2 years ago and I have commented on and which contains some text, but the interface and results are no where near as good as a simple text search in Mail.app. This makes Jira a black hole where everything disappears into and is never heard from again.

Besides the above, my main issues with Jira:

1. When I just open the main page, it opens to whatever my last search was, which is almost always what I'm least interested in. Open issues assigned to me would be more useful, for example.

2. When I open an epic, there is no simple way (that I'm aware of) to hide the many associated issues that are closed already so I can focus on the outstanding ones.

3. Its visual editor is buggy, marking individual inline words as monospaced often fails.

There's probably more. I guess some of these issues could be workes around or configured if I became a power user, but it really doesn't make me want to.

On the plus side, the integration with the other slow and tedious Atlassian tools works OK and does give a generally quite useful set of tools.

The last-search thing is configurable, depending on your version of Jira. You can have it open to a specific RapidView, or your user-configurable Dashboard page, where you can add a Widget for a a specific JQL like "Assigned to me AND NOT issuestatus = Resolved"

Not that this exonerates JIRA of being clunky, but hopefully you can improve your experience.

I've thought a lot about the speed, and am very curious from an organizational perspective how say, a person managing an engineering org might not feel the same frustration from slow page loads.

Do they only open it occasionally? Do the pages they use open more quickly?

Anyone managing teams of engineers that can chime in? :)

It is super slow for me as well. The usual Jira pages at least a full minute to render.

Almost every ticket gets "accidentally" into edit mode and I have to click a button to get of edit mode but a slight click on text sends right back into edit mode.

I've written to Atlassian at least 2 times about this but they keep adding more JS to the page so I don't think the page will ever be light enough on my workstation.

I don't follow any of his arguments.

The author suggests that Jira is partially to blame for people who don't fully understand Agile software development. I would argue it's not the software that's the problem.

Bad practice in workflows? If you have a bad workflow, the software is not the issue.. and the author's argument that making workflows is 'difficult', just doesn't hold water with me.

His final argument to steer clear of Jira because physical paper is 'better' isn't even an argument against Jira, it's an argument against all organizational software.

I never knew there was jira hate before this posting, and only leaves me wondering 'Why all the Jira hate?'

Github/Gitlab (gh/gl) for source control is [almost] universal in enterprises, but it is quite confusing to me why these enterprises end up not using gh/gl issues for task management and tracking. Both of these now have well implemented project boards and these are way faster and more usable than traditional alternatives including Jira. For a developer, it is way easier and more effective to spend time creating and updating issues in gh/gl than using an entirely different solution. Open source projects have already demonstrated the effectiveness of gh/gl issues, but enterprises continue to rely on "enterprisey" solutions. I think this is mainly because the choice of project management tool is in the hands of developers in case of open source, but mostly with project/product managers in case of enterprises. As long as this remains the case, developers employed with enterprises will continue to have to live with tools that provide sub-optimal user experience.

Edit:

There is a good reason for project/product managers to prefer Jira and similar products. They want to be able to create dashboards with some very complex queries for reporting, and also features such as moving an Issue from one project to another, etc. In short, it provides management features that PMs rely on for reporting progress up the management chain.

I would say that in the enterprise you would have for example a global strategy of the company for the next years. This would somehow map to your department and then somehow to your team. This means not everything needs to be sourcecode but probably Epics derives stories and derived tasks which might span across the company.

Physical boards have a nice feel to it but you can only put so much on it.

On JIRA, Trello or whatnot you have the chance to provide some more context using extensive descriptions, pictures, references, urls.

I guess if you have a team which is not distributed, and everybody is on the team 100% of their time and you manage that your holidays overlap a lot, it might be feasible to have a physical board. Otherwise I see all this communication overhead to explain to everybody what the thing on the board means in detail.

This. Six years in we're past ticket #45k. Thats a lot of documented work and history that is valuable to be able to search.

I'm two years in on a greenfield project, looking back at the old tickets does happen, but rarely.

I guess you could treat as a poor man's documentation, though our tasks are not written in that perspective.

> Physical boards have a nice feel to it but you can only put so much on it.

I’m wondering if maybe that is the single most important property of physical boards. You have an immediate and tangible feedback that maybe you should stop creating new tasks, and work in getting existing tasks done first.

> On JIRA, Trello or whatnot you have the chance to provide some more context using extensive descriptions, pictures, references, urls.

All of those should not be on a board. That's the problem with Jira and friends, which is widespread in software tools: feature bloat.

The limitations of a physical card or a physical board are a feature. The point of a physical board is for everyone to get a summary at a glance. Detailed descriptions, etc. should be in documentation.

I believe the commenter is referring to the ability to add URLs and images to individual stories and tasks. If I’m doing frontend, I need mocks for major UI/UX changes.

This post is from 2015, and hasn’t aged well. The author doesn’t provide much evidence for why he hates Jira. People assuming Jira makes the team agile is a problem with those people, not the tool.

The default workflow is “good enough”. The times when folks have screwed up workflows were more a result of an overly-complicated workflow than the tool itself.

The recommendation to use a physical board doesn’t work for remote teams. My team of four is currently distributed in four separate locations. Paper won’t cut it.

Most of the complains seem to be from people preferring a physical medium for their Kanban board.

Well, I agree with them, but I work with a team from all around the world and we only get physically together every 3 months.

Although I am still not sold into all this Agile/Scrum philosophy, the fact remains that it made our remote work as a team actually manageable when before (using email/slack) it was simply not.

I was hoping for something more substantive as well.

To me, Jira is a jack of all trades, which means that it will usually be set up bad.

I did laugh out loud at "jiras": haven't heard that before, but I can easily imagine it taking hold :)

My suggestion:

- use Clubhouse.io.

- If you have no choice but to use Jira - use go-jira (Jira CLI tool).

You are a programmer, dealing with Jira is only a part of your job. Reduce the frustration, don't let it become your [main] job.

Reply on news.ycombinator.com