5 ms·

I still don't understand why people hate JIRA so much. It's not great but it's not nearly as awful as people seem to make it out to be. I found the Github integ

I still don't understand why people hate JIRA so much. It's not great but it's not nearly as awful as people seem to make it out to be. I found the Github integration was really sharp as well.

cure 5y ago
I guess you're not a developer. JIRA is incredibly convoluted and backwards from a development perspective, because it was built for a different audience (product? sales? I'm not sure). Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.
- spc476 5y ago
  Perhaps it's down to how JIRA is configured. At $JOB, if you mention the JIRA ticket in a commit message, a link will show up in the ticket to show the commit (it may take some time to show up, but it does eventually). Also, there's an obvious link on the ticket to see all activity.
- brightball 5y ago
  Very much a developer. :) Used it for 5 years at a midsized business and had an overall positive experience with it.
- mbrodersen 5y ago
  25 years of professional developer experience here. I think JIRA works just fine. Is it perfect? Of course not. Nothing is. Is it better than most other imperfect alternatives? Yeah pretty much. Is the cost of switching to something else that also isn’t perfect worth it? Probably not.
NikolaeVarius 5y ago
Jira can be fine if you keep it simple and straightforward. You do a task, you move it on the kanban board. Done It quickly becomes not fine when you have PMs, Teams Leads and whatever creator vast amounts of workflow crap, automation, a billion tags, sprints.
Twisol 5y ago
For the teams I've been on, Jira is less in support of team processes and more an excuse for their nonexistence. The following exchange is only slightly doctored: "What are our team processes?" "Oh, we use Jira." ... I suppose that's not Jira's fault, exactly, but you can see why it would have a bad rap.
commandlinefan 5y ago
JIRA as a generic issue tracking system is fine - and to the extent that it's used as a generic issue tracking system in cases where you actually need a generic issue tracking system, it's acceptable (bugzilla was just fine, too, though). It is very useful, when somebody identifies and reports an issue, to have an "issue #" to associate with it so that if somebody wants to know whatever happened to issue #34, they can just go take a look and see that it was never assigned to anybody, or it's already been fixed, etc. The problem is when "scrum masters" start trying to apply Taylorism (the only thing they know) to software development on top of JIRA. That's when you get JIRA tickets with vague descriptions like "simplify login flow" or "reduce memory usage" and some self-important jerk insisting that you either assign a "point value" to it and finish it in two weeks or "break it down into smaller chunks that you can estimate".
dcminter 5y ago
I think on-prem JIRA (often with some additional DB customisation work) is probably the reason. I've been at a few places where it was hideously slow and flakey (erroring just after you save a long story edit). In recent years I've mostly used it in SaaS form, or at least very well provisioned. I don't love it, and the UI is clunky (especially the messed-up almost-but-not-quite-markdown or wysi-almost-wyg) but it's usable, widely known, and as you note has some useful integrations. Edit: the hard part - and this has nothing to do with JIRA is getting people to write well-formed stories. I have spent a lot of my professional life fighting to deprecate contentless stories!
bitwize 5y ago
Well, JIRA isn't terrible. It does its job reasonably well, but it really shows that it's a project management tool that developers happen to be forced to use, and it's the standard "agile" tool. Its use is a red flag that maybe the org hasn't put much thought into encouraging developers to work efficiently and cultivating Csikszentmihalyian "flow". A typical corporate JIRA workflow is an example of what I call switch-cutting: making the production of metrics that will be used by management to crack the whip later, the responsibility of the line workers (akin to the old-timey practice of making a child cut the switch with which they will be beaten). But Scrum itself has this problem as well, and JIRA is just a tool to that end. Like I said, there are far worse things that could be forced on a developer team -- like VersionOne, switching away from which to JIRA will seem as a breath of fresh air.

I still don't understand why people hate JIRA so much. It's not great but it's not nearly as awful as people seem to make it out to be. I found the Github integration was really sharp as well.

cure 5y ago

I guess you're not a developer. JIRA is incredibly convoluted and backwards from a development perspective, because it was built for a different audience (product? sales? I'm not sure). Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.

spc476 5y ago
Perhaps it's down to how JIRA is configured. At $JOB, if you mention the JIRA ticket in a commit message, a link will show up in the ticket to show the commit (it may take some time to show up, but it does eventually). Also, there's an obvious link on the ticket to see all activity.
brightball 5y ago
Very much a developer. :) Used it for 5 years at a midsized business and had an overall positive experience with it.
mbrodersen 5y ago
25 years of professional developer experience here. I think JIRA works just fine. Is it perfect? Of course not. Nothing is. Is it better than most other imperfect alternatives? Yeah pretty much. Is the cost of switching to something else that also isn’t perfect worth it? Probably not.

NikolaeVarius 5y ago

Jira can be fine if you keep it simple and straightforward. You do a task, you move it on the kanban board. Done It quickly becomes not fine when you have PMs, Teams Leads and whatever creator vast amounts of workflow crap, automation, a billion tags, sprints.

Twisol 5y ago

For the teams I've been on, Jira is less in support of team processes and more an excuse for their nonexistence. The following exchange is only slightly doctored: "What are our team processes?" "Oh, we use Jira." ... I suppose that's not Jira's fault, exactly, but you can see why it would have a bad rap.

commandlinefan 5y ago

JIRA as a generic issue tracking system is fine - and to the extent that it's used as a generic issue tracking system in cases where you actually need a generic issue tracking system, it's acceptable (bugzilla was just fine, too, though). It is very useful, when somebody identifies and reports an issue, to have an "issue #" to associate with it so that if somebody wants to know whatever happened to issue #34, they can just go take a look and see that it was never assigned to anybody, or it's already been fixed, etc. The problem is when "scrum masters" start trying to apply Taylorism (the only thing they know) to software development on top of JIRA. That's when you get JIRA tickets with vague descriptions like "simplify login flow" or "reduce memory usage" and some self-important jerk insisting that you either assign a "point value" to it and finish it in two weeks or "break it down into smaller chunks that you can estimate".

dcminter 5y ago

I think on-prem JIRA (often with some additional DB customisation work) is probably the reason. I've been at a few places where it was hideously slow and flakey (erroring just after you save a long story edit). In recent years I've mostly used it in SaaS form, or at least very well provisioned. I don't love it, and the UI is clunky (especially the messed-up almost-but-not-quite-markdown or wysi-almost-wyg) but it's usable, widely known, and as you note has some useful integrations. Edit: the hard part - and this has nothing to do with JIRA is getting people to write well-formed stories. I have spent a lot of my professional life fighting to deprecate contentless stories!

bitwize 5y ago

Well, JIRA isn't terrible. It does its job reasonably well, but it really shows that it's a project management tool that developers happen to be forced to use, and it's the standard "agile" tool. Its use is a red flag that maybe the org hasn't put much thought into encouraging developers to work efficiently and cultivating Csikszentmihalyian "flow". A typical corporate JIRA workflow is an example of what I call switch-cutting: making the production of metrics that will be used by management to crack the whip later, the responsibility of the line workers (akin to the old-timey practice of making a child cut the switch with which they will be beaten). But Scrum itself has this problem as well, and JIRA is just a tool to that end. Like I said, there are far worse things that could be forced on a developer team -- like VersionOne, switching away from which to JIRA will seem as a breath of fresh air.