9 ms·

I would really like to understand who makes the decision to purchase JIRA. It's like the C++ of ticketing software--it does everything because no one wanted to

I would really like to understand who makes the decision to purchase JIRA. It's like the C++ of ticketing software--it does everything because no one wanted to sit down and think critically about the use cases and instead decided it would be easier to say "yes" to every single feature request. It definitely feels like whoever is buying JIRA is not on the team who is using it (maybe IT or finance) because it ticks their boxes and it has such a huge list of features that nominally it appears to tick the product development boxes (ignoring more subjective concerns like "quality", "performance", and "usability"). I would really like to try working in an organization that uses something simpler, like Trello (although now that this is also an Atlassian property, maybe not exactly Trello?).

sam0x17 5y ago
And yet, it actually is set up in an extremely opinionated annoying way. For example there is no way to actually assign multiple users to the same ticket, which is a big problem if your org legitimately does pair programming (mine does for juniors)
- Cd00d 5y ago
  Why not just clone the ticket?
- robertlagrant 5y ago
  Having a single owner for each ticket is not a bad idea. You can see contributors in git.
RandallBrown 5y ago
I think people buy JIRA because you can set it up however you want. I've seen it almost as simple as Trello and much more complicated. It doesn't have to be terrible, it just usually is. If JIRA didn't allow you to make it terrible, it wouldn't allow for some of the absurd things that people want it for and those companies might not buy it.
- a4isms 5y ago
  They used to say of Microsoft Word, "Nobody uses more than 5% of its features, but every company uses a different 5%." The saying is apocryphal and unlikely to be accurate, but the shape of the thing its describing applies to almost every piece of enterprise software whether installed on-prem or SaaS. And as another comment points out, at Enterprise scale you can substitute "team" or "group" for customer. Every team might use a different 5%, and unless you standardize their processes, you have to buy the product that can accomodate all of their needs.
  - grog454 5y ago
    >"Nobody uses more than 5% of its features, but every company uses a different 5%." >The saying is apocryphal and unlikely to be accurate Well its mathematically impossible to be accurate as soon as you have > 20 users.
    - robertlagrant 5y ago
      A better counterexample is that one user could use all features. But your statement doesn't make sense; there might be millions of features, and trillions of ways to combine them to make 5%.
    - KronisLV 5y ago
      > Well its mathematically impossible to be accurate as soon as you have > 20 users. It's probably in the semantics. Text input and editing is clearly a part of functionality that's probably used by everyone (or at least most users), so it's not possible for "different 5%" to mean what you're alluding to, maybe the phrasing needs work. In any given 5% there might be 1-4% of overlap with what others are using and the remainder of that is specific to the company.
      - grog454 5y ago
        And the greater the degree of overlap the weaker the implicit argument. If it's a uniform distribution of discrete features then each feature is equally "important" and worth equal resources and dev time. If 81/100 companies use the exact same 5% of features and the remaining 19 cover the remaining 95%, then all else equal you can probably drop 95% of your features and still do well.
BlargMcLarg 5y ago
Trickle down and first mover. JIRA was there first being "decently ok", enough people adapted it and now others do the same. Then couple with that what you write, the people in charge of deciding the software are generally the ones who can justify wasting half their day on it. To this day I still don't know what JIRA does so much better that other products don't which big corps are willing to waste months worth of manhours over. It's biggest selling point is integration with the remainder of the Atlassian stack, not exactly known for being great either.
- vikingerik 5y ago
  Jira's big feature is being widely known. It's the modern version of "nobody ever got fired for buying IBM."
dangus 5y ago
The answer is medium to large companies. Jira is a tool that can satisfy hundreds of different teams’ work management needs without having to buy dozens of different products. The fact that it’s so feature packed and customizable is the point. I think the complainers are not really investing the time in to change project settings to fit their needs. My only complaint about the Atlassian suite is the performance of Jira and Confluence. The overall page load speed is too slow.
- macintux 5y ago
  How do you change the markup language to be consistent between Jira and Confluence? How do you eliminate all non-task ticket types in a Jira board and allow any ticket to be a child of any other ticket? It’s hard to configure away complexity from a product if it’s designed to be complicated.
  - Karunamon 5y ago
    Re 1: I'm not sure why that's a necessity beyond a notion of consistency. I find that major wiki editors are not often major ticket creators, and these are different products with different audiences at the end of the day. Also, Confluence uses a WYSIWYG editor, so it's rare to need to think about the markup. Re 2: Set the project's issue type scheme to one that only allows tasks and subtasks. That gets you one level of nesting. (And even though task and subtasks are different issue types, changing from one to the other is trivial since they have identical fields.) Allowing epics gets you another at the top level. That's a bit limited, but wouldn't arbitrary nesting be even more complex?
  - chrisseaton 5y ago
    > How do you change the markup language to be consistent between Jira and Confluence? This here is the single most insane thing about Atlassian.
  - DocTomoe 5y ago
    > allow any ticket to be a child of any other ticket? I have no idea why you would want this from a work management point of view, but you can just use issue linking to describe a parent <-> child relationship.
anecd0te 5y ago
ime people pick Jira because they've used Jira and have been promoted via the peter principle to the level at which they make purchasing decisions.
- brimble 5y ago
  IBM effect. If you don't care a whole lot about your ticketing system, you just pick Jira because everyone'll nod along with the choice and you won't personally be blamed if/when it sucks, you won't make enemies or have to argue over the choice because it can't do something that someone else in the org "needs" it to do, et c.
tenacious_tuna 5y ago
My relatively small team at a massive enterprise built all our report generation tools around JIRA for an entire class of offerings. It's been easier for them to justify continuing to pay for JIRA and keep it propped up than to develop (or migrate to) a new solution. As the lone dev on the team I've been continually astounded by my leadership's willingness to commit more and more to tech debt laden paths. The notion that all software requires maintenance is anathema to them, and it's led us to be 'cornered' into decisions re: what software we can use / where we can invest our discretionary funding. Moreover, we're constrained by the parent mega-enterprise's software purchase policies; JIRA's already approved (and run elsewhere in the enterprise), whereas off-the-shelf or SaaSy alternatives are significantly harder to get buy-in for. (No using corporate cards for SaaS, all purchases need to go through the quote/purchase-order process, etc).
- peletiah 5y ago
  I once worked for a company that did the same - but with Lotus Notes, in 2013. Modified it into a full-fledged ticketing- and time-tracking tool. Using it took a half hour out of each workday.
Forgeties79 5y ago
I really, really like Trello and am dreading the day when atlassian starts tinkering with it in any real capacity. As a content creator, it is the first workflow system I’ve ever seen that I can effectively share with my client. It’s so simple and streamlined and the fact that I’ve stuck with it despite my ADHD says a lot. Clients add their notes to the card, I check the boxes as I hit the notes, and I move the card further right as we enter different stages of the post production process. We then have a column of every completed project, which is incredibly easy to sift through if we need to revisit something. It’s literally left to right in the workflow, it visually is telling me where we are at all times. It’s incredibly simple and elegant. For fast turnaround, relatively stripped down content (like podcasts) there is nothing like it.
systemvoltage 5y ago
What's wrong with C++? Seems unfair to compare it with JIRA.
- throwaway894345 5y ago
  I was a C++ programmer in a past life and I sorta like it. C++ and JIRA seem to have the same philosophy with respect to choosing which features to admit: "yes". The idea is that by supporting the largest number of features possible, they'll surely build something that everyone likes because it will tick everyone's boxes. What people frequently fail to realize is that the absence of misfeatures or redundant features is an important feature in and of itself. Moreover, the more features you support, the harder it is to control for quality.
  - hhmc 5y ago
    > The idea is that by supporting the largest number of features possible, they'll surely build something that everyone likes because it will tick everyone's boxes. The idea that the C++ committee are unthinking people pleasers it patently false. C++ does have a lot of cruft, but mostly because it aims to: i) support new features ii) maintain pretty strong backward compatibility guarantees In general the new features are actually pretty well liked, but in conjunction with (ii) it creates a big language. There's a reasonably decent subset that can be carved out, but it's also clear why newcomers without legacy baggage (e.g. rust) are making inroads.
    - throwaway894345 5y ago
      "unthinking people pleasers" isn't how I would characterize it; rather, I think of it more as a "kitchen sink" or "more is more" philosophy rather than a "less is more" philosophy. I'm sure the committee deliberated extensively, but deliberation within their particular philosophical context still produced an unpleasant result. I think the same is true of JIRA. EDIT: clarified wording a bit.
- uuyi 5y ago
  Ex C++ dev and ex JIRA admin. They are the same class of complete bananas.
richardw 5y ago
I’m just a user but totally happy with all our Atlassian apps. Confluence is a huge win across our multi-thousand person company and the best teams use it very well. I like the integration between Jira and Bitbucket. We don’t over complicate things and it works fine. It’s like my taste in wine. I don’t want an overdeveloped sense of taste where only a $400 bottle will do. I’m fine with what we have because the work is what excites me and if people are documenting projects and managing workloads and committing code, we’re 90% of the way there.
- danielovichdk 5y ago
  Good point. Wine that costs 400$ is for fun. You don't drink that professionally.
x0x0 5y ago
I made the decision, unfortunately. The rationale was literally that I hated pivotal tracker -- what a garbage app that is -- and I'd heard of jira, needed something to track bugs / work items, and signed up. It crucially had a zendesk -> jira sync, so all our zendesk requests could end up in jira. In the beginning, with me plus 2 engineers, I noticed it was slow but since I used it for 20 minutes a week, that didn't really matter. By the time I started using it for an hour a day, we had 10 engineers on 2 teams using it. I got to see a friend using linear, and I had some spare time that I was going to use to switch, but I couldn't get in the beta. By the time they let me in, the opportunity was over and I was too busy.
closeparen 5y ago
JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque: you have no way of knowing whether they're working or not. Another problem you face is that they're uppity: people who went to college and got used to managing their own time now have all kinds of idiosyncratic ideas about how to manage their own time and arrange their own working lives. Since you are a middle manager you despise local differences. Since you are a manager you're pretty sure that only you and your lieutenants can be trusted with this kind of decision making power. Adopting JIRA is a powerful level to put people back in their place as work item churning machines. Constraints such as only certain people can create or assign tickets, only certain people can mark them completed, only certain states are valid transitions from other states, etc. implement a level of domination over white-collar workforces that managers would be otherwise uncomfortable asserting face to face. Other ticketing systems do not work nearly as well for this purpose because they are designed mainly as external brains or communication platforms for workers, and they assume a level of worker autonomy in moving tasks through their lifecycle. In Trello you cannot make it so that a PM has to sign off before a card is moved to the in-progress column, or that only in-progress cards can have code reviews associated with them. JIRA eats these kinds of requirements for breakfast. EDIT: This is not to say you can't use JIRA in a workflow-neutral way, or that everyone uses it for this reason, but I would submit that it's JIRA's differentiated advantage.
- Rimbo 5y ago
  Oh, nonsense. People buy Atlassisn because the licensing is cheap, not because it's particularly good at what it does or designed with any particular workflow in mind.
  - ofrzeta 5y ago
    I don't see how it is cheap. Standard may be cheap but then you are missing a lot of features that are announced on the product pages with a small footnote saying "only in premium".
  - Viliam1234 5y ago
antiterra 5y ago
In a lot of ways, JIRA disrupted Remedy Action Request System, which had a painful transition from X to Windows client. Remedy was even more admin dependent and unwieldy.
deleted 5y ago
[deleted]
csours 5y ago
"I am not a fish" - the people who buy it are not the people who use it. - https://www.ted.com/talks/seth_godin_this_is_broken https://www.ted.com/talks/seth_godin_this_is_broken
SatvikBeri 5y ago
At big companies I've worked at, the justification was that JIRA was the only one that met all the regulatory/compliance requirements. I don't know if this is actually true, but smaller companies certainly don't market compliance as well.
notreallyserio 5y ago
JIRA is generally fine software that is good enough for most folks, especially if you're willing to adapt your workflow to it. Where it goes wrong is where tools like Jenkins go wrong: folks add too much customization. That means the tool is often the wrong one for the job, but instead of picking something that's a better match out of the box folks stick with the easy choice (extend what they have).
prescriptivist 5y ago
This reminds me of one of my favorite HN comments of all time: https://news.ycombinator.com/item?id=16424423 https://news.ycombinator.com/item?id=16424423
JoBrad 5y ago
I was part of the decision to purchase Atlassian tools at my company. We had been using a variety of self-hosted and SaaS tools which had varying abilities to integrate with each other. We’ve had very positive feedback from users since switching to them. We were also able to move some of our help desks to JIRA Service Management, and away from another self-hosted product which is still used by a good portion of our business. The self-hosted product is honestly a nightmare to maintain and keep secure. According to the vendor, the “fix” is to have 1-2 people dedicated to that product, which simply isn’t something that my team has the bandwidth or will to do. JIRA does try to be all things to all people…and mostly succeeds. For instance, we use the same workflow and mostly the same nomenclature across our development and helpdesk teams. Some of our software projects use Kanban-style workflows, while others use sprints, but we can keep track of a project across multiple teams using the same tools. I’m sure other products also offer this, but we liked the integration and overall capability for the price. There are definitely issues: some feature requests and bugs have languished in their backlog for years. But you can get started very quickly and we’ve had great feedback from users.
fnord123 5y ago
> like Trello Maybe Asana or Monday would work for you.
robertlagrant 5y ago
The reason to buy Jira is that loads of stuff integrates with it, and lots of people know it. Maybe not perfect, but that's why. And unless you're in it all the time, which some people may be, its ergonomics are not as important as, say, an IDE's.
Cd00d 5y ago
Interesting take. Personally, I like JIRA. I think it adds a ton of transparency in our org, and while I've used Trello for personal and home projects, I don't see how it's good enough for business. Trello doesn't even allow for time estimates (last I tried), which for us is part of planning. Search in JIRA is also really good, so no ticket is ever just lost to the ether. Sure, it's not perfect, and waiting for a board to load is annoying, but for distributed work and visibility, I haven't seen something as professionally useful. Open to exploring though.
- stuff4ben 5y ago
  GitHub Enterprise and ZenHub Enterprise work well for us here @IBM, not that I speak on behalf of them, just a drone doing work.
  - Cd00d 5y ago
    ZenHub looks really interesting - thank you for pointing it out. How good is ticket search? I have to be honest, JQL is the superpower that makes or breaks for me.
karaterobot 5y ago
The way it works is, someone always says "Sure, JIRA is bad out of the box, but you can customize it to work the way you want" and there is nobody around to say "so now you have two problems: a bad system that depends on having an expert to make it work the way it should". Then, you pay for JIRA, and that expert customizes it the way they like. It still doesn't work very well for most people. Nobody likes it except one stakeholder, and the engineering lead who acts as a admin on it. A while later, those people have left the company, and everyone else is out of luck. Seen this exact scenario play out at two different companies now. Am witnessing it play out in real time at a third.
throwawayboise 5y ago
The one place I worked that used Jira was a small-but-not-tiny company (about 15 devs at the time). The only people who actually used Jira were the managers. Developers got printed stories. These were used for planning, and were printed on cards and taped to a white board when ready. Developer would pull a card to work on, and return it to the manager when it was complete. The manager did all the status updates and reporting to upper management. IDK if this was to cheap out on the licensing with a minimal number of users, or if it was to insulate the developers from the experience of using Jira. Perhaps some of both. Clearly that usage pattern would only scale so far.
spookthesunset 5y ago
I find it helpful to stop thinking of JIRA as a bug tracker or anything like that. In my opinion JIRA is more of a way to create and track workflows. It can be used as a blank slate for quite a lot of things (which I cannot come up with any examples for at the moment!) That being said, because it can do anything, it doesn't take much effort to make a workflow as painful as possible. Somebody with the "right" mind might make all kinds of checkpoints in a workflow, which makes a lot of operations a pain in the ass because you wind up hopping through a bunch of steps. Pretty sure in our org we just make our workflow "you can hop from any state to any other state"--basically a free-for-all. Dunno my point, but there you go!

sam0x17 5y ago

And yet, it actually is set up in an extremely opinionated annoying way. For example there is no way to actually assign multiple users to the same ticket, which is a big problem if your org legitimately does pair programming (mine does for juniors)

Cd00d 5y ago
Why not just clone the ticket?
robertlagrant 5y ago
Having a single owner for each ticket is not a bad idea. You can see contributors in git.

RandallBrown 5y ago

I think people buy JIRA because you can set it up however you want. I've seen it almost as simple as Trello and much more complicated. It doesn't have to be terrible, it just usually is. If JIRA didn't allow you to make it terrible, it wouldn't allow for some of the absurd things that people want it for and those companies might not buy it.

a4isms 5y ago
They used to say of Microsoft Word, "Nobody uses more than 5% of its features, but every company uses a different 5%." The saying is apocryphal and unlikely to be accurate, but the shape of the thing its describing applies to almost every piece of enterprise software whether installed on-prem or SaaS. And as another comment points out, at Enterprise scale you can substitute "team" or "group" for customer. Every team might use a different 5%, and unless you standardize their processes, you have to buy the product that can accomodate all of their needs.
- grog454 5y ago
  >"Nobody uses more than 5% of its features, but every company uses a different 5%." >The saying is apocryphal and unlikely to be accurate Well its mathematically impossible to be accurate as soon as you have > 20 users.
  - robertlagrant 5y ago
    A better counterexample is that one user could use all features. But your statement doesn't make sense; there might be millions of features, and trillions of ways to combine them to make 5%.
  - KronisLV 5y ago
    > Well its mathematically impossible to be accurate as soon as you have > 20 users. It's probably in the semantics. Text input and editing is clearly a part of functionality that's probably used by everyone (or at least most users), so it's not possible for "different 5%" to mean what you're alluding to, maybe the phrasing needs work. In any given 5% there might be 1-4% of overlap with what others are using and the remainder of that is specific to the company.
    - grog454 5y ago
      And the greater the degree of overlap the weaker the implicit argument. If it's a uniform distribution of discrete features then each feature is equally "important" and worth equal resources and dev time. If 81/100 companies use the exact same 5% of features and the remaining 19 cover the remaining 95%, then all else equal you can probably drop 95% of your features and still do well.

BlargMcLarg 5y ago

Trickle down and first mover. JIRA was there first being "decently ok", enough people adapted it and now others do the same. Then couple with that what you write, the people in charge of deciding the software are generally the ones who can justify wasting half their day on it. To this day I still don't know what JIRA does so much better that other products don't which big corps are willing to waste months worth of manhours over. It's biggest selling point is integration with the remainder of the Atlassian stack, not exactly known for being great either.

vikingerik 5y ago
Jira's big feature is being widely known. It's the modern version of "nobody ever got fired for buying IBM."

dangus 5y ago

The answer is medium to large companies. Jira is a tool that can satisfy hundreds of different teams’ work management needs without having to buy dozens of different products. The fact that it’s so feature packed and customizable is the point. I think the complainers are not really investing the time in to change project settings to fit their needs. My only complaint about the Atlassian suite is the performance of Jira and Confluence. The overall page load speed is too slow.

macintux 5y ago
How do you change the markup language to be consistent between Jira and Confluence? How do you eliminate all non-task ticket types in a Jira board and allow any ticket to be a child of any other ticket? It’s hard to configure away complexity from a product if it’s designed to be complicated.
- Karunamon 5y ago
  Re 1: I'm not sure why that's a necessity beyond a notion of consistency. I find that major wiki editors are not often major ticket creators, and these are different products with different audiences at the end of the day. Also, Confluence uses a WYSIWYG editor, so it's rare to need to think about the markup. Re 2: Set the project's issue type scheme to one that only allows tasks and subtasks. That gets you one level of nesting. (And even though task and subtasks are different issue types, changing from one to the other is trivial since they have identical fields.) Allowing epics gets you another at the top level. That's a bit limited, but wouldn't arbitrary nesting be even more complex?
- chrisseaton 5y ago
  > How do you change the markup language to be consistent between Jira and Confluence? This here is the single most insane thing about Atlassian.
- DocTomoe 5y ago
  > allow any ticket to be a child of any other ticket? I have no idea why you would want this from a work management point of view, but you can just use issue linking to describe a parent <-> child relationship.

anecd0te 5y ago

ime people pick Jira because they've used Jira and have been promoted via the peter principle to the level at which they make purchasing decisions.

brimble 5y ago
IBM effect. If you don't care a whole lot about your ticketing system, you just pick Jira because everyone'll nod along with the choice and you won't personally be blamed if/when it sucks, you won't make enemies or have to argue over the choice because it can't do something that someone else in the org "needs" it to do, et c.

tenacious_tuna 5y ago

My relatively small team at a massive enterprise built all our report generation tools around JIRA for an entire class of offerings. It's been easier for them to justify continuing to pay for JIRA and keep it propped up than to develop (or migrate to) a new solution. As the lone dev on the team I've been continually astounded by my leadership's willingness to commit more and more to tech debt laden paths. The notion that all software requires maintenance is anathema to them, and it's led us to be 'cornered' into decisions re: what software we can use / where we can invest our discretionary funding. Moreover, we're constrained by the parent mega-enterprise's software purchase policies; JIRA's already approved (and run elsewhere in the enterprise), whereas off-the-shelf or SaaSy alternatives are significantly harder to get buy-in for. (No using corporate cards for SaaS, all purchases need to go through the quote/purchase-order process, etc).

peletiah 5y ago
I once worked for a company that did the same - but with Lotus Notes, in 2013. Modified it into a full-fledged ticketing- and time-tracking tool. Using it took a half hour out of each workday.

Forgeties79 5y ago

I really, really like Trello and am dreading the day when atlassian starts tinkering with it in any real capacity. As a content creator, it is the first workflow system I’ve ever seen that I can effectively share with my client. It’s so simple and streamlined and the fact that I’ve stuck with it despite my ADHD says a lot. Clients add their notes to the card, I check the boxes as I hit the notes, and I move the card further right as we enter different stages of the post production process. We then have a column of every completed project, which is incredibly easy to sift through if we need to revisit something. It’s literally left to right in the workflow, it visually is telling me where we are at all times. It’s incredibly simple and elegant. For fast turnaround, relatively stripped down content (like podcasts) there is nothing like it.

systemvoltage 5y ago

What's wrong with C++? Seems unfair to compare it with JIRA.

throwaway894345 5y ago
I was a C++ programmer in a past life and I sorta like it. C++ and JIRA seem to have the same philosophy with respect to choosing which features to admit: "yes". The idea is that by supporting the largest number of features possible, they'll surely build something that everyone likes because it will tick everyone's boxes. What people frequently fail to realize is that the absence of misfeatures or redundant features is an important feature in and of itself. Moreover, the more features you support, the harder it is to control for quality.
- hhmc 5y ago
  > The idea is that by supporting the largest number of features possible, they'll surely build something that everyone likes because it will tick everyone's boxes. The idea that the C++ committee are unthinking people pleasers it patently false. C++ does have a lot of cruft, but mostly because it aims to: i) support new features ii) maintain pretty strong backward compatibility guarantees In general the new features are actually pretty well liked, but in conjunction with (ii) it creates a big language. There's a reasonably decent subset that can be carved out, but it's also clear why newcomers without legacy baggage (e.g. rust) are making inroads.
  - throwaway894345 5y ago
    "unthinking people pleasers" isn't how I would characterize it; rather, I think of it more as a "kitchen sink" or "more is more" philosophy rather than a "less is more" philosophy. I'm sure the committee deliberated extensively, but deliberation within their particular philosophical context still produced an unpleasant result. I think the same is true of JIRA. EDIT: clarified wording a bit.
uuyi 5y ago
Ex C++ dev and ex JIRA admin. They are the same class of complete bananas.

richardw 5y ago

I’m just a user but totally happy with all our Atlassian apps. Confluence is a huge win across our multi-thousand person company and the best teams use it very well. I like the integration between Jira and Bitbucket. We don’t over complicate things and it works fine. It’s like my taste in wine. I don’t want an overdeveloped sense of taste where only a $400 bottle will do. I’m fine with what we have because the work is what excites me and if people are documenting projects and managing workloads and committing code, we’re 90% of the way there.

danielovichdk 5y ago
Good point. Wine that costs 400$ is for fun. You don't drink that professionally.

x0x0 5y ago

I made the decision, unfortunately. The rationale was literally that I hated pivotal tracker -- what a garbage app that is -- and I'd heard of jira, needed something to track bugs / work items, and signed up. It crucially had a zendesk -> jira sync, so all our zendesk requests could end up in jira. In the beginning, with me plus 2 engineers, I noticed it was slow but since I used it for 20 minutes a week, that didn't really matter. By the time I started using it for an hour a day, we had 10 engineers on 2 teams using it. I got to see a friend using linear, and I had some spare time that I was going to use to switch, but I couldn't get in the beta. By the time they let me in, the opportunity was over and I was too busy.

closeparen 5y ago

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque: you have no way of knowing whether they're working or not. Another problem you face is that they're uppity: people who went to college and got used to managing their own time now have all kinds of idiosyncratic ideas about how to manage their own time and arrange their own working lives. Since you are a middle manager you despise local differences. Since you are a manager you're pretty sure that only you and your lieutenants can be trusted with this kind of decision making power. Adopting JIRA is a powerful level to put people back in their place as work item churning machines. Constraints such as only certain people can create or assign tickets, only certain people can mark them completed, only certain states are valid transitions from other states, etc. implement a level of domination over white-collar workforces that managers would be otherwise uncomfortable asserting face to face. Other ticketing systems do not work nearly as well for this purpose because they are designed mainly as external brains or communication platforms for workers, and they assume a level of worker autonomy in moving tasks through their lifecycle. In Trello you cannot make it so that a PM has to sign off before a card is moved to the in-progress column, or that only in-progress cards can have code reviews associated with them. JIRA eats these kinds of requirements for breakfast. EDIT: This is not to say you can't use JIRA in a workflow-neutral way, or that everyone uses it for this reason, but I would submit that it's JIRA's differentiated advantage.

Rimbo 5y ago
Oh, nonsense. People buy Atlassisn because the licensing is cheap, not because it's particularly good at what it does or designed with any particular workflow in mind.
- ofrzeta 5y ago
  I don't see how it is cheap. Standard may be cheap but then you are missing a lot of features that are announced on the product pages with a small footnote saying "only in premium".
- Viliam1234 5y ago

antiterra 5y ago

In a lot of ways, JIRA disrupted Remedy Action Request System, which had a painful transition from X to Windows client. Remedy was even more admin dependent and unwieldy.

deleted 5y ago

[deleted]

csours 5y ago

"I am not a fish" - the people who buy it are not the people who use it. - https://www.ted.com/talks/seth_godin_this_is_broken https://www.ted.com/talks/seth_godin_this_is_broken

SatvikBeri 5y ago

At big companies I've worked at, the justification was that JIRA was the only one that met all the regulatory/compliance requirements. I don't know if this is actually true, but smaller companies certainly don't market compliance as well.

notreallyserio 5y ago

JIRA is generally fine software that is good enough for most folks, especially if you're willing to adapt your workflow to it. Where it goes wrong is where tools like Jenkins go wrong: folks add too much customization. That means the tool is often the wrong one for the job, but instead of picking something that's a better match out of the box folks stick with the easy choice (extend what they have).

prescriptivist 5y ago

This reminds me of one of my favorite HN comments of all time: https://news.ycombinator.com/item?id=16424423 https://news.ycombinator.com/item?id=16424423

JoBrad 5y ago

I was part of the decision to purchase Atlassian tools at my company. We had been using a variety of self-hosted and SaaS tools which had varying abilities to integrate with each other. We’ve had very positive feedback from users since switching to them. We were also able to move some of our help desks to JIRA Service Management, and away from another self-hosted product which is still used by a good portion of our business. The self-hosted product is honestly a nightmare to maintain and keep secure. According to the vendor, the “fix” is to have 1-2 people dedicated to that product, which simply isn’t something that my team has the bandwidth or will to do. JIRA does try to be all things to all people…and mostly succeeds. For instance, we use the same workflow and mostly the same nomenclature across our development and helpdesk teams. Some of our software projects use Kanban-style workflows, while others use sprints, but we can keep track of a project across multiple teams using the same tools. I’m sure other products also offer this, but we liked the integration and overall capability for the price. There are definitely issues: some feature requests and bugs have languished in their backlog for years. But you can get started very quickly and we’ve had great feedback from users.

fnord123 5y ago

> like Trello Maybe Asana or Monday would work for you.

robertlagrant 5y ago

The reason to buy Jira is that loads of stuff integrates with it, and lots of people know it. Maybe not perfect, but that's why. And unless you're in it all the time, which some people may be, its ergonomics are not as important as, say, an IDE's.

Cd00d 5y ago

Interesting take. Personally, I like JIRA. I think it adds a ton of transparency in our org, and while I've used Trello for personal and home projects, I don't see how it's good enough for business. Trello doesn't even allow for time estimates (last I tried), which for us is part of planning. Search in JIRA is also really good, so no ticket is ever just lost to the ether. Sure, it's not perfect, and waiting for a board to load is annoying, but for distributed work and visibility, I haven't seen something as professionally useful. Open to exploring though.

stuff4ben 5y ago
GitHub Enterprise and ZenHub Enterprise work well for us here @IBM, not that I speak on behalf of them, just a drone doing work.
- Cd00d 5y ago
  ZenHub looks really interesting - thank you for pointing it out. How good is ticket search? I have to be honest, JQL is the superpower that makes or breaks for me.

karaterobot 5y ago

The way it works is, someone always says "Sure, JIRA is bad out of the box, but you can customize it to work the way you want" and there is nobody around to say "so now you have two problems: a bad system that depends on having an expert to make it work the way it should". Then, you pay for JIRA, and that expert customizes it the way they like. It still doesn't work very well for most people. Nobody likes it except one stakeholder, and the engineering lead who acts as a admin on it. A while later, those people have left the company, and everyone else is out of luck. Seen this exact scenario play out at two different companies now. Am witnessing it play out in real time at a third.

throwawayboise 5y ago

The one place I worked that used Jira was a small-but-not-tiny company (about 15 devs at the time). The only people who actually used Jira were the managers. Developers got printed stories. These were used for planning, and were printed on cards and taped to a white board when ready. Developer would pull a card to work on, and return it to the manager when it was complete. The manager did all the status updates and reporting to upper management. IDK if this was to cheap out on the licensing with a minimal number of users, or if it was to insulate the developers from the experience of using Jira. Perhaps some of both. Clearly that usage pattern would only scale so far.

spookthesunset 5y ago

I find it helpful to stop thinking of JIRA as a bug tracker or anything like that. In my opinion JIRA is more of a way to create and track workflows. It can be used as a blank slate for quite a lot of things (which I cannot come up with any examples for at the moment!) That being said, because it can do anything, it doesn't take much effort to make a workflow as painful as possible. Somebody with the "right" mind might make all kinds of checkpoints in a workflow, which makes a lot of operations a pain in the ass because you wind up hopping through a bunch of steps. Pretty sure in our org we just make our workflow "you can hop from any state to any other state"--basically a free-for-all. Dunno my point, but there you go!