Why Jira Sucks

Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?

https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_s...

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 eyeball the ticket.

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.

The other approach is to have developers build up a real sense of why they are building what they’re building, who they are building it for, and give them the agency to change the how and what to better meet that why. This requires trust, so it is more easily done in organizations that are on a first name basis. It may involve jira, but really almost any work tracking solution will work.

As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based around short-term thinking.

First, it provides multiple negotiations for every work stream: "What tickets are part of this project?" and inevitably "what tickets do we need to cut to get this project out the door faster?" The developer quality of life tickets are the easiest for non-engineers to jettison. What's worse, sometimes they're right to want to get rid of those tickets. Quite honestly, developers often don't do the math on "Will we ever get the time back we spend fixing this?"

Second, JIRA-based systems are designed to try to make everything take the minimum possible time. This is a good thing, but developers can bear the burden of it. Quick iteration is good, but it turns into a situation where the most you can undershoot a task is by hours or a few days, but if something is much harder than you expect, it could overrun by weeks. I think this is a necessarily reality of business, and that "evidence-based scheduling" a-la Joel Spolsky is an innovation that could have eased this pain by introducing "how bad are long-tail effects?" into project planning. But as-is, you're in a situation where you're either meeting expectations (since the ticket took more-or-less what people thought), or you're visibly holding a project back (because it was tightly scheduled to within an inch of its life). So the development experience becomes this weird commodity that sometimes has really visible failure modes.

And finally, since JIRA projects/epics/whatever are often prioritized by expected value, it's difficult to raise large engineering concerns. Again, this is a good thing, because time spent engineering is time not spent helping the customer. But because the focus of JIRA is so granular, it's difficult to break out of that. Imagine a company in the 80s that wrote desktop software in assembly, and some engineer is like, "This is crazy, we should invest the time to write modules in C". How do you climb out of that? In the language of agile development, you actually need a lot of foresight to break out of this local maxima, because your prototype will be demonstrably worse - "so we need to set up this compiler toolchain everywhere, and interface with our existing assembly code, which the compiler toolchain doesn't make easy, and it introduces ABI concerns, and your prototype looks worse than just going with this. I think we can safely call this a failed experiment." When the only project language you have is trees, it's difficult to talk about forest. I think this is why healthy engineering organizations that I've worked for tend to spend about 30% of their time working on more ambitious stuff. But it's something that needs to come from the top-down, because the tools won't provide it.

So to developers, the structure imposes a system where successes are minor, failures are visible, it's hard to get negotiation leverage, you lose the forest for the trees, and they need to fight tooth-and-nail for quality of life improvements (or they get a week thrown down from above, as a treat, to address any technical debt).

Agree with most of what you say aside from this bit. I find most similar systems are in the same ballpark in terms of being able to track what I care about.

Mainly:

- Is the ticket ready for me to work on? (Do I have the designs I need to work it?)

- Who is working on a given ticket right now?

- Am I done with a ticket?

- Is the ticket ready for QA?

- Did QA reject the ticket and I need to fix something on the ticket?

Pivotal does these things fairly well. There is also the obligatory pointing system, but the above is the bulk of what I care about. Pivotal also lets me create queries so I can zero in on the work which I'm doing as opposed to the entire project.

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 technical details, I probably spam the whole team with lots of "Ticket was edited" notifications because there is no logic to Atlassian's markup systems.

I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true.

</rant>

And as someone who enjoys documenting their own work for fellow developers and other roles, I don't even think Jira helps. Most discussions will still happen offline and without documentation, especially from non-technical roles who hate typing.

I know most of the people in these positions aren't _actually_ stupid, and would agree if you were able to explain to them why some specific thing is completely irrelevant, or even detrimental, to your team. At the end of the day, though, at big orgs no one cares. They'll waste as much time and effort as necessary in order to look good on metrics. Even if the metrics are worthless.

How does JIRA help with that?

I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA.

My $100 bet: They don't.

While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.

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. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort.

More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables.

Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.

So much for Agile!

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, everybody here knows that's not true.

I think the true way to optimal resource usage is not through ever-increasing process and managerial layering. Instead, it's through tight feedback loops where small cross-functional teams iterate closely with the people they're serving. Which is exactly how most good startups work. If you were really right about pursuing a financial optimum, the first thing (very resource-constrained) startups would do is get a copy of JIRA and hire some middle managers to carefully parcel out the work against precisely designed specs and timelines. That they don't should tell you something.

[1] https://en.wikipedia.org/wiki/Managerialism, and also see https://www.amazon.com/dp/B00A76WZ96/

He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done.

It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard.

After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes.

It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams.

This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on.

This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.

Anything is better than Jira including post it notes on a wall.

It's for developers too.

As a developer I want to know what the history of work on a certain issue was, who requested it and who worked on it in the past (not just at the code level, the information for which should be in version control logs, but also at non-code levels like approval, review, etc), what the communication was with other stakeholders, etc.

Much of this information is useful to me to figure out who to talk to if I have some questions which the documentation or sourcecode does not answer, and also how to communicate how/what was done on this issue.

This is the strength of a ticket tracking system, and that strength helps everyone.

This is patently false, as evidenced by every business in existence that doesn't use issue trackers, including most non-tech divisions of current businesses and most tech businesses until the rise of agile. And I question the value add of these things; my current company was built without them, and it's only as we've matured (well after the product was built and mostly refined) that issue tracking was used.

Yeah. The problem is they now have to report at least 50% less progress because half of s dev’s mental power is dedicated to ignoring or updating Jira.

Hard disagree. Unless you're writing software for clients a crapton of ceremony goes into JIRA tickets when 99.9% of them will never be looked at again once marked closed.

>>> If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money.

JIRA is used when companies have no trust in their devs. We all use Git. There's a perfect, permanent record of anything I ever touch. Yet management is always worried we're going to "get distracted". As if that wouldn't be incredibly obvious.

It's like hiring a plumber to fix something then following them around the house to make sure they don't straighten your artwork or do the dishes while they're at at.

There's a pervasive theme that "PM knows best" among companies obsessed with JIRA. The best companies I worked at had no project managers at all and things ran great.

Jira / Kanban works for some projects while Waterfall works for others. Some projects need high levels of governance while others move faster with low levels of governance. Some projects can get away without time-commitments, but others have dependencies and must hit deadlines, and this must be tracked.

And just because GTD is great for managing my personal workload, doesn't mean that it's great at coordinating the work of 100 people.

(I say this as a person that generally believes in Agile, is a huge proponent of GTD, and have also been on a dev team where Agile and Kanban was applied where traditional Prince2 would have been a better fit).

> Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an addiction. “On more than a few days, I wondered what, precisely, I was trying to accomplish,” he wrote. [...] It seemed to him that it was possible to implement many G.T.D.-inflected life hacks without feeling “more competent, stable, and alive.”

[1] https://www.newyorker.com/tech/annals-of-technology/the-rise... (or https://beta.trimread.com/articles/59839)

Stuff you might or might not complete is basically, everything. That's not a meaningful category list.

> These core mechanics work.

They work like a water-filled car coasting downhill. It looks like it's water-powered (or JIRA-powered) but it's just the gravity well of "looking busy" for the most part.

Maybe the in-car water fountain could be considered water-powered in practice, but that's a derail. Management gets approximations from JIRA because that's what they want, but JIRA doesn't provide it. A tool with a dependency graph could do much better.

With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket.

I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself!

8 person teams are usually the recommended max team size anyway under Agile (two pizza team).

I've seen many examples of both extremes:

Sometimes I see people working totally unsupervised, essentially just playing and tinkering with whatever random technology seems interesting to them that day. This can be a huge waste of the company's money. Surprisingly often these people are counter-intuitively very productive despite the apparent time wasting. If you take away the 20% management overheads, someone being unproductive 20% or even 40% of the time is either the same or only slightly less productive overall!

On the other hand, the bureaucratic hells of 80%-90% overheads are all too common. These are the organisations where managers would say with a straight face that the floggings will continue until morale improves. These places can be so soul crushing that all of the talented staff leave for better jobs, which is not only a brain drain but also leaves the worst employees behind. Eventually management redoubles their oversight to try and squeeze some productivity out of the remaining dregs, but this just results in even the mediocre staff jumping ship, leaving only the most unskilled, unmotivated, and unproductive staff remaining. Jira often becomes one of the whips used in places like this to flog the remaining unfortunates.

TL;DR: Some management is required but the extremes are bad, and the extreme of too much management is much worse.

That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.

Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself.

Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".

Unpleasant?

deleterious fits in an alliterative way

See also my comment from 2018: https://news.ycombinator.com/item?id=18511497

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 hash of the ACL and use that as a cache key. This both deduplicates the ACLs (which tend to be repetitive), and also allows (ACL,UserId) tuples to be efficiently cached.

This way, a page with even a hundred controls becomes effectively a hundred hashtable lookups the second time it is viewed, and even the first time it is opened the overhead is no more than a millisecond.

If turning off security makes a noticeable difference like you said, Atlassian has done none of these basic things. It indicates to me an incredible level of negligence.

These tools market themselves as creating transparency but they are in practice often used to hide or excuse things.

I suppose that is why they all take the tragic path from being heralded as new and fresh in the beginning to absolutely being hated in the end.

Goes for methodologies as well (I remember the agile manifesto ... look at where we are now).

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 it's from the 90s. It doesn't seem to do multithreading well - sometimes force pushed branch rebases pick up a new, unrelated author. A bug that hasn't been fixed in years, and only one of many. How many times will merging not actually work?

Jira is a special kind of hell. It's like every team needs their own embedded Atlassian solutions engineer to get it into a usable state. Not an EM or PM, but a specially dedicated role just to deal with Jira nonsense. Why even bother?

Atlassian is like Salesforce for business process, but if it were written by all-remote temp contractors churning through Jira tickets themselves.

[0]: https://linear.app/

I think there are multiple clones of JIRA that literally just focus on the performance part. I think at this point it's unrealistic to expect major performance improvements in a timely fashion with JIRA.

Firefox 84 on Kubuntu Linux, no relevant addons.

[0]: https://github.com/go-jira/jira

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

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

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.

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

1) Ignore the burndown chart / any other reports. Everything is fine on the business side, so let's just accept that the reports are broken and not spend time trying to fix them.

2) Have everyone invest more time into using the system (usually on an ongoing basis), so that it produces the correct looking down-and-to-the-right chart.

The problem is that with #1, the software is arguably not producing much value, if any. The problem with #2 is that you're spending extra energy and effort to make the software happy, even though outside of the software it seems like your team is working well, shipping features and keeping customers happy - all of which are more important than a pretty graph.

Jira doesn't use Spring--you may be confusing it with Confluence which does.

Jira and the other behemoths tend to come with a lot of process/formality. Tends to be borderline waterfall.

The lighter-weight tools tend to be used by teams that actually run an Agile process.

I imagine you do as well! If you were looking for a job and they were programming in VB 6 and using CVS for version control I would imagine you (or almost everyone if not you) would say 'hmmm I'm not sure that's how I want to spend my day'.

I know I don't want to spend my precious hours on Earth trying to remember which markup syntax this particular input box uses in Jira today.

It makes a huge difference in my happiness if I'm fighting with procedures and tools all day, or fighting with user impacting problems all day.

I imagine this is true for people who don't share my process and tool preferences, too.

When you say “need the features”, that immediately makes me think “which features?” because it reads as if you are referring to some previously mentioned features.

As an additional side note, Jira updates are NOT free. You have to pay for a license fee every year to get the updates + support, but the product unfortunately remains kind of the same: super slow and with missing basic features (e.g: Markdown)

Fun fact, next-gen might actually be a reason why your instance is running slower. A side-effect of NG can be the slowdown from each project with its own custom fields and that effect multiplied hundreds of NG projects across an organization. Then (I think), when loading your project it calls all the fields to see which fields it should show. Not an ideal rec, but I'd check out Classic projects and see if that speeds things up for you and your org.

Speeding up Jira Cloud is a top priority for Atlassian this year so you should see some improvements coming. I'm working on a new view right now in Jira and we've been able to load about 100 issues in ~1-2 seconds. It lazy loads, but we can flip through 500 easily once you've scrolled to the bottom. Should be able to get that in your hands this coming year.

You also have to pay to even comment on issues. I think that's a pretty great way of getting companies to pay for support but it's also annoying if you want to work with other freeloaders on issues.

Also it's written in PHP which means you aren't ever going to want to read or modify the code. No different to GitHub, or probably even GitLab but I can definitely imagine modifying Gogs/Gitea.

I wholeheartedly agree with your suggestions. Trello won't scale, but it's good for n < 3 users, especially if working with non-engineers / non-PMs.

On android, returning from a screen unlock deleted all my unsaved text.

or

https://trac.edgewall.org/

- YouTrack: https://www.jetbrains.com/youtrack/