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

461–470 of 530 posts

Re: Why Jira Sucks

#461

Post by redisman »

Terretta wrote: post #176
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…

Have you read David Allen’s Getting Things Done and looked at that system? You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward. Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING. These core mechanics work . Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown str…

I’ve been thinking for a while that the ideal developer view would be just a 1 dimensional queue. You have 1 ticket at slot 0 that you work on and if someone wants you to work on something urgent out of order they’ll insert it at slot 1, otherwise you just keep popping off the queue. Managers and scrum priests could add more complexity to the metadata and the ordering as much as they want but the developer view would stay the same

Re: Why Jira Sucks

#462

Post by jariel »

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…

'JIRA thinking' is good for bug fixing and resulting issue tracking.

It's maybe not so good at the front end of the process.

Re: Why Jira Sucks

#463

Post by redisman »

_5yoy wrote: post #270
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…

Every single job I've worked that used Jira, also used google sheets to "map" actual work to Jira work. It has always blown my mind. All the meetings to update the google sheet, and then to update Jira, and then to ask why the two aren't in sync. It feels like I'm taking crazy pills. Why are we using a manual tool (google sheet) to keep track of the work, that's in our work tracking technology? What?

Because there’s so much friction to do anything in Jira. It’s horrible for any kind of planning or really anything that’s not set in stone. I just keep a text editor with my current and next tasks and then update jira at the end of day based on it.

Re: Why Jira Sucks

#464

Post by redisman »

nikau wrote: post #453
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 t…

I would guess because in slack the history can change when irc is basically a read only log. Slack has threads, edits, deletes and emojis etc. that will change the history so you can’t cache it

Re: Why Jira Sucks

#465

Post by BigJono »

namdnay wrote: post #386
ajkjk wrote: post #289

Earlier quoted context omitted.

I disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't kno…

> A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. My heart wants to agree, and I think that up to a certain level for internal projects…

That's not the idea. There's a shitload of middle ground between breaking everything down into daily tasks and daily meetings; and disappearing for 3 years until you emerge with a completed product.

Re: Why Jira Sucks

#466

Post by ncann »

ajkjk wrote: post #389
ryandrake wrote: post #378

Earlier quoted context omitted.

> The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up. Let's take two projects. Project A is estimat…

The first approach relies on a lead and a team that actually has the ability to do this style of development. No doubt it would not work with lots of teams in practice, but I think it would work for a lot if they were ever given the option. Of course the way to do it is not to completely let the team go untethered with monthly checkins. You can still monitor progress, at the tech-lead level. But micromanaging the tea…

I couldn't agree more. The second approach is definitely more likely to make the deadline. At the same time, it will often result in disgruntled people who just do the minimum possible to ship. The extra meetings and overhead result in less time for actual dev work, and people will be hesitant to make any improvement they deem would be nice to have, no matter how small, because of all the processes it has to go through.

Re: Why Jira Sucks

#467

Post by jiggawatts »

caspar wrote: post #457
jiggawatts wrote: post #440

Earlier quoted context omitted.

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 thousan…

The permission performance issue I was commenting on (apparently) resides in the back-end code of the on-premises Jira server.

The front-end code issues other people have raised seem like the type that could be solved by simply turning on Gzip or Brotli compression for static JavaScript content in the web server.

All of this seems to be incredibly basic tuning to have been overlooked, especially given that every public discussion of Jira mentions its slow performance!

As for the Jira Cloud: I just did some quick experimentation. I spun up a free-tier account and created an empty issue. This is the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, high-performance client link, same region as the Atlassian PaaS server, etc...

At least here, most of the traffic is coming from a CDN that enables compression, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of.

Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form!

This required 1.2MB of uncacheable content to be transferred.

With the cache off, a total of 27.5 MB across 151 files taking 33 seconds is required!

The total text displayed on the screen is less than 1 KB.

The page took 4.35 seconds of CPU time on a gaming desktop PC with a 3.80 GHz CPU and a gigabit fibre Internet connection.

A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds!

Is no one responsible for performance at Atlassian?

Re: Why Jira Sucks

#468

Post by kalyantm »

Does anyone else think that Airtable is headed down the same path? Hot mess in terms of trying to do a lot, and never being able to find out what i actually need?

Re: Why Jira Sucks

#469

Post by bendauphinee »

jvvlimme wrote: post #359
ypeterholmes wrote: post #349

Earlier quoted context omitted.

Redmine is great.

No, it’s not. From a Product Owner point of view, it’s a piece of shit. Hard to set priorities, hard to follow progress. I’ll take jira any day.

From a dev perspective, I see your point. Redmine was great for the reason that we documented a lot better inside tickets because it was lower friction.

Re: Why Jira Sucks

#470

Post by nikau »

redisman wrote: post #464
nikau wrote: post #453

Earlier quoted context omitted.

> 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 t…

I would guess because in slack the history can change when irc is basically a read only log. Slack has threads, edits, deletes and emojis etc. that will change the history so you can’t cache it

I would prefer slack to update the channels in the background rather than on demand when I click a channel to view.

This would probably be a bit more resource intensive, but I have network and CPU bandwidth to spare.

Post reply on HN