3 ms·

> 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 o

> 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.

scarface74 9y ago
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.
- ravitation 9y ago
  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).

scarface74 9y ago

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.

ravitation 9y ago
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).