Hacker News Reader

Comment by GuB-42 | Hacker News Reader

Is Jira that bad? It sure is a mess, but that's because its requirement are a mess. It is not SAP but that's the idea, something that sits between developers, testers, management, customers, etc... People who want different things, speak different languages, and somehow need to work together.

If you just want an issue tracker, there are many options. Bugzilla, Mantis, GitHub, GitLab, Gitea,... Some of them customizable via plugins. Heck, you can even do it with Excel, I don't recommend it, but it gets the work done at many places. I mean, it is just a shared TODO list.

But then you want people to get notified by email, and the boss want a colorful dashboard with progress graphs, and QA wants a documented process, and developers want to attach tickets to their commits, project managers want time estimates, customers want to report bugs, sales want to send invoices, etc... That's how you get monsters like Jira, because the organization itself is a monster.

View on HN

Having used Jira for only a modest 12 years, I have had multiple stages of feelings about it. I agree with the parent that “everybody” hates Jira because “it’s too complicated” — yet when developers try to use a lean, simple tool like Pivotal or Trello, inevitably other stakeholders demand something better for business users, these simpler tools can’t deliver that, and the replacement ends up being Jira 99% of the time. I’ve started tech orgs on multiple issue trackers and this plays out every time.

Also, I hated Jira before learning a lot of its features and how to use them, getting frustrated that everything is not just a setting, but something meta where you need to adjust a “scheme” and understand how it works with the other data objects in the system. Eventually I learned it, just in time for Atlassian to put a lot of effort into a candy-coated, “simplified” set of defaults that hides 99% of the system’s power and abilities.

The main thing I actually don’t like about Jira is that: its insistence on setting up all new projects with infantile, Trello-like schemes, which then encourage sloppy setup when you start customizing unless you’re very seasoned with Jira. I think they should consider training an AI to “do what I mean” and help users to build out their setups —because transitioning from the “out of box experience” which I call “Expensive Trello” into a sophisticated workflow which actually models the business processes correctly and protects you against breaking your agreements, while making it easy to understand what to do next, is very difficult. In all but the biggest orgs, i don’t think it ever really happens.

>because “it’s too complicated”

I personally "hate" Jira because it's so dumb.

I open an epic, to see the stories that still need my attention, it shows all the stories, so I hit the "Hide done". Then I thoughtlessly click on one of the stories, I edit it, go back to the epic, and now it shows all the stories again. Rinse and repeat.

I open a screen, it loads slowly, when I think it's ready I click on whatever I wanted to click. Apparently, it wasn't quite ready, so by the time my mouse-click lands, I click the wrong thing, which brings me to a new screen, so I have to go back to where I came from. Rinse and repeat.

I open an epic, click the button to "Add a child issue", it prompts a "task", I want a "story", so I have to change the selection in the dropdown. Next time, it prompts again a "task". How many times did I mistakenly make a "task" where I had meant to make a "story"?!

There's this sort of silly (to me) things all over the place, which has often made me wonder: do these people use this software themselves, and if so, do they take any pride in it?

> which has often made me wonder: do these people use this software themselves, and if so, do they take any pride in it?

Agreed - Jira is functional but there are endless little annoyances like this. My usual problem is that I work across two project boards, and no matter what board you're on, the default project that Create Task picks is the last board that you created a ticket on, not the project for the current board that you're viewing.

Random idea, untested. Maybe it remembers client side? Then using two different browsers (or users in the same browser) could separate them.

This applies to many systems I've seen and my short summary of that is "the bigger the system the more it resembles CRUD scaffold, because they stop implementing specific user flows".

Luckily it's a nice space to contract in, making simpler dedicated interfaces to the heavy enterprise stuff.

They do use it: https://jira.atlassian.com/issues

As for being proud, with roughly 8k (?) employees I imagine you get the full spectrum.

I don't know what value non-developers are getting out of Jira, because I've been asked to produce reports out of Jira at different times and the only thing they ever want is "give me a list of all the X" or "graph the number Y across all the projects".

The one thing they all do is go in and mess with the issue workflows: they never improve the workflows, but they sure love adding states and restricted transitions and renaming them...and then promptly ignore all of it because it turns out your 3 layers of "review" transitions don't actually have any staff assigned to look at them, it's just all the same guy who either spends all his time updating the issue as he works on it or just hits the transition button 3 times when he's actually done with it.

Nailed it, the biggest issue imho is those state transitions. Why make a state that can’t transition to all others? It takes forever to tease out the intention behind it. State machines are notoriously difficult in code, why add them into something unnecessarily?

Hugely agree that if in practice it’s just an extra click by the same person that’s a bad pattern. And you see it a LOT. Hard to justify even using a bespoke workflow when it just adds “digital paperwork.”

OTOH Jira does support a way to force you to build a process you’ll honestly follow — there’s a validator that says the person who transitions from Y to Z must be a different person than from X to Y (or say, that it must be a member of a certain team). :)

As an EM I think it is my job to ensure as little paperwork as possible, so I monitor this to make sure workflows don’t waste people’s time, using automations, context-sensitive paths through the workflow, etc. for instance I have a transition that skips past ALL of the steps and doesn’t even need to prompt the user, for when an issue needs to be resolved as “working as intended.”

We got that from the last audit. They don't like it if everyone could set the state of some ticket and thus circumvent the required workflow. A lot of companies develop certified software and thus have the same requirement.

Ah that makes sense, we’ve got a process certification as well.

I agree with this sentiment completely. It's a "do everything for everyone" but "impossible to do anything" software.

Excel sheets ALWAYS is simpler to understand what's going on at a high level, but then devs want, then biz wants, etc etc and i just end up at the soup that which is jira.

It's annoying because there's a always a better individual tool (pivotal, trello for devs, excel, powerpoint for biz), but none of them inter-op and then you're stuck at jira which does it all but not very well. It really feels like salesforce, just an absolute mess but it can really do everything.

Bad management demands bad tools.

I used JIRA at, I think, every single company I've worked at and I never really liked it much...

But the company where I work at right now has a really well set-up JIRA board where most things that I need to do are easy to so and there are clearly defined workflows. Compared to the morasses of legacy code I have to wrestle with, I find JIRA now to be one of the least troubling aspects of my work day.

I'm sure it was super painful for the people who had to actually set up the current flows, but I guess that once you customise JIRA to your needs, it can work really well. The issue probably is that many companies don't want to bother setting up good, streamlined processes, or just don't know how.

Now, Confluence on the other hand... I have no excuses for it. I can't understand how a documentation tool can have a search feature that is unable to find what you're looking for basically every single time.

> I'm sure it was super painful for the people who had to actually set up the current flows, but I guess that once you customise JIRA to your needs, it can work really well. The issue probably is that many companies don't want to bother setting up good, streamlined processes, or just don't know how.

It’s actually not as bad as you’d think to set up. The reason Jira is so universally hated is because everyone uses it and very few people spend any time thinking about how it should work. In most companies it gets adopted by shadow IT, and is supported by whatever team member was most excited about it. But their competency isn’t Jira configuration, it’s widget support, so they spend the bare minimum amount of time setting it up using online tutorials and various blog/SO posts. They don’t follow any recommended best practices because they don’t know they exist. Eventually that person leaves/gets promoted or the system just becomes so widely adopted IT is forced to take over support. By this point though, the damage is done, the system is a mess of half baked badly implemented ideas. And there’s no budget/time to start from scratch. So it just limps along, being hated but no alternative being offered… until some VP discovers ServiceNow…

And then you have some poor suckers doing their damnedest to balance all the demands of all the middle managers who all want servicenow customizations on priority.

Truly just a horrifying situation to be subjected to.

I fight a lot about unnecessary customization, but the one place that I’ll never back down on is touching the priority/urgency matrix.

Do u happen to work where I work? Lol

I hope not. I'm trying to get out of that shit, and you don't want half of my workload if you're one of the leftovers

I don't know, I've seen that extreme, but I've also seen the other extreme.

People with vast knowledge of JIRA, obviously far more than anyone else in the org, developing vast dashboards and labeling systems. Every ticket has to be properly groomed and properly built (even if not useful).

That isn't always better.

Knowledge doesn’t equal expertise.

JIRA has a very simple initial onboarding story, especially in comparison to servicenow or SAP. But it’s got a lot of hidden complexity that can make it super powerful. That power can become its downfall if implemented badly. Vast dashboards and labeling systems is improper implementation.

True, and worse, this kind of approach sounds like expertise. I've found some people are amazingly good at selling continuously expanding complexity of management overhead.

The problem I see is that Jira encourages "management by looking at Jira" - effectively Jira becomes a second source of truth that is unconnected and unconstrained by the actual truth (the code). Jira acquires state that has to be carefully maintained as a separate operation by the developers to keep Jira's state in sync with the actual state of the project. Since most of the organisation are looking at Jira, the effective source of truth becomes Jira's current state, and the developers end up running to try and keep the actual project in sync with Jira. Or they become disconnected and Jira's state becomes completely independent of the actual project state (tickets being marked as "done" that aren't complete, or sometimes even started, because it doesn't matter because everyone is looking at Jira and not at the code).

I would love to see Jira state somehow derived from the state of the codebase. Tickets get marked complete when they are actually complete in the code, with tests and documentation and everything, because the ticket state is derived from the code state.

The code itself doesn't even contain much of the information relevant to coders, you'd have to also look at the git repo, its history, its commits, etc.

The code, or the repo, however are in most cases not the source of truth for a business roadmap, prioritisation discussions, estimation, customer feedback, bug reports, and so on.

It's a myopic view to only look at the code without any of its context and conclude that it's "the" source of truth.

Also, I don't know about you, but most places I've worked haven't struggled with keeping the code and JIRA in sync.

I've noticed it particularly with outsource teams where the communication is difficult. The team update tickets with what management expect, not what code has actually been written.

Code is not a source of truth, it is an attempt at partial realization of an incomplete understanding of a bunch of contradictory assumptions about what’s true at a particular point in time.

It's a source of truth about what code has been written.

I have used Jira at several place, and every time that it worked fine Jira was the source of thruth for the project. There was no shadow tracking beside it. So everybody updated it happily and used it.

You can't do that based of the code because the code is limited to its content. How do you track everything that isn't in it ? (requirements, relation with other teams, delivery to customer, customer tickets,...)

You can write glue for whatever hosts your repository to make api calls to Jira.

Say you have some code that needs some changes but at a later time, you can put a comment above it (or really anywhere)

// JIRA: MYPROJ-123

When the glue sees that comment disappear from the codebase, it can mark the ticket as done.

Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around.

The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.

What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.

Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.

Sure, but then you have to tag those tests with the ticket, and GP didn't want to have references to JIRA inserted in the code.

The other problem is that you still need to track when all the tests for the feature have been written.

yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting...

edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.

The code is the model.

The project management system is the view.

The model shouldn't have to change to accomodate the view.

> Is Jira that bad?

As someone who had to admin an on-prem installation of various Atlassian products, upgrades were always a nightmare: you could try multiple dry-runs to make sure data tables were updated, and plug-in upgrades were good, but invariably there would still be a good chance that something would still go wrong when you tried it with production.

The workflow we settled on was basically leave the old version alone, rsync over all the data to a completely new app and DB servers, and do the upgrades on the new systems. Any attempt at in-place upgrades was just asking for trouble.

Anyone who was prime on the software was very happy when The New Guy on the team arrived due to personnel churn and they got handed the baton for dealing with it.

Atlassian seems to be pushing hard to get everyone into their cloud. I’ve heard, but don’t recall details and have no direct knowledge, that the pricing for an on-premises install has gotten outrageous.

Perhaps that’s because they’re spending too much money on supporting companies who are struggling with upgrades.

They eliminated the server-tier licensing so now you have to go cloud or go datacenter, which is much more expensive.

I feel bad for the people that have to the Jira updates where I work - every time it happens it seems to take forever because it needs to "reindex", and they try and start it in the early evening but it still seems to bleed into business hours the next day.

My biggest issue with Jira (and Confluence) is that it is unbearably slow. At every company I've worked at, we've used Jira, and everytime, it is slow.

Jira sucks in the same way that email sucks - the platform is fine, the stuff people put in it sucks. you probably don't hate jira, you hate your boss, or their boss, or your colleagues, or your business's development practices or prioritization. or your developer's productivity levels, if you're looking at it from the management side.

but it's easier (and probably healthier) for jira to soak up that hatred. jira's good at that.

even a default jira is unusable just from a slowness perspective.

slowness, I can accept, but the extremely bad UX, byzantine inconsistency, some parts are SPA some are long forgotten wizards with useless and completely idiotic next-next-finish steps, some functions are so close to useful, but ultimately fall short because even though Jira can do anything it can't simply graph a fucking JQL result set over time, it simply doesn't have anything useful to report by default. Epics and subtasks and story points seems useful, sure, we picked it because it has the best scrum support, but there's no aggregation of points from subtasks to tasks. Oh, yes you can DIY with ducktape-and-hate using the new automation functionality, but it'll have the same bad UX of course, because it's not integrated, because it's Jira. It's hell. It's bad. It's ridiculous.

It's unfathomably tragicomic how the alternative offerings are also UX nightmares. PM tools are cursed, it seems.

i'm not really sure what your metric is here, or if you're talking about their on-prem version. but the jira hosted by atlassian seems like it runs at about the same speed as most websites. i'm not going to say it's blazing fast, but it's acceptable.

I mean I can't even use the one they host because I wait for things to load and spin.

I think one of the biggest problems with Jira is that it's taken the approach of so many other "Enterprise" products made by talentless teams: they just add all functionality into the app that anyone ever asks for.

The result is that for some of the companies I've worked for, each team's tickets have different but very similar "workflows" using custom state labels. In some projects when I go to close a ticket, it offers me approximately 30 different semantics which which to close the ticket. These include things like both "Done", and "Completed". What the fuck is the difference between "Done" and "Completed"? I do not know or care whether it is Jira that has populated this dropdown with such embarrassingly unintelligent crap or my company: if the latter then Jira should have neither encouraged nor even made it possible.

I've worked at a company that had Cancelled instead of Abandoned - so if you try and "cancel" a ticket you're given a model with two action buttons - Cancelled and Cancel: Cancelled cancels the ticket and Cancel cancels the modal.

You’ve hit my Jira pet peeve, kinda - accepting the default of naming the transition the exact same as the state it goes to.

Transitions should be verbs. States should be adjectives.

So your transition should have been called “Cancel” so your modal would have had 2 cancel buttons :D

(Or yes, another term should have been picked!)

Yes Cancel and Cancel would have made no sense, and I think that should have told someone that Cancelled is an awful state name.

It’s “death by a thousand cuts” for me. On planning meetings I usually take notes on a notepad and transfer that to Jira after the meeting, because interacting with Jira directly (plus the swearing) would make the meeting take double the time.

> Is Jira that bad?

Jira itself is fine. It is very powerful, and with that power, it can be setup "wrong". That all stems from opinionation. On itself it's an empty box, right?

> Is Jira that bad?

As the saying goes, Jira is fine, the only problem is that it is Turing-complete.

It's pretty bad. The actual interface has improved a lot over the last 5 years, but it's still very unintuitive and has weird limitations. For instance you can't have proper hierarchical tasks. In Phabricator you can just give tasks a parent task and it will display the whole hierarchy. Very useful. In Jira, a task can be a child of an Epic... and that's it. You can have "subtasks" but they aren't really full tasks so you get 2 or 3 levels of hierarchy max.

Another example: tasks can't be part of more than one project. Have a task that affects multiple projects? Tough. Pick one.

The backlog doesn't update immediately when you edit tasks on it. You have to refresh.

But a big part of the problem with Jira is that it is highly configurable and you always end up with project managers massively overcomplicating things. You get dozens of issue types, dozens of statuses, weird automation rules etc.

It's not awful, it's just surprisingly bad at its core task.

It's really not bad. It's gotten much simpler and faster in the past 5-ish years. If you take the time to learn it, it does pretty much everything you want, and there's always the API, extensions, automations, etc.

But it's an opinionated tool. Almost every person I have ever worked with has never read the docs, so they just sort of suffer and complain and never learn that they're using it wrong. I'm the guy on every job that has to teach the team how to use Confluence and Jira correctly. My biggest challenge in making Jira work well is convincing coworkers to stop using it wrong. (They'd rather come on HN and complain about it than read the docs or take a Udemy course)

All this is compounded by people who don't even know how to do Scrum or Kanban or even basic project management, so their complaints are also often just people who don't know how to work. Which, again, is most people I have worked with.

Linear and Height are not monsters but they do all those things, if I not mistaken.

Having used linear (we switched to Jira) I have to say its near-complete lack of automations, and no REST api, only GraphQL (and not a complete or reliable one at that)… did not impress me.

There is a big feature gap. And also Linear is even more opinionated, and seems to exist mainly to get you to follow their pet process.

Jira was acceptable when it was easy to run and cheap ($10/year for 10 developers).

My problem is that it’s expensive. $100/year/user for cloud and minimum $40k for “data center” hosting.

Also, it’s java based so updated are kind of a pain with ears and jars and wars and manually application. And there have been a few zero days and data loss.

At this price, I want something else. I don’t think issue tracking is a “big deal” but Jira is making it a big deal because of its price and security.

I’m trying to get by with gitlab and GitHub issues.

To me personally, Jira was the best tool I've used so far (used a few of them, but not very many).

But I still was not too happy with it back when I used it - main reasons being extremely slow load times (we had the cloud version, not self-hosted) - and lots of annoying inconsistencies, like "create issue" using a completely different editor than "edit issue", etc.

jira-1369 is a 20 year old bug of email notifications not being put into a digest and instead flooding users.

I for one feel like I grew up those people and we should share our wedding and other milestone photos and announcements on that chain.

Even though I’ve come to like Jira there are a few of these 15-20 year bugs that are just frustrating beyond belief. And a Jira PM will duck in there every 8 years or so to say they’re not considering it and then run away. Mine is how it’ll let you create infinite case variations of Labels, even though Labels are case-insensitive when querying, but it means the accidental variations people will make crap up the autocomplete forever.

Or the fact that Components or Versions can’t exist across multiple Projects. Thankfully we did basically automate Version management using their Automations to basically fake it. Thankfully Versions in JQL are searched by string instead of being instantly converted to ID like Sprints are.

Part of me feels like writing a new interface of what I need to Jira using their API to get things how they're needed while maintaining some meaningful compatibility.

Then I remind myself I'm not the only person to ever think that.

What amazes me is the number of times JIRA has landed at a clients while we are working with them (from us introducing them). It is excitedly rolled out to hundreds of employees on a project eam after they see what it can do with modifications for their workflow.

Every single deployment has eventually been shut down because Confluence can't digest updates every 5-10 minutes, nor can Jira.

A plugin isn't realistic in some cases, so some other ways was found around it.

I think Jira is fine and it’s ok tool. Nowadays the performance of the cloud version also has been good.

BUT it is absolutely possible to configure Jira to be horrible to use. Add lot’s of extra fields, force complex workflows etc.

It all comes down to managers and PMs. or wanting to do their job of communicating status to stakeholders so they try to automate it with the monstrosities.

Reply on news.ycombinator.com