Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

Post reply on HN
Print view View original

451–460 of 530 posts

Re: Why Jira Sucks

#451

Post by icanhackit »

SideburnsOfDoom wrote: post #84

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…

> It encourages micro-management. It encourages more and more process.

I think it's a case of there being multiple truths, and depending where you sit on the food chain you'll sing one and not the others:

1. If you're a highly competent dev it gets in the way and wastes valuable time

2. If you're a project manager with thousands of moving parts and a diverse array of talent from almost useless to God-tier it can help keep things on track

3. If you're a rookie you can at least quantify and digest which tasks require your attention and not feel overwhelmed

4. By virtue of some common personality flaws you over-estimate how good you are, underestimate what you need to do, and work on the wrong task and still say it's a pile of shit despite it being exactly what you need

Re: Why Jira Sucks

#452

Post by gizmo686 »

dbbk wrote: post #443
Karunamon wrote: post #221

Earlier quoted context omitted.

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible. When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning…

At the network? How would that work with people working remotely?

VPNs

Re: Why Jira Sucks

#453

Post by nikau »

Lazare wrote: 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…

> there's one huge one: It's slow. Really, really slow

This is spot on.

Its the same reason I hate Sharepoint - every implementation I've used was always incredibly slow, so I would only ever use it when my arm was forced.

I miss old school "legacy" style apps that cached stuff so moving around the app is quick.

Even simple apps like slack suck these days as it always takes a few seconds to move around windows, why the hell can't it cache things? IRC clients in the 90s did about the same amount of stuff and they never lagged swapping servers or channels.

Re: Why Jira Sucks

#454

Post by nikau »

bdavis__ wrote: post #226
eplanit wrote: post #126

Earlier quoted context omitted.

It's the mainframe app of our time.

nah. mainframe apps are very snappy with that text only interface.

Damn right, I still miss Infoman for change management, you could just type ahead with command line interface to do everything if it was under load.

Now everyone uses service now with 50 unnecessary subtickets and multi second delays moving around the web interface.

Re: Why Jira Sucks

#455

Post by mgkimsal »

nicoburns wrote: post #416
anonymousCar wrote: post #261

Earlier quoted context omitted.

I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.

Typing in the description field of a ticket lags and spins up the fans on my laptop. It's doing something wrong.

Unrelated, but... we've got a jira input field that keeps moving the cursor to the end of the input field on each keypress. Perhaps that all do that(?), but it's noticeable when I'm pasting in a URL and want to change the beginning part of the URL.

Example: server-abc.example.com, need to change to server-def.example.com - changing the A then moves the cursor to after the .com, which is also beyond the end of the input box, and thus invisible.

Re: Why Jira Sucks

#456

Post by mgkimsal »

echelon wrote: post #17
_y5hn wrote: post #7

Earlier quoted context omitted.

The interface used to be simpler and less in the way of getting things done. Then they added personas, UX and tried to "help" the user. You now need more clicks to accomplish the same stuff while information is more hidden than before also. There's no way to cater every possible workflow without feature bloat. However, the space is ripe for simpler, more accessible solutions that supports work across multiple project…

It's not for engineers. Or anyone in particular. They're building to check off boxes in order to sell top down to C-level execs that never touch the stuff. Atlassian products are all like this, and each one is a horrible trash fire. Confluence is the worst wiki product I've ever used. Gross syntax, slow, clunky plugin system, awkward permissions. Install MediaWiki and be done with it. Bitbucket is slow and feels like…

> Confluence is the worst wiki product I've ever used.

BUT... the direct integration with the ticket system - highlight a list, and make linked tickets (which keep the status info 'live' in the confluence doc) is pretty powerful, and allows a lot of people to keep their business docs, and get status updates without ever having to learn other parts of the system.

Re: Why Jira Sucks

#457

Post by caspar »

jiggawatts wrote: post #440
Karunamon wrote: post #221

Earlier quoted context omitted.

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible. When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning…

It is a fundamentally poor design for permission checks to require additional network round-trips. A user's group memberships need only be evaluated once when they log on, with a refresh every few minutes at most. Access control lists can be easily cached, and then most access checks can be performed entirely in-memory. Instead of evaluating the full ACL every time, an additional trick is to take the cryptographic ha…

About 6 years ago I maintained the LDAP integration code for Atlassian Crowd, which is/was reused by Jira (& Confluence).

Jira (both Cloud and Server) does cache permissions, heavily. Jira effectively has a local cache of user and group relationships for all users who have access to a given blah.atlassian.net Jira, and caches lookup results in a shared cache too. It's complicated by having well over a hundred thousand active Jira sites spread over several hundred stateless servers, which does make effective caching a bit trickier.

AFAICT Jira Cloud's slow feel currently stems largely from the front-end, amplified by the debacle that is modern front-end engineering. It's tricky to get 300+ engineers to ship fixes and enhancements in a multi-million line codebase over 15 years old on a good day. Feature creep in design systems, constant ecosystem churn, and poor build tools all conspire to make it that much harder to prevent performance regressing.

But even knowing all that - yeah, I wish that Jira's performance was 5x better too :)

Disclaimer: am still employed by Atlassian but all views are my own, things may have changed a bit since I haven't touched any Jira code in ages, etc.

Re: Why Jira Sucks

#458

Post by Karunamon »

dbbk wrote: post #443
Karunamon wrote: post #221

Earlier quoted context omitted.

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible. When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning…

At the network? How would that work with people working remotely?

You can still grant login permissions, but anything beyond that is just asking for it.

Re: Why Jira Sucks

#459

Post by tootie »

gurkendoktor wrote: post #238
tootie wrote: 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 find it kinda odd that people's complaints about JIRA seem to all center on meetings and people. JIRA is absolutely not easy to configure. It's a pro suite of tools that requires investment in setup. What it allows is total flexibility within a set of paradigms to meet any orgs preferred workflow. Other tools that are simpler are all too simplistic.

Re: Why Jira Sucks

#460

Post by tootie »

wpietri wrote: post #308
tootie wrote: 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…

You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices. If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, ev…

That's not what I mean at all. JIRA doesn't imply any sort of top down approach. In fact, I'd argue it's the best tool for those tight feedback loops. Each ticket is a versioned history of the decisions, feedback and work history of a single task. Startups can get away without tools because they can communicate very tightly. That doesn't scale much past an org of even 20 people. Not everyone can talk directly to the CEO or the budget makers, nor are they all sufficiently cognizant of the business constraints to make the right calls on prioritization. There isn't a tier of professional managers as much there's a tier of experts in their discipleship who have visibility across multiple teams and into the business decision making. People who need to allocate budgets and resources without attending every scrum or sprint planning.
Post reply on HN