5 ms·

I can't believe Jira is so popular, I've had to use it for 3 years and it's - to put it mildly - bad. Ok, actually it's a pile of shit. It's hard to count how m

I can't believe Jira is so popular, I've had to use it for 3 years and it's - to put it mildly - bad. Ok, actually it's a pile of shit. It's hard to count how many times we had problems with it on meetings, the UX is absolutely horrendous - I felt like Jira was always in the state of war with you, trying to make your day worse. Common tasks that should be easy to do were overly complicated and required too many actions, trying to find an issue was a chore, on every page a lot of shit you don't need - generally one big mess. I don't know about their other software, maybe it's better, but Jira being the most popular, their success baffles me.

adrianN 11y ago
Have you tried the competition? They all seem to be pretty bad.
- deleted 11y ago
  [deleted]
- daveguy 11y ago
  What would make for a good one?
Rexxar 11y ago
I'm not sure if Jira is inherently bad or if Jira is destroyed by project managers that force developers to use it as a reporting/management tool and not as a bug-tracking tool.
- mgkimsal 11y ago
  I'm diving in to a new project right now - third one with Jira/Confluence, and working with a freelance PM on it. The one issue she's got with it is trying to generate "good reports" with it for the 'biz folks' on the project. :) That said, we're still going with it, partially because the other tools we've tried all... don't work together very well. Documenting things in Confluence and tying tickets to those documents directly does wonders for bridging the gap between tech/dev and the other parts of a project that think in English. There are no doubt better 'bug trackers' out there, and there are no doubt better 'document collaboration' tools, and better 'planning' tools, but I've not found any that play nice together. Open to suggestions...
- oneJob 11y ago
  My experience also suggests that this is the real issue. Someone has to make a decision on which solution to use for their "agile" development workflow, but this someone doesn't understand that they are actually purchasing a product with a constrained, predefined version of agile. Even though it is somewhat flexible it doesn't perfectly map onto this person's version of agile and so, since they've already paid the licensing fees and gone through the office politics of getting buy in or stuffing it down the users throats, they don't want to admit that either their version of agile could be tweaked or that they should have licensed different software. So then, the mess begins. At every turn square pegs are forced into round holes and workflows are misused with consequences that are not immediately evident. A year down the road and everyone is frustrated. You'd be better off using an excel workbook. Now you have to explain to everyone you onboard why your version of agile is so much better than other versions and warranted creating this monstrosity which they must figure out how to use without documentation (which is useless at this point) and without frustrating their new coworkers with too many questions about the arbitrary nature of their system, which they hate and had shoved down their throats.
trhway 11y ago
>their success baffles me what you described is a typical enterprise software which naturally leads to its maker being a solid tech performer. Enterprises like enterprise software. In my experience, in addition to all what you mentioned, the Jira was also slow as hell on our pretty large deployment. Like an icing on the cake, it made it very enterprise-y and natural in our BigCo environment. Mid management and their suckers loved it during those couple years of Black Death... err... Agile Lean Scrum pandemic.
- yawgmoth 11y ago
  You obviously wouldn't think that poor performance and usability was an indicator of a reasonable tool for a job - no one would. Perhaps the people with which you worked were simply making bad decisions? > those couple years of Black Death... err... Agile Lean Scrum pandemic. What's wrong with SCRUM?
  - pc86 11y ago
    Nothing, but let's not let that get in the way of the anti-enterprise HN circlejerk.
NikolaeVarius 11y ago
I don't know about you, but after I learned how to really use it, I actually like it. Did you ever dive into all the cool stuff you can do?
- oneJob 11y ago
  Agreed. If you don't make it your business to create the perfect workflow software for your coworkers, and instead learn to use it as designed, it may not be perfect, but it works well and has some really nice features. It certainly works well enough, when used as designed and only using the pieces you need instead of trying to find uses for stuff that you can do without and which will only complicate your work, and is a good tool that can let you get back to your work.
yawgmoth 11y ago
You can customize what's on any given view in a project. You can also use any number of plugins for Agile, such as Grasshopper. It integrates nicely with various source control technologies to keep track of work items and tickets/stories, being able to plug sprints into cards on Confluence (say describing long-term goals or release requirements) is convenient. There are certainly reasons for its success, despite the recent surfacing of anti-enterprise sentiment on HN.
FLUX-YOU 11y ago
I don't see how the UX was bad from a developer point of view. I mostly just created/assigned tickets around though.
gregmac 11y ago
I have the opposite experience. First of all, like any system, the data for search is as good as the data entered: if the users put in garbage, you'll have trouble finding things. If your users are very good about making proper titles, using appropriate labels, etc, and most importantly, fixing up (other people's) badly-entered issues when they come across them, you won't have this trouble. In fact, JQL is freaking awesome. It's really like using SQL for finding tickets. For a mildly complex example, here's the JQL I use for viewing active customer-reported bugs: type = Bug AND ("Related Support Tickets" is not EMPTY OR "Bug Reported by" = Customer) AND (status != closed OR status changed to closed after -30d) ORDER BY updated DESC JIRA has a very highly-customizable workflow, which controls how tickets of various types flow from one state to another, and includes optional things like permission restrictions, required fields at certain states, etc. This can be pretty powerful and useful, and it can also be horribly crippling. I wasn't the one that introduced JIRA, but took it over fairly quickly. At this point, I don't think we have any permission restrictions on workflow (that is: if you have access to transition issues on a project, you can do anything). The only actual restriction that springs to mind is the "fixVersion" field (which we use for targeting and then later confirming what release it's in) must not be blank when closing an issue as "fixed". We also early on identified any situations where people had to quickly transition between 2 or 3 workflow states (usually brought up during sprint retrospectives) to do something, and made a way to transition directly. I suspect most of the pain and hate comes from badly configured or even draconian rules. If you try to make it so only QA or a manager can close a ticket, you're going to cause friction. If you try to enforce fields get filled out even if you're closing as "wontfix", it will cause friction. If you also require 8 workflow transitions to get it from "new" to "closed" -- even for wontfix -- then yeah, people will rightfully hate it. One of the best and worst things about JIRA is it's very customizable. If your admin wants to make it a pain in the ass to get work done, JIRA will happily allow them to configure it that way.

adrianN 11y ago

Have you tried the competition? They all seem to be pretty bad.

deleted 11y ago
[deleted]
daveguy 11y ago
What would make for a good one?

Rexxar 11y ago

I'm not sure if Jira is inherently bad or if Jira is destroyed by project managers that force developers to use it as a reporting/management tool and not as a bug-tracking tool.

mgkimsal 11y ago
I'm diving in to a new project right now - third one with Jira/Confluence, and working with a freelance PM on it. The one issue she's got with it is trying to generate "good reports" with it for the 'biz folks' on the project. :) That said, we're still going with it, partially because the other tools we've tried all... don't work together very well. Documenting things in Confluence and tying tickets to those documents directly does wonders for bridging the gap between tech/dev and the other parts of a project that think in English. There are no doubt better 'bug trackers' out there, and there are no doubt better 'document collaboration' tools, and better 'planning' tools, but I've not found any that play nice together. Open to suggestions...
oneJob 11y ago
My experience also suggests that this is the real issue. Someone has to make a decision on which solution to use for their "agile" development workflow, but this someone doesn't understand that they are actually purchasing a product with a constrained, predefined version of agile. Even though it is somewhat flexible it doesn't perfectly map onto this person's version of agile and so, since they've already paid the licensing fees and gone through the office politics of getting buy in or stuffing it down the users throats, they don't want to admit that either their version of agile could be tweaked or that they should have licensed different software. So then, the mess begins. At every turn square pegs are forced into round holes and workflows are misused with consequences that are not immediately evident. A year down the road and everyone is frustrated. You'd be better off using an excel workbook. Now you have to explain to everyone you onboard why your version of agile is so much better than other versions and warranted creating this monstrosity which they must figure out how to use without documentation (which is useless at this point) and without frustrating their new coworkers with too many questions about the arbitrary nature of their system, which they hate and had shoved down their throats.

trhway 11y ago

>their success baffles me what you described is a typical enterprise software which naturally leads to its maker being a solid tech performer. Enterprises like enterprise software. In my experience, in addition to all what you mentioned, the Jira was also slow as hell on our pretty large deployment. Like an icing on the cake, it made it very enterprise-y and natural in our BigCo environment. Mid management and their suckers loved it during those couple years of Black Death... err... Agile Lean Scrum pandemic.

yawgmoth 11y ago
You obviously wouldn't think that poor performance and usability was an indicator of a reasonable tool for a job - no one would. Perhaps the people with which you worked were simply making bad decisions? > those couple years of Black Death... err... Agile Lean Scrum pandemic. What's wrong with SCRUM?
- pc86 11y ago
  Nothing, but let's not let that get in the way of the anti-enterprise HN circlejerk.

NikolaeVarius 11y ago

I don't know about you, but after I learned how to really use it, I actually like it. Did you ever dive into all the cool stuff you can do?

oneJob 11y ago
Agreed. If you don't make it your business to create the perfect workflow software for your coworkers, and instead learn to use it as designed, it may not be perfect, but it works well and has some really nice features. It certainly works well enough, when used as designed and only using the pieces you need instead of trying to find uses for stuff that you can do without and which will only complicate your work, and is a good tool that can let you get back to your work.

yawgmoth 11y ago

You can customize what's on any given view in a project. You can also use any number of plugins for Agile, such as Grasshopper. It integrates nicely with various source control technologies to keep track of work items and tickets/stories, being able to plug sprints into cards on Confluence (say describing long-term goals or release requirements) is convenient. There are certainly reasons for its success, despite the recent surfacing of anti-enterprise sentiment on HN.

FLUX-YOU 11y ago

I don't see how the UX was bad from a developer point of view. I mostly just created/assigned tickets around though.

gregmac 11y ago

I have the opposite experience. First of all, like any system, the data for search is as good as the data entered: if the users put in garbage, you'll have trouble finding things. If your users are very good about making proper titles, using appropriate labels, etc, and most importantly, fixing up (other people's) badly-entered issues when they come across them, you won't have this trouble. In fact, JQL is freaking awesome. It's really like using SQL for finding tickets. For a mildly complex example, here's the JQL I use for viewing active customer-reported bugs: type = Bug AND ("Related Support Tickets" is not EMPTY OR "Bug Reported by" = Customer) AND (status != closed OR status changed to closed after -30d) ORDER BY updated DESC JIRA has a very highly-customizable workflow, which controls how tickets of various types flow from one state to another, and includes optional things like permission restrictions, required fields at certain states, etc. This can be pretty powerful and useful, and it can also be horribly crippling. I wasn't the one that introduced JIRA, but took it over fairly quickly. At this point, I don't think we have any permission restrictions on workflow (that is: if you have access to transition issues on a project, you can do anything). The only actual restriction that springs to mind is the "fixVersion" field (which we use for targeting and then later confirming what release it's in) must not be blank when closing an issue as "fixed". We also early on identified any situations where people had to quickly transition between 2 or 3 workflow states (usually brought up during sprint retrospectives) to do something, and made a way to transition directly. I suspect most of the pain and hate comes from badly configured or even draconian rules. If you try to make it so only QA or a manager can close a ticket, you're going to cause friction. If you try to enforce fields get filled out even if you're closing as "wontfix", it will cause friction. If you also require 8 workflow transitions to get it from "new" to "closed" -- even for wontfix -- then yeah, people will rightfully hate it. One of the best and worst things about JIRA is it's very customizable. If your admin wants to make it a pain in the ass to get work done, JIRA will happily allow them to configure it that way.