Hacker News Reader

>If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot.

If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.

There are places where the incoming work is pretty high volume...so you need a "ticket" system just to make sure it's all accounted for. Jira isn't perfect, but I can't tell if you just generally object to tracking work, or if the particular environment you're in just doesn't need that sort of thing.

And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not.

I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.

You seem to be talking about JIRA reports. JIRA != Trello + fancy reports.

The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.

(Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )

> The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.

This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason...

And you're also stuck carrying around all the features you don't use...

You can also build flexible, low-overhead workflows using JIRA. The key is to keep managers out of the admin section, make sure the dev team is in full control, and tend towards saying "no" whenever anyone asks for changes to the workflow.

I think anecdotally that may work, but I'm not convinced that dev teams are that much better than "managers" are at creating or managing process (nor are they often very interested in doing it)...

But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.

Just anecdotally I can confirm that different development and product teams work good with JIRA and Confluence in conjunction.

The agency I work at uses these tools together with ovur clients, as well as internally on different levels.

We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...

> The key is to keep managers out of the admin section

Works as a general rule, too.

Apache uses them: https://issues.apache.org/jira/secure/BrowseProjects.jspa?se...

I am not sure who the 'management' would be in their case.

the companies that pay the foundation bills.

I shall steal the quote, "Rorschach number generators for management" xD

I'd argue that we're stretching a bit with the word "need" here. Are we still at the point where every software development team has to come up with their own special process?

I feel like, as an industry, we should be moving beyond that at some point.

Indeed, JIRA is a necessary evil. There is nothing out there with the flexibility of JIRA, and a plugin ecosystem. The user interface is driven by its fully-configurable nature and almost by definition it will suck.

Now, if there was a way to grow its user interface along with the organization's growth, it would be fantastic.

Could third-party UX be built on the API for JIRA's public cloud service?

The recent move to a react front end has (to my team) brought a number of improvements

> but a non-negligible number of smart people think that these integrations are worth a lot

Just throwing something out there... But I wonder what the spread of these "smart" people is across "development" and "management"? The parent comment seems related to this...

> JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.

Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealing.

Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealin

The "tool" doesn't need to be overly "opinionated" just like a programming language, I want a tool to be flexible. It's my responsibility as the architect to constrain the tool/language for my environment.

I think broadly this metaphor works. But you, as an architect, have a breadth (probably) of experience to draw from that dictates how you work in that environment. I feel safe saying that those that are creating or managing processes in the JIRA environment often don't have the equivalent experience (or they have experience only in other equally dysfunctional uses of JIRA). And that JIRA doesn't exactly enforce good habits on its own (a la JavaScript, for example).