6 ms·

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

• xp84 3y ago
  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.
  • XorNot 3y ago
    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.
    • Aurelius108 3y ago
      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?
      • xp84 3y ago
        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.”
      • flicaflow 3y ago
        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.
• throw0101b 3y ago
  > 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.
  • macintux 3y ago
    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.
    • bombcar 3y ago
      They eliminated the server-tier licensing so now you have to go cloud or go datacenter, which is much more expensive.
  • jamesfinlayson 3y ago
    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.
• esafak 3y ago
  Linear and Height are not monsters but they do all those things, if I not mistaken.
  • xp84 3y ago
    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.
• MuffinFlavored 3y ago
  > 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?
• toastercat 3y ago
  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.
• onionisafruit 3y ago
  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.
• EuAndreh 3y ago
  > Is Jira that bad? As the saying goes, Jira is fine, the only problem is that it is Turing-complete.
• marcus_holmes 3y ago
  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.
  • justahuman74 3y ago
    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.
    • marcus_holmes 3y ago
      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.
      • Tainnor 3y ago
• notatoad 3y ago
  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.
  • pigeons 3y ago
    even a default jira is unusable just from a slowness perspective.
    • notatoad 3y ago
      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.
      • pigeons 3y ago
        I mean I can't even use the one they host because I wait for things to load and spin.
        • deleted 3y ago
          [deleted]
    • pas 3y ago
      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.
• throwawaaarrgh 3y ago
  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.
• da39a3ee 3y ago
  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.
  • jamesfinlayson 3y ago
    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.
    • xp84 3y ago
      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!)
      • jamesfinlayson 3y ago
        Yes Cancel and Cancel would have made no sense, and I think that should have told someone that Cancelled is an awful state name.
• Tainnor 3y ago
  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.
  • vxNsr 3y ago
    > 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…
    • _ea1k 3y ago
      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.
• j45 3y ago
  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.
  • xp84 3y ago
    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.
    • j45 3y ago
      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.
• hooby 3y ago
  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.
• IshKebab 3y ago
  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.
• otikik 3y ago
  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.
• jpalomaki 3y ago
  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.
• prepend 3y ago
  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.