I fucking hate Jira(ifuckinghatejira.com)
ifuckinghatejira.com
I fucking hate Jira
https://ifuckinghatejira.com/
537 comments
I can't help but wonder what PM tools Atlassian developers use. Surely it can't be JIRA? Maybe they have some browser extensions that make the interface less frustrating.
I assume they do use JIRA, hence the mess.
It's such a bloated mess that it's hard to point to a specific thing.
It’s like trying to describe why a McDonalds $1.99 burger is bad, to someone who just lists ingredients and insists it has just the same mayo, cheese & patty as a $12.99 burger does.
It’s not about any single feature being missing, it’s just terrible the same way Vista was terrible
It’s not about any single feature being missing, it’s just terrible the same way Vista was terrible
> I'd like a really easy way to see all of the tickets I've ever completed.
Can be solved by creating a custom person field called “Developer”. Then you can customize the Status transition for your In Progress status to automatically set that field to the current user or maybe the issue assignee.
For better or worse, Jira is quite powerful and flexible. But it’s not always simple to setup.
Can be solved by creating a custom person field called “Developer”. Then you can customize the Status transition for your In Progress status to automatically set that field to the current user or maybe the issue assignee.
For better or worse, Jira is quite powerful and flexible. But it’s not always simple to setup.
Everything turning into an edit action when I just want to click a link or copy a bit of text is super annoying! Also is thinking you're in a text field, typing out something and realizing you've done a whole bunch of random actions because of all the hotkeys.
The #1 thing I want out of every project management thingy I've used is the ability to have direct links to a ticket/issue or list of tickets/issues load as a basic HTML page, that's either read-only or uses a "save" button rather than persisting edits instantly. Provide a link to the full-fat version of the page, on the off chance I want that.
I just want tickets to load instantly (trivial, if you're not loading an "app" with it), not use hundreds of MB of memory and tons of background processor cycles (ditto) so I feel like I can't just leave it open, and not to have to worry I'll click in the wrong place or accidentally trigger some hotkey thing and screw something up.
Let the PMs have their version of the site with live-edited everything and janky (because Web) drag & drop galore and a whole universe of hotkeys and combos. I just want a fucking web page with the info I need.
I just want tickets to load instantly (trivial, if you're not loading an "app" with it), not use hundreds of MB of memory and tons of background processor cycles (ditto) so I feel like I can't just leave it open, and not to have to worry I'll click in the wrong place or accidentally trigger some hotkey thing and screw something up.
Let the PMs have their version of the site with live-edited everything and janky (because Web) drag & drop galore and a whole universe of hotkeys and combos. I just want a fucking web page with the info I need.
The hate is not for JIRA the tool, but JIRA the way of managing things.
No, the tool is shit too.
Yes, but also Jira the tool with it's horrendous UX, janky markdown (which is also different from Confluence's wtf), memory foortprint, slow loading, slow everything, controls moving from under your cursor just as you're about to click them...
Honestly, it's a horrendous piece of software however you look at it.
Honestly, it's a horrendous piece of software however you look at it.
This is true. I too would rejoice to see Jira die in a fire; but the fact is that if that happened, another tool would be used instead, and the same dysfunctional management processes would just re-emerge.
- For a while, we had tickets in done states that just roll over to the next epic, like they were still open. Nobody knew why, and it went away with nobody making any fixes to anything.
- For a while, the side pane when you open an issue would just be blank.
- Setting a ticket's epic makes me want to tear my eyeballs out. The button has the tiniest hitbox, the suggestion list is always wrong.
- Bulk operations are just a PITA
- the search box is always description. I'm almost always filtering on other criteria, and so, have to suffer a page load.
- and every page load is long and slow. Loading my backlog page is 186 requests, 4.4 MiB on the wire, and takes 9.4s. For one page.
- UIs that have drag & drop, but don't support simultaneous scroll are annoying. I have to wait for the view to move at JIRA's speed, which is ofc., slow.
- it encourages "sprints" and "agile", which in turn encourage "process" over just getting shit done.
- For a while, the side pane when you open an issue would just be blank.
- Setting a ticket's epic makes me want to tear my eyeballs out. The button has the tiniest hitbox, the suggestion list is always wrong.
- Bulk operations are just a PITA
- the search box is always description. I'm almost always filtering on other criteria, and so, have to suffer a page load.
- and every page load is long and slow. Loading my backlog page is 186 requests, 4.4 MiB on the wire, and takes 9.4s. For one page.
- UIs that have drag & drop, but don't support simultaneous scroll are annoying. I have to wait for the view to move at JIRA's speed, which is ofc., slow.
- it encourages "sprints" and "agile", which in turn encourage "process" over just getting shit done.
All valid criticisms, especially the slowness and heavy page sizes. Another perspective on 3 of your points though (and a free quality-of-life tip!)
> For a while, we had tickets in done states that just roll over to the next epic, like they were still open. Nobody knew why, and it went away with nobody making any fixes to anything.
I almost guarantee someone forgot to set the resolution field when creating a workflow transition, noticed and went back and fixed it.
> Bulk operations are just a PITA
Agreed that the UI is jank AF, but it works reliably on the order of tens of thousands of tickets at a time.
> UIs that have drag & drop, but don't support simultaneous scroll are annoying. I have to wait for the view to move at JIRA's speed, which is ofc., slow.
Almost every operation you want to do this for can also be done by right-clicking and “move to.” There’s “move to top of backlog”, “move to sprint x”, “move to top of column”, you can also ctrl/cmd click (or shift-click) to select multiple issues.
> For a while, we had tickets in done states that just roll over to the next epic, like they were still open. Nobody knew why, and it went away with nobody making any fixes to anything.
I almost guarantee someone forgot to set the resolution field when creating a workflow transition, noticed and went back and fixed it.
> Bulk operations are just a PITA
Agreed that the UI is jank AF, but it works reliably on the order of tens of thousands of tickets at a time.
> UIs that have drag & drop, but don't support simultaneous scroll are annoying. I have to wait for the view to move at JIRA's speed, which is ofc., slow.
Almost every operation you want to do this for can also be done by right-clicking and “move to.” There’s “move to top of backlog”, “move to sprint x”, “move to top of column”, you can also ctrl/cmd click (or shift-click) to select multiple issues.
> I'd also like to add that as a developer, once I finish my ticket I assign it to a QA. Then I can never get back to the ticket.
That's not JIRA, that's your organization's crappy workflow/customization. That's the problem... JIRA is a tool that encourages setting up elaborate yet dysfunctional workflows.
Regarding your actual problem, just create a tickets.txt in your home directory and store your list of completed JIRAs and whatever else is important to you there.
That's not JIRA, that's your organization's crappy workflow/customization. That's the problem... JIRA is a tool that encourages setting up elaborate yet dysfunctional workflows.
Regarding your actual problem, just create a tickets.txt in your home directory and store your list of completed JIRAs and whatever else is important to you there.
Jira has JQL (Jira Query Language) https://www.atlassian.com/blog/jira-software/jql-the-most-fl... you can search for a lot of different things, it is possible to construct queries for items you have touched in the past.
on edit: once you have a query you like save it as a personal filter and it will show up somewhere in the UI, because Jira sucks who knows where (changes all the time), but you can of course also make personalized dashboards and place the filters you have made on to that dashboard with a widget that runs the filter.
on second edit: evidently I earned someone's downvote by not being adequately anti-jira despite having put in that Jira sucks, but really the comment to which I'm replying ends with:
" I'd also like to add that as a developer, once I finish my ticket I assign it to a QA. Then I can never get back to the ticket. I'd like a really easy way to see all of the tickets I've ever completed. But completed tickets aren't assigned to me, they're assigned to QA. "
which, using JQL, is real easy.
on edit: once you have a query you like save it as a personal filter and it will show up somewhere in the UI, because Jira sucks who knows where (changes all the time), but you can of course also make personalized dashboards and place the filters you have made on to that dashboard with a widget that runs the filter.
on second edit: evidently I earned someone's downvote by not being adequately anti-jira despite having put in that Jira sucks, but really the comment to which I'm replying ends with:
" I'd also like to add that as a developer, once I finish my ticket I assign it to a QA. Then I can never get back to the ticket. I'd like a really easy way to see all of the tickets I've ever completed. But completed tickets aren't assigned to me, they're assigned to QA. "
which, using JQL, is real easy.
> I wish the comments were more specific about which features they don’t like.
I have a very specific complaint: the ease which all sorts of custom fields can be added for _everyone_. Sales will want to add a field to hold their contract status. Lo and behold, engineering now has it. It can be done in the proper way, but it seems that doing it at a global level is easier since that's how multiple Jira installations at multiple companies were configured.
All I want is a ticket, with a title, description, assignee, the current status, an easy way to transition, and comments. That's it. Let my project _opt out_ of any global customization if making global stuff is unavoidable.
Also, the newest Jira UX is... terrible. Tickets should not be THAT easy to edit. How often do we want to change a ticket's description, or title? I'd say, not often. If we do, there's really no harm in having an "edit" button. Old Jira versions had one.
I have a very specific complaint: the ease which all sorts of custom fields can be added for _everyone_. Sales will want to add a field to hold their contract status. Lo and behold, engineering now has it. It can be done in the proper way, but it seems that doing it at a global level is easier since that's how multiple Jira installations at multiple companies were configured.
All I want is a ticket, with a title, description, assignee, the current status, an easy way to transition, and comments. That's it. Let my project _opt out_ of any global customization if making global stuff is unavoidable.
Also, the newest Jira UX is... terrible. Tickets should not be THAT easy to edit. How often do we want to change a ticket's description, or title? I'd say, not often. If we do, there's really no harm in having an "edit" button. Old Jira versions had one.
I had a similar thought: Jira is very customizable; if people hate something that is so customizable then part of what they're hating is the organizations customization of it.
I've seen the same thing at multiple companies. Someone comes up with a Jira workflow, it doesn't match the needs of some people, but the company wants to standardize on that workflow, so now people are stuck using a stupid workflow that doesn't work for them. I've also seen a bunch of stupid custom fields on every single ticket. Is this Jira's fault or the organization's fault? You complain but the word from your immediate manager is that the team is already in hot water so escalating complaints about the Jira configuration isn't going to help, etc.
I've seen the same thing at multiple companies. Someone comes up with a Jira workflow, it doesn't match the needs of some people, but the company wants to standardize on that workflow, so now people are stuck using a stupid workflow that doesn't work for them. I've also seen a bunch of stupid custom fields on every single ticket. Is this Jira's fault or the organization's fault? You complain but the word from your immediate manager is that the team is already in hot water so escalating complaints about the Jira configuration isn't going to help, etc.
If only one organisation did that, it would be that organisation's fault. When every organisation using Jira does that, it's Jira's fault.
Why does everyone standardize on a company-wide workflow that the developers can't change with a bunch of stupid mandatory fields? Because that's what Jira nudges you to do. Workflow editing is for managers only, fields are mandatory by default...
Why does everyone standardize on a company-wide workflow that the developers can't change with a bunch of stupid mandatory fields? Because that's what Jira nudges you to do. Workflow editing is for managers only, fields are mandatory by default...
> Tickets should not be THAT easy to edit. How often do we want to change a ticket's description, or title? I'd say, not often. If we do, there's really no harm in having an "edit" button.
It's very useful for when the user submits a ticket with "My computer isn't working" as the title and "excel is broken" as the description.
It's very useful for when the user submits a ticket with "My computer isn't working" as the title and "excel is broken" as the description.
I'd not mind to press edit to change it.
Every time I'm highlighting and ctrl+c'ing something out of a ticket and it turns into edit mode, I tense up a little bit. Ugh.
What I hate about jira is it's flexibility.
The biggest issue I have with jira is it's so dead simple for braindead process zombies to cram another field, another label, another required text box, 4 new transition states, 20 difference confusing priorities, etc. Then, require everyone to follow through with this (with 90% of the time putting some form of "not applicable" in the boxes they added).
It is built for anal retentive "rule enforcers" to jump in and chastise you because you checked box 4a but didn't fill out sub box 3c.
FFS, I have an easier time filling out my taxes than some project's jira setups. (And I live in the US).
The biggest issue I have with jira is it's so dead simple for braindead process zombies to cram another field, another label, another required text box, 4 new transition states, 20 difference confusing priorities, etc. Then, require everyone to follow through with this (with 90% of the time putting some form of "not applicable" in the boxes they added).
It is built for anal retentive "rule enforcers" to jump in and chastise you because you checked box 4a but didn't fill out sub box 3c.
FFS, I have an easier time filling out my taxes than some project's jira setups. (And I live in the US).
Isn’t there problem the people cramming those things in?
We use jira as a way to track ongoing tasks, we use subject, description, comments/attachments, and assigned to.
We use jira as a way to track ongoing tasks, we use subject, description, comments/attachments, and assigned to.
> Isn’t there problem the people cramming those things in?
Yes.
However, the feedback loop for "that's a dumb mistake" both takes too long and is easily ignored.
Even with CRs, spaghetti code still gets written. There's no CR for a Jira workflow change. Further, the people making such changes are frequently unimpacted by them (or they like them because they are the aforementioned anal retentive process zombies)
Yes.
However, the feedback loop for "that's a dumb mistake" both takes too long and is easily ignored.
Even with CRs, spaghetti code still gets written. There's no CR for a Jira workflow change. Further, the people making such changes are frequently unimpacted by them (or they like them because they are the aforementioned anal retentive process zombies)
My organisation/team uses jira, we don’t do process, so the post is meaningless
The composer in general. I often have to intersperse log/code lines with prose, and there’s no telling what the Formatting menu will do. Some times selecting a formatting will apply to selected text, sometimes not. Sometimes it will apply when choosing a formatting then pasting text, some times not. Some times it seems to apply to a selection as well as everything after it. It does support Markdown with backticks for monospace, but that’s a lot of manual editing I would rather not do.
I also get annoyed at the subtle ways the top-level Issue composer is different from the comment composer, most frequently with the top-level composer’s refusal to allow image embedding/positioning. You can only add images to a new Issue as file attachments displayed as a row of tiny thumbnails under all the Issue text, so I will frequently create a mostly blank Issue and then write what I want to say as the first comment where I can embed images and talk about them inline.
In the interest of also saying something nice, I think it’s cute how the JIRA logo seems to be a Jera/“j” rune :)
https://wac-cdn.atlassian.com/dam/jcr:e348b562-4152-4cdc-8a5...
https://en.wikipedia.org/wiki/J%C4%93ran
I also get annoyed at the subtle ways the top-level Issue composer is different from the comment composer, most frequently with the top-level composer’s refusal to allow image embedding/positioning. You can only add images to a new Issue as file attachments displayed as a row of tiny thumbnails under all the Issue text, so I will frequently create a mostly blank Issue and then write what I want to say as the first comment where I can embed images and talk about them inline.
In the interest of also saying something nice, I think it’s cute how the JIRA logo seems to be a Jera/“j” rune :)
https://wac-cdn.atlassian.com/dam/jcr:e348b562-4152-4cdc-8a5...
https://en.wikipedia.org/wiki/J%C4%93ran
Not being able to embed images in comments sucks. It's not always clear which images people are talking about when they all get dumped in to the "attachments" section.
You can insert attached images into comments. It's in the menu of the "Visual" editing pane, or doable by inserting some magic [] or {} incantation in the "Text" pane. Sorry, I don't know it by heart. But you can do it visually first, then find and learn it by switching to the textual view. I do remember you can specify size by optional width and height parameters; without them, I think you get just a tiny thumbnail.
> Also it’s really annoying when I try to copy something from a ticket description but it starts editing the whole description field.
+1. Absolute garbage interface.
+1. Absolute garbage interface.
We are looking at switching vendors, but the fact that they EOL'ed the server version makes JIRA a non-starter for us.
https://www.atlassian.com/migration/assess/journey-to-cloud
https://www.atlassian.com/migration/assess/journey-to-cloud
How do I find an old story in Jira? *Without searching my email.
> For me a particularly frustrating aspect is the way the UI moves around a lot. I’m quite anxious to click anything until all the loading spinners have stopped in case I click the wrong thing. Then I could be taken to a page or feature I’ve never seen before.
This is a common antipattern that doesn't get talked about enough. It's very common in the era of interactive ads, websites with 3rd party web UIs layered on top, lazy loading, and just "rich" UIs in general. A user needs to be able to trust what they are about to click. This is fundamental.
This is a common antipattern that doesn't get talked about enough. It's very common in the era of interactive ads, websites with 3rd party web UIs layered on top, lazy loading, and just "rich" UIs in general. A user needs to be able to trust what they are about to click. This is fundamental.
The Vera functionality in Jira likes to move me ahead in a test sequence, so each time I touch something in a long test sequence I have to make sure I’m on the right test step.
Absolutely trash.
Absolutely trash.
This is something browsers should solve. If the thing you clicked on wasn't there 0.2s ago then you didn't intend to click on it, so just ignore the click. And add an API for twitch games to turn this off.
I'd probably support a page similar to the one used to warn you about certificate problems. "This page is using a user-hostile interface that may cause you to interact with unintended elements. Do you want to proceed?" But, you know, worded better.
I have a hard time finding out things I like.
I recall even wasting time ensuring that Jira recognized correctly that a PR was merged.
I recall even wasting time ensuring that Jira recognized correctly that a PR was merged.
I'm sometimes kind of surprised at how often I see people say they don't mind it. It's by far the tool I like the least out of everything I've used at any job I've ever been in.
I don't mind it. Maybe because I only peek into it about once per week or so, so we don't really drive daily work using it.
Same, I check into Jira once per day, max. It's useful to give an overview of what everyone is working on in the "Kanban" meetings twice weekly. I use quotes because we really don't follow any strict rules or structures, everyone just kind of does what needs to be done to keep things moving forward.
Maybe a couple times a day for me, but mostly if I somehow have two things going at once.
Meanwhile I’m battling Bamboo regularly, and I hate everyone who has ever worked on that crime against humanity.
Meanwhile I’m battling Bamboo regularly, and I hate everyone who has ever worked on that crime against humanity.
The UX is annoying as hell but I am almost never unable to do what I need to do. I can't say that for all SaaS tools.
It's quite easy to have a minimized exposure to jira as a developer. I hate its guts but if my interactions are limited to writing a few tickets and changing statuses then its awfulness is more somebody else's problem and it doesnt bother me nearly as much.
If it's set up properly, it's easy for developers to browse the tickets, log work on them, and update their status - and that's all they will need to do. So, from their perspective, it's fine. However, getting to that point is unnecessarily difficult, and if you fail, that difficulty spills over into the developer experience.
I would fight you about how Bamboo is the worst tool I’ve had to use, but since they’re both from Atlassian that feels a bit like splitting hairs.
It's a tool for the boring part of software engineering- I don't expect it to spark joy. I wish it were faster, scaled the full width of my monitor, allowed external editors, etc. Overall it gets the job done well. Everything else that I've used is horrible which makes it the best in my experience but that's still not saying much.
But what if it _did_ spark joy… https://linear.app/readme
We use Linear at my job too - it's very smooth and easy to use and certainly does spark joy
This looks really nice but it scares me to think of what my large (60,000+ employees) employer would do to it. Thanks for sharing though- I'm going to check this out.
I use linear and I hate it more than jira. It’s jira with all the useful production features removed, making it useless for large teams and qa teams. Beyond simple task tracking it has been a chore to use.
We use it at my current work and I'm not impressed. We even moved back some workflow steps to Notion because of lost work in the editor.
Frankly, I miss the limited GitHub PM tools we used at my previous job.
Even their one true limitation, no sub-issues, is very meh on Linear.
Frankly, I miss the limited GitHub PM tools we used at my previous job.
Even their one true limitation, no sub-issues, is very meh on Linear.
I looked it over, but the properties provided prevent us from organizing and prioritizing the tickets on things that matter to us. Doesn't look like we can add properties to issues.
So, if we have some kinda numerical metric, call it "foo", we can't ask linear to give us all foo's over 6.
So if we wanted to do any kinda metrics, basically, we have to export our whole project as CSV and do the calculations there? I just checked the export system. It exports everything only. I don't think this is tenable for project management.
I can see it work for a personal task list or a small team doing simple sprints. But... I wouldn't see it used beyond that.
Maybe I'm off base on all this, I did just give the product a quick once over. If I missed ways to make all this work, then that's on me.
So, if we have some kinda numerical metric, call it "foo", we can't ask linear to give us all foo's over 6.
So if we wanted to do any kinda metrics, basically, we have to export our whole project as CSV and do the calculations there? I just checked the export system. It exports everything only. I don't think this is tenable for project management.
I can see it work for a personal task list or a small team doing simple sprints. But... I wouldn't see it used beyond that.
Maybe I'm off base on all this, I did just give the product a quick once over. If I missed ways to make all this work, then that's on me.
There's lots of worse shit here: https://en.wikipedia.org/wiki/List_of_version-control_softwa.... I remember IBM ClearCase in particular as vile.
Only if you toss in multi-site for fun. :)
What tools do you like the most?
I only use Jira for defect tracking and not project planning. In that regard it seems to be only slightly worse than Github/Gitlab's issue tracking. It'd be kinda nice if it supported Markdown but it's not a big deal.
The only things I need it to do are: (1) record an archive of comments describing the progress on the issue's resolution, (2) be able to store attachments, (3) be able to cross-reference other issues. Maybe I have a really low bar? But it seems to do those without much problem and in my case it doesn't seem to be slow.
The only things I need it to do are: (1) record an archive of comments describing the progress on the issue's resolution, (2) be able to store attachments, (3) be able to cross-reference other issues. Maybe I have a really low bar? But it seems to do those without much problem and in my case it doesn't seem to be slow.
I don't love it, but I sure hate it less than just about everything that came before it.
I'd prefer any kanban board app over jira.
Jira is terrible until you try other tools for managing dev work.
Jira is the worst possible choice, except for all the others.
Yep. Jira is far from perfect, but I've not had any better luck with anything else.
I was honestly really pleased when we moved to Jira at a previous job, having lived through three other worse ticket systems. It’s just more powerful, and has ways of keeping tickets from falling into a black hole. None of that is an excuse for the slow, terrible frontend for Jira, or the complete lack of discoverability in Confluence.
Has anyone tried to use something like notion? Depending on your size you don't necessarily need all the stuff around it. Whats the difference between a story and an epoch? Most people don't really care. They just need something to track stuff being done, like a glorified to-do list with rich text.
Disclaimer: I work at Notion.
I think Notion works well for tasks if your organization is small, or you are happy with lightweight process. There is no way to ensure all updates to a Notion page follow a strict state machine like Jira. Notion just doesn’t have those kind of validation / restriction tools yet.
For our 100ish engineers it works well especially because planning docs flow seamlessly into project specs and then tasks… but we suffer a bit from loosely defined workflows around 2-week sprints that take more clicking than anyone wants.
I think Notion works well for tasks if your organization is small, or you are happy with lightweight process. There is no way to ensure all updates to a Notion page follow a strict state machine like Jira. Notion just doesn’t have those kind of validation / restriction tools yet.
For our 100ish engineers it works well especially because planning docs flow seamlessly into project specs and then tasks… but we suffer a bit from loosely defined workflows around 2-week sprints that take more clicking than anyone wants.
Shouldn't these tools be used primarily at the team level? Large organizations don't necessarily have larger teams. I'm not sure why it should make a big difference if you have 2 or 200 teams of 5 using the tool.
it makes a difference because frequently, when you have (say) several hundred teams of 10-15 people, they need to interoperate (so that the fields used, and the meanings of the fields, are standardized and have a structured lifecycle), and also they need to be able to roll up to larger progress reports/status updates so that the org leaders can understand where everything is. If all the small teams organically choose their own fields/meaning/process (which happens, all the time, everywhere, by default), you can end up with a tower of babel problem.
Under that kind of top-down structure, each team will force their organic processes into the Procrustean bed of what the project management system expects. Aggregating that data heedless of any variation in meaning will result in garbage. Leadership can't do anything with aggregate metrics derived from day-to-day development anyway. That results in fantasy metrics like "velocity". They should be focused on conditions and outcomes.
Have you tried Linear [0]?
----
[0] - https://linear.app/
----
[0] - https://linear.app/
[deleted]
I used to hate Jira, and then, I had to use Asana...
Wow, I like Asana much more than Jira. We're using Linear now, which I know is a favourite here, but I actually think Asana is pretty close in quality (better in some ways)
Yeah, I've yet to use something that doesn't make me sad and aggravated at the same time.
On my "hate" list: Jira, Asana, Zenhub &/or Github Issues, Trello.
On my "hate" list: Jira, Asana, Zenhub &/or Github Issues, Trello.
I like Jira because it hides the crap I don't want to do or think about in this thing called the backlog, which I can point to as a "see, it is something in the works but we don't have enough resources" thing, and then I can focus on the things I need/want to do by putting them in the Will Do Soon column.
I'll start complaining about JIRA when I find a reasonable alternative for my organization. Until then, I'm just glad we're not using IBM Rational ClearQuest anymore.
The two people who drove our company to Jira from other tools:
- One of them resigned soon after the migration.
- The other barely uses it today - in fact, he found other tools for his team because Jira is too cumbersome.
The rest of us are left holding the bag because "Jira is the industry standard".
- One of them resigned soon after the migration.
- The other barely uses it today - in fact, he found other tools for his team because Jira is too cumbersome.
The rest of us are left holding the bag because "Jira is the industry standard".
Struts was an industrial standard for longer than most things, and everyone hated using it for most of that time.
A quarter pounder with cheese is an industry standard too, but that doesn’t mean you should give it preferential treatment. Industry standards are often more like consolation prizes than a special experience.
A quarter pounder with cheese is an industry standard too, but that doesn’t mean you should give it preferential treatment. Industry standards are often more like consolation prizes than a special experience.
Reminds me of this classic piece of Internet lore: https://www.internetisshit.org
What are some alternatives to JIRA? Also, how much of the hate directed towards JIRA buried resentment towards Agile and other project management paradigms?
PivotalTracker, GitLab has pretty great project tracking and ticket management if you’re on them. These are the two I can think of off the top of my head. Personally I really like Pivotal.
Pivotal Tracker is only good if you buy into the way that it works and are willing to lose all knowledge that your tickets represent.
Pivotal is really only good at a particular type of project tracking (mostly building greenfield features and projects), and absolutely godawful at issue tracking.
I’ll use JIRA over Pivotal any day.
Pivotal is really only good at a particular type of project tracking (mostly building greenfield features and projects), and absolutely godawful at issue tracking.
I’ll use JIRA over Pivotal any day.
Pivotal was just a normal board based tracker when I used it. Better than Trello and less complex than Jira which is all I really want, I’ve never been in an organization that has any more context attached to a ticket than what the work is and who’s working on it.
I think I can count on my hand the number of times anyone has actually had a conversation on a Jira ticket for me.
It also helps that right now I don’t have tickets for my work, I’ve been lucky enough to work on exploratory/skunkworks work for my team at my current org.
I think I can count on my hand the number of times anyone has actually had a conversation on a Jira ticket for me.
It also helps that right now I don’t have tickets for my work, I’ve been lucky enough to work on exploratory/skunkworks work for my team at my current org.
I like shortcut and use it whenever I have a say in the matter.
https://shortcut.com/
https://shortcut.com/
Slightly more than a +1, the team I work on switched to Shortcut and the quality of our tickets went up, more tickets were resolved, and fewer ended up lingering in backlog hell. Why? I'm sure there are many possible reasons, but the results stand on their own.
There was no directive other than "Ok, we're going to use this tool for now". Everything was self-organized within the bounds of the business/stakeholder goals.
I'm sure you can use either Jira or Shortcut in a manner which makes either tedious, but at face value we found significant improvements simply through adopting Shortcut.
There was no directive other than "Ok, we're going to use this tool for now". Everything was self-organized within the bounds of the business/stakeholder goals.
I'm sure you can use either Jira or Shortcut in a manner which makes either tedious, but at face value we found significant improvements simply through adopting Shortcut.
Shortcut is pretty stripped down and lacks several features conducive to cross team collaboration. In particular I dislike shortcut's lack of internal comments. It's a much bigger annoyance than anticipated.
I dislike atlassian products in general, but having some discipline with the config/workflows was much better than shortcut.
I dislike atlassian products in general, but having some discipline with the config/workflows was much better than shortcut.
> lack of internal comments
What do you mean by this? There's a section to comment in each card/epic/milestone and you can ping team members. Comments also sync with slack so you can get notifications there if you'd like. I don't have a ton of JIRA knowledge, so there's a chance I'm missing something.
What do you mean by this? There's a section to comment in each card/epic/milestone and you can ping team members. Comments also sync with slack so you can get notifications there if you'd like. I don't have a ton of JIRA knowledge, so there's a chance I'm missing something.
In Jira you have the concept of internal comments, which aren't visible to people outside the team.
They are useful for putting triage and debugging information in. Or even as a play by play with specifics so your team mates or manager can follow along with your progress.
They are useful for putting triage and debugging information in. Or even as a play by play with specifics so your team mates or manager can follow along with your progress.
Linear.app
Depending on what you use it for, Gitlab springs to mind
Linear https://linear.app/
It's a joy to use
It's a joy to use
Backlog by Nulab is pretty much all the good features of Jira distilled down into a simple product. I've used it and been very happy with it.
https://nulab.com/products/backlog/
>Agile
>resentment
Yup.. at least fake agile... where every "sprint" is the same length and features aren't customer-oriented.
Yup.. at least fake agile... where every "sprint" is the same length and features aren't customer-oriented.
Shameless plug for Constructor[1], we're early (new website on the way) but have a bunch of happy customers, many of whom came from Jira, the rest mostly from Trello (to which we're most often and justifiably compared, we keep it simple!)
1. https://constructor.dev
1. https://constructor.dev
Highly recommend ClickUp
For something less task-focused and more customer-oriented, we built https://www.kitemaker.co :)
I had no issues using YouTrack from JetBrains. It's fairly lightweight w/ a focus on ticketing (MarkDown + images), good search, and Kanban views, if that's your thing.
https://www.jetbrains.com/youtrack/
https://www.jetbrains.com/youtrack/
If self hosted is your thing I like taiga for kanban integrated with gogs for the issue tracking/VCS integration side of things. Didn't take me more than a day to get working and everyone signed up on it, isn't a lot of maintenance, just works, costs nothing.
We switched to Quire (https://quire.io) - it has a generous free plan, it's simple yet very flexible, and, most importantly for us, quick enough to not be a chore to update (Jira was horrible). Some small UI bugs here and there, but inconsequential.
> Also, how much of the hate directed towards JIRA buried resentment towards Agile
it is kind ironic, yet pretty typical and very telling, that the slow as hell Jira is tightly associated with Agile
it is kind ironic, yet pretty typical and very telling, that the slow as hell Jira is tightly associated with Agile
For more lightweight task and project management with an notes editor and outliner feel, try Taskade [0]
----
[0] - https://taskade.com/
----
[0] - https://taskade.com/
The real problem with Jira is that every company adopts it without sufficient support. It needs dedicated admins. You can't just let every single team YOLO things.
Unfortunately, what happens is a company adopts it from the start, and then it grows into an impossible-to-use forest where there's no meaningful way to bring things back to actually usable, and everyone is miserable.
Unfortunately, what happens is a company adopts it from the start, and then it grows into an impossible-to-use forest where there's no meaningful way to bring things back to actually usable, and everyone is miserable.
If a tool needs this level of support it's not a good tool and not even a tool - it's the no-code equivalent of a framework.
I'd rather pick any other ticketing system which has things done in one way than waste my life configuring jira
I'd rather pick any other ticketing system which has things done in one way than waste my life configuring jira
Just about every enterprise tool requires a proper implementation and system admins and business process analysis and change management to get setup.
A lot of enterprise tools are "crap, why would the company ever use this", and 90% of that is in the implementation (or lack thereof)
A lot of enterprise tools are "crap, why would the company ever use this", and 90% of that is in the implementation (or lack thereof)
Yep! It also comes down to a difference between the people the tool is primarily targeted at, and who actually has to interact with it. Salesforce's CRM (and its various sub-products) is very similar.
This is an inane take. Almost every system we use in a business requires support, and management to be used effectively. You wouldn't fire the people responsible for maintaining your other services.
You can either have something incredibly powerful, like Jira, with a lot of sharp edges, or you can use something incredibly similar. The latter would be more like 'no-code' since it's going to be drastically limited in terms of adapting to how your business does work, versus Jira which can be transformed into just about anything.
That 'just about anything' is the root of the problem, since over years a business will let dozens of people alter configurations and do special little bespoke things on their projects until it's unsustainable.
You can either have something incredibly powerful, like Jira, with a lot of sharp edges, or you can use something incredibly similar. The latter would be more like 'no-code' since it's going to be drastically limited in terms of adapting to how your business does work, versus Jira which can be transformed into just about anything.
That 'just about anything' is the root of the problem, since over years a business will let dozens of people alter configurations and do special little bespoke things on their projects until it's unsustainable.
> You can either have something incredibly powerful, like Jira, with a lot of sharp edges...
It's powerful. But I think a bunch of the dislike is because the edges are not sharp. They're very dull. That's why it's so clumsy to use. (Sure, it's still easy to cause damage, but that's not the same thing...)
Disclaimer: I have never actually had to use Jira. This is just my impression from listening to others complain.
It's powerful. But I think a bunch of the dislike is because the edges are not sharp. They're very dull. That's why it's so clumsy to use. (Sure, it's still easy to cause damage, but that's not the same thing...)
Disclaimer: I have never actually had to use Jira. This is just my impression from listening to others complain.
The point of something being sharp is doing damage with minimal effort, which I think fits here! Though, I won't disagree that a lot of parts of the Jira UX are more blunt-force.
Dedicated admins make it even worse, because they have the bandwidth and inclination to do all kinds of crazy customization, which is what takes jira from merely bad to terrible. The worst jira instances I've ever seen are the ones that had full-time people customizing them.
You've clearly not worked in places where it's people part-time customizing them, because I guarantee the outcome is worse!
You are both right! What you really want is a place that doesn't customize Jira at all, and if you find such a place you'll find out that they eventually switched to something else because everyone also hates Jira's default out of the box behaviors.
I don't know, because the part-time customizers are scratching some itch. Maybe they are messing up because they don't know any better.
The full time customizers need to justify their salary.
The full time customizers need to justify their salary.
Even with zero customization, just using it for a Kanban board is incredibly slow and frustrating. My 2-person team was using the free version of Target Process and needed to migrate to something else since we hit the entity limit, so we went with Jira because it seemed like the industry standard. What we got was the slowest initial page load and slowest interactions of any webapp I've ever used.
After struggling along for 2-3 months, we moved over to Clubhouse (now called Shortcut) and the difference in speed and overall experience is night and day.
After struggling along for 2-3 months, we moved over to Clubhouse (now called Shortcut) and the difference in speed and overall experience is night and day.
I honestly can't imagine trying to hire someone for such a terrible job.
Ripe for disruption.
I've seen absolutely ridiculous workflows on Jira. Things like - "i'm gonna make the most ridiculous workflow out of spite and boredom just to troll you."
From that perspective it's easy to hate it, but you hate the actual use of the tool not the tool itself.
Currently i enjoy more sane use of it. Simple workflow. You get in, read the ticket, clicky a button, get out. Slowness in that regard is very tolerable.
From that perspective it's easy to hate it, but you hate the actual use of the tool not the tool itself.
Currently i enjoy more sane use of it. Simple workflow. You get in, read the ticket, clicky a button, get out. Slowness in that regard is very tolerable.
Wait till you hear about servicenow
Single letter hotkeys are pretty bad. If it's not an input field you've focused but the page itself, you might assign the ticket to yourself and set it to some crazy state before you realize the focus is all wrong. Ask me how I know...
I do believe I managed to disable those in preferences or similar
I came from Apple (and their excellent Radar issue tracking tool) to a company that uses Jira.
Jira is the worst. I routinely lose data in jira, like saving errors. Dragging and dropping attachments sometimes causes the page to crash and reload. Everything in the UI moves around or obscured behind some tabs. I want to be able to file a network of issues all at once, something Radar did great. Jira workflows are much to complicated, and their flexibility just increases your administrative hell. I can go on and on.
Jira is the worst. I routinely lose data in jira, like saving errors. Dragging and dropping attachments sometimes causes the page to crash and reload. Everything in the UI moves around or obscured behind some tabs. I want to be able to file a network of issues all at once, something Radar did great. Jira workflows are much to complicated, and their flexibility just increases your administrative hell. I can go on and on.
Also ex-Apple here. Radar does suffer (to a lesser extent than Jira) from a profound defect, though: Searches are "exact match" for whatever text you put in the title. To find a bug YOU filed, you have to remember the exact words and sequence you used in the title. Did I say "resize window" or "resize a window?"
I filed a bug against Radar for this behavior, and developers from other teams added comments expressing surprise that the tool was crippled in this manner. I think a year later, someone said, "Yep, our team got bit by this today again. We assumed this was fixed years ago."
This fundamental flaw may explain why some widely-encountered bugs in Apple products don't get fixed, or at least fixed in a timely manner. A dozen Radars could be filed for the same defect, but if they aren't phrased the same way you'll never find all the dupes. So dumb.
Still... I could construct queries based on status and product more easily in Radar than in Jira.
I filed a bug against Radar for this behavior, and developers from other teams added comments expressing surprise that the tool was crippled in this manner. I think a year later, someone said, "Yep, our team got bit by this today again. We assumed this was fixed years ago."
This fundamental flaw may explain why some widely-encountered bugs in Apple products don't get fixed, or at least fixed in a timely manner. A dozen Radars could be filed for the same defect, but if they aren't phrased the same way you'll never find all the dupes. So dumb.
Still... I could construct queries based on status and product more easily in Radar than in Jira.
Well it's obvious then. Apple needs to create a new and bespoke issue tracker just for radar.
Or you need a “Queen’s English” standard way of describing everything enforced to all users.
That seems weird... is it too hard to feed everything into an Elasticsearch index? Even with default settings and some decent hardware you'd get good stemming and relevance ranking pretty easily.
No idea. You could type SQL into searches, but then you had to go somewhere (no idea where) and look up the tables or entities to query. I mean... really?
I'm curious what other people's thoughts are when comparing CA Agile Central (formerly known as Rally) to Jira. Which do you like more and why?
Jira is bloated. Full stop.
It feels like there isn't a strong unified product vision for Jira. It's just trying to solve everything. It's all "just configurable." That likely is a selling point into Enterprises who need some level of flexibility.
But for a lot of situations, people just want something that works well out of the box.
I often wonder what the 37signals guys would do if they ever decided to tackle this problem. They don't always hit the mark, but I give them a lot of credit for self-curating and having a strong product vision for what they ship.
It feels like there isn't a strong unified product vision for Jira. It's just trying to solve everything. It's all "just configurable." That likely is a selling point into Enterprises who need some level of flexibility.
But for a lot of situations, people just want something that works well out of the box.
I often wonder what the 37signals guys would do if they ever decided to tackle this problem. They don't always hit the mark, but I give them a lot of credit for self-curating and having a strong product vision for what they ship.
Isn't that what Basecamp from 37signals is meant to be? Perhaps I'm missing something as I've only used it a bit.
Once a JIRA shop, we moved everything to Asana years ago, after trying literally everything else. Our design team just could not get on board with JIRA. It was too much "work", in their words, to track their efforts.
Asana seems to be a good balance between the depth of data developers want to track and the high-level task management every other team wants.
Asana seems to be a good balance between the depth of data developers want to track and the high-level task management every other team wants.
I fucking do not hate Jira. Cause I do not use it.
Ok, it's slow, and navigation sucks, and lots of other things. Workflows are easy to get out of hand, but as long as you keep your workflows lean/tame/flexible, it's mostly "good enough". I suspect a sizable portion of the "Jira sucks" crowd are under the thumb of a maniacal administrator creating intense workflows.
That said, which competitor has a visual workflow editor, to which I can add custom statuses/transitions, which are applied based on various conditions/validations? And custom screen/field configurations? And custom resolutions? And time tracking? And apply security/permission schemes across all these things?
I get it, Jira sucks, I agree, but what's the go-to competitor?
That said, which competitor has a visual workflow editor, to which I can add custom statuses/transitions, which are applied based on various conditions/validations? And custom screen/field configurations? And custom resolutions? And time tracking? And apply security/permission schemes across all these things?
I get it, Jira sucks, I agree, but what's the go-to competitor?
Linear is much nicer. Very quick issue entry and very nice looking sprint summary/status and roadmap tabs. It's everything I want. Most importantly, it's fast. I work with issues a lot, so a slow tool like jira just isn't acceptable.
Jira exists to check every checkbox so you feel serious remorse if you pick anything else, but in terms of day-to-day productivity, it doesn't do too well. "Nice to look at" and "Fast" aren't checkbox items for managers. They're eventual problems for someone to solve when they notice engineers never touch the bug tracker.
At my current org, my advice to use Linear was overruled in favor of jira, and I'm pretty sure I'm the only engineer that regularly touches jira.
(I intentionally write "jira" in all lowercase because I like to call it JIRA, but jira's built-in text editor unconfigurably autocorrects "JIRA" to "Jira". That's the feature they spent engineering time on? Fuck them.)
Jira exists to check every checkbox so you feel serious remorse if you pick anything else, but in terms of day-to-day productivity, it doesn't do too well. "Nice to look at" and "Fast" aren't checkbox items for managers. They're eventual problems for someone to solve when they notice engineers never touch the bug tracker.
At my current org, my advice to use Linear was overruled in favor of jira, and I'm pretty sure I'm the only engineer that regularly touches jira.
(I intentionally write "jira" in all lowercase because I like to call it JIRA, but jira's built-in text editor unconfigurably autocorrects "JIRA" to "Jira". That's the feature they spent engineering time on? Fuck them.)
I looked at Linear and it's very software-specific. The features page says it's "the new standard for modern software development".
I do use Jira for software, but also for generic state tracking of non-software processes. E.g. some projects have no use for sprints, or code integration, or user stories.
I do use Jira for software, but also for generic state tracking of non-software processes. E.g. some projects have no use for sprints, or code integration, or user stories.
It's aimed for software teams, but there are also non-software teams using it.
Sprints (cycles) are turned off by default, similarly many other features can be enabled or left off if you don't need them.
Code integration is also not really visible unless you integrate and use it.
Sprints (cycles) are turned off by default, similarly many other features can be enabled or left off if you don't need them.
Code integration is also not really visible unless you integrate and use it.
> I get it, Jira sucks, I agree, but what's the go-to competitor?
You started to ask hard questions but you hit nail on the head.
Jira is bad because it's slow and doesn't telepathically adjust itself to everyone's needs.
Perhaps the author can buy ifuckinglovejiragotocompetitor.com to provide us with the answer.
You started to ask hard questions but you hit nail on the head.
Jira is bad because it's slow and doesn't telepathically adjust itself to everyone's needs.
Perhaps the author can buy ifuckinglovejiragotocompetitor.com to provide us with the answer.
An ad-hoc Excel sheet coded by an anal retentive management assistant to show em all ;)
I feel like hating on Jira is the pastime that is now passed down from each generation of programmers to the next.
I'm going to stick up for Jira. I certainly don't "love" Jira, though I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now).
The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve. It's always taken on from the position of "well, it didn't make my specific use case easy", but never with an appreciation with some of the complexity that Jira needs to solve for other users at your company, never mind other companies.
Obviously some of the complaints (speed, stability) are very valid, but here's a question I think is just as valid: why don't you think some other company has come along and toppled the Jira crown? Certainly tons of them have tried, and while many have their supporters, they are almost equally likely to have their detractors.
The fact is, building a generic project management and tracking tool is a really difficult, hard problem. In my old age as a programmer I feel like Jira is kind of like our form of government: "Jira is the worst project management tool, except for all the others".
I'm going to stick up for Jira. I certainly don't "love" Jira, though I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now).
The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve. It's always taken on from the position of "well, it didn't make my specific use case easy", but never with an appreciation with some of the complexity that Jira needs to solve for other users at your company, never mind other companies.
Obviously some of the complaints (speed, stability) are very valid, but here's a question I think is just as valid: why don't you think some other company has come along and toppled the Jira crown? Certainly tons of them have tried, and while many have their supporters, they are almost equally likely to have their detractors.
The fact is, building a generic project management and tracking tool is a really difficult, hard problem. In my old age as a programmer I feel like Jira is kind of like our form of government: "Jira is the worst project management tool, except for all the others".
I totally disagree with you, but I upvoted you for making me think about it differently.
I couldn't agree with this more. What people hate is not Jira but the organisational thinking that it facilitates. I've used jira in other contexts and it's been mostly a joy because the processes it modelled were happily simple.
> why don't you think some other company has come along and toppled the Jira crown?
I really wish Jetbrains Spaces was around when the organization I work for was doing the "everyone under one umbrella" migration.
Prior to Jira, we had one team using GitLab issues, one team using Redmine, one team using Borland Star (with a tight limit on licenses), and one team using Excel.
I personally would have gone with Redmine over Jira... however that also would have tied me to doing a lot more setup work, upgrades, and care and feeding of the system compared to the relatively turn key setup of Jira.
I really wish Jetbrains Spaces was around when the organization I work for was doing the "everyone under one umbrella" migration.
Prior to Jira, we had one team using GitLab issues, one team using Redmine, one team using Borland Star (with a tight limit on licenses), and one team using Excel.
I personally would have gone with Redmine over Jira... however that also would have tied me to doing a lot more setup work, upgrades, and care and feeding of the system compared to the relatively turn key setup of Jira.
> why don't you think some other company has come along and toppled the Jira crown?
Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works.
I don't buy that it's a matter of competitors not being better. It is more about inertia.
The argument you have here could equally be applied to C++ or Cobol "Why is new code being written in these languages? Why is C++ so popular even when there are many other competitors? Certainly tons of languages have tried."
I currently work in a field that is disrupting existing products that were, no joke, written in the 90s in VB6. It can be super hard to sell our product to a lot of people, not because our product isn't better, but because they've been using our VB6 competitor since the 90s.
Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works.
I don't buy that it's a matter of competitors not being better. It is more about inertia.
The argument you have here could equally be applied to C++ or Cobol "Why is new code being written in these languages? Why is C++ so popular even when there are many other competitors? Certainly tons of languages have tried."
I currently work in a field that is disrupting existing products that were, no joke, written in the 90s in VB6. It can be super hard to sell our product to a lot of people, not because our product isn't better, but because they've been using our VB6 competitor since the 90s.
I disagree with this. Absolutely, once Jira (or any particular project management tool) gets it's "tentacles" into a sizable enterprise, it's very difficult to dislodge.
But I've seen tons of other examples in my career of companies making larger, more difficult transitions because they clearly felt the risk/benefit was worth it: moving from CVS/Subversion to git, moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres, yada yada yada.
I'm certainly not saying it's easy, but I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira", that many companies would make the switch. This hasn't happened, and honestly if you hear people complain about Fogbugz or Asana or whatever that it's probably an equal "per-capita" bitch rate.
But I've seen tons of other examples in my career of companies making larger, more difficult transitions because they clearly felt the risk/benefit was worth it: moving from CVS/Subversion to git, moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres, yada yada yada.
I'm certainly not saying it's easy, but I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira", that many companies would make the switch. This hasn't happened, and honestly if you hear people complain about Fogbugz or Asana or whatever that it's probably an equal "per-capita" bitch rate.
I think it's maybe a bit of both? I worked at an org that was using Trac for most things. It's probably fine for a small, engineering-driven company, but it's not very full-featured and isn't great for PMs and other business types.
So once the company got large enough, management wanted to switch. Many of us essentially said, "ok, that's fine, but please please please not Jira". And yet, they went and hired some consultants who were like "oh, Jira is the industry standard for your line of work, you'd be taking on a huge risk not using it, blah blah blah". Management bought it, and they've been on Jira ever since.
So once the company got large enough, management wanted to switch. Many of us essentially said, "ok, that's fine, but please please please not Jira". And yet, they went and hired some consultants who were like "oh, Jira is the industry standard for your line of work, you'd be taking on a huge risk not using it, blah blah blah". Management bought it, and they've been on Jira ever since.
If you said "please please please not Jira", what other options did y'all suggest that you thought would be better?
> moving from CVS/Subversion to git
Was that really painful? We did that transition and it amounted to having teams one by one run the "git-svn" script on their repos to port over to git. Even with over a million commits on our central SVN server, the whole process generally took around 5 minutes per project. Even in the worst cases, it was something like 1 hour.
The most painful part we had was putting a rate limiter in place to keep our SVN server from toppling over.
> moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres
These are certainly all more difficult but also things that aren't central to the way the company operates AND can be done a piece at a time. Moving from Jira->something else can't really be done in a piecemeal fashion.
The other big problem here is Jira has a wider audience than just the dev department. Dev saying "Let's go from svn to git" is something that doesn't hardly need involvement from the C levels. They never (usually) touch or look at the VCS interface. In fact, the only thing you listed that I think would be a hard sell to C levels is switching from windows to mac. Though, I suspect a lot of them are using macs anyways. Try getting your C levels to agree to switch from mac or windows to linux and I bet that'd never fly in any organization.
> I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira"
I just disagree. The best counter example is Internet Explorer. Both Firefox and Chromium have been better than IE for a long time (10->15 years). So why didn't every corporation switch to Firefox? Why did Chrome end up winning for desktop web browser even though it came so much later (2008)?
The answer is simple, chrome advertised on media that stakeholders watched.
Chrome eventually won, but it got there through deep pockets and advertising. If there's anything that will topple atlassian, it will have to be through the same route. That product/product set has to be better AND they have to spend a lot of capital advertising so that other shareholders find out they exist. Without doing both those things, toppling atlassian will be a long nearly impossible slog.
Was that really painful? We did that transition and it amounted to having teams one by one run the "git-svn" script on their repos to port over to git. Even with over a million commits on our central SVN server, the whole process generally took around 5 minutes per project. Even in the worst cases, it was something like 1 hour.
The most painful part we had was putting a rate limiter in place to keep our SVN server from toppling over.
> moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres
These are certainly all more difficult but also things that aren't central to the way the company operates AND can be done a piece at a time. Moving from Jira->something else can't really be done in a piecemeal fashion.
The other big problem here is Jira has a wider audience than just the dev department. Dev saying "Let's go from svn to git" is something that doesn't hardly need involvement from the C levels. They never (usually) touch or look at the VCS interface. In fact, the only thing you listed that I think would be a hard sell to C levels is switching from windows to mac. Though, I suspect a lot of them are using macs anyways. Try getting your C levels to agree to switch from mac or windows to linux and I bet that'd never fly in any organization.
> I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira"
I just disagree. The best counter example is Internet Explorer. Both Firefox and Chromium have been better than IE for a long time (10->15 years). So why didn't every corporation switch to Firefox? Why did Chrome end up winning for desktop web browser even though it came so much later (2008)?
The answer is simple, chrome advertised on media that stakeholders watched.
Chrome eventually won, but it got there through deep pockets and advertising. If there's anything that will topple atlassian, it will have to be through the same route. That product/product set has to be better AND they have to spend a lot of capital advertising so that other shareholders find out they exist. Without doing both those things, toppling atlassian will be a long nearly impossible slog.
It depends upon how SVN is used, and for the team I'm on, it's going to be painful. SVN allows you to checkout a subdirectory of any given repository, and because of our history, we have everything my team writes (10 programs) in two repositories, with a lot of sharing between the two repos. This is something that is ... not easy ... to replicate with git [1].
As far as Macs go, the company I worked for was 50/50 Mac/Windows, with the majority (if not outright all) of the developers using Macs. We got bought out, and our new corporate overlords were purely Windows, and didn't know what to do about our Macs. Personally, I ended up with a fully manged Windows laptop that I never used [2] for three years before I could send it back and send me a "semi-managed" Mac laptop.
As for Jira, eh. I didn't mind it that much, except when management mandated that every team use the same queue for everything. That queue didn't match our preferred method of working, so we kept our old queue purely for internal stuff. Our time tracking system is way worse than Jira by far.
[1] Not to say I love SVN---I hate it actually, and would prefer to use git. But having used SVN for over a decade on these two repos, and given their structure, it's going to be interesting.
[2] Except to turn it on to have it autoupdate when I got "the email". What a colossal waste of resources. My team kept on using the Macs.
As far as Macs go, the company I worked for was 50/50 Mac/Windows, with the majority (if not outright all) of the developers using Macs. We got bought out, and our new corporate overlords were purely Windows, and didn't know what to do about our Macs. Personally, I ended up with a fully manged Windows laptop that I never used [2] for three years before I could send it back and send me a "semi-managed" Mac laptop.
As for Jira, eh. I didn't mind it that much, except when management mandated that every team use the same queue for everything. That queue didn't match our preferred method of working, so we kept our old queue purely for internal stuff. Our time tracking system is way worse than Jira by far.
[1] Not to say I love SVN---I hate it actually, and would prefer to use git. But having used SVN for over a decade on these two repos, and given their structure, it's going to be interesting.
[2] Except to turn it on to have it autoupdate when I got "the email". What a colossal waste of resources. My team kept on using the Macs.
>Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works.
eh. I've experienced a number of painful tool and platform shifts in my career that basically came down to "it's cheaper" so I don't buy that companies are unwilling. If someone provides the feature set that is some combination of cheaper and better, then the only thing you really need is a migration path (Jira import tool in this case), and you'll be able to make some sales. Make enough sales and you start looking popular and that can provide its own inertia. The fact that this has not happened is, to me, evidence that nobody has done it better so far.
eh. I've experienced a number of painful tool and platform shifts in my career that basically came down to "it's cheaper" so I don't buy that companies are unwilling. If someone provides the feature set that is some combination of cheaper and better, then the only thing you really need is a migration path (Jira import tool in this case), and you'll be able to make some sales. Make enough sales and you start looking popular and that can provide its own inertia. The fact that this has not happened is, to me, evidence that nobody has done it better so far.
> Jira import tool
This is the problem. Jira is so highly configurable that without recreating a good chuck of the Jira feature set, an "import" tool will be pretty hard to make.
Any competitor in this marketspace will have to invest a considerable amount of their time creating and maintaining such a tool, which I imagine if they ever became a serious contender, Atlassian would put up some anti-competitive road blocks. (For example, forcing everyone into their cloud offering so they can more easily control endpoint access....)
This is the problem. Jira is so highly configurable that without recreating a good chuck of the Jira feature set, an "import" tool will be pretty hard to make.
Any competitor in this marketspace will have to invest a considerable amount of their time creating and maintaining such a tool, which I imagine if they ever became a serious contender, Atlassian would put up some anti-competitive road blocks. (For example, forcing everyone into their cloud offering so they can more easily control endpoint access....)
I'll note that most other competitors that are engineer (rather than management) focused don't use a jira workflow approach and instead tend to be more of an adhoc "apply labels" and "we trust you to apply the correct labels".
The Jira complex state table tends to be something that isn't replicated as its part of the "we're not Jira" value proposition.
The Jira complex state table tends to be something that isn't replicated as its part of the "we're not Jira" value proposition.
I don't disagree, but just to point out the issue with transitioning, even in a basic sense, is that Jira allows and can invisibly create new states for pretty critical pieces.
Your case might be in a "Closed" state on the UX, but internally that can be "custom state 48083232" because some wingus decided to first start by naming it "to be closed" and then changed it to just "Closed". That can be different for every project.
This is why an import tool is a complex thing to figure out. You have to translate all the potential custom states into the "we're not Jira"'s states that make sense.
Your case might be in a "Closed" state on the UX, but internally that can be "custom state 48083232" because some wingus decided to first start by naming it "to be closed" and then changed it to just "Closed". That can be different for every project.
This is why an import tool is a complex thing to figure out. You have to translate all the potential custom states into the "we're not Jira"'s states that make sense.
Yea... I wrote a redmine to Jira importer. That was... interesting. I'm familiar with Redmine and its table structure. I was able to reverse engineer the json schemas (there are examples at https://support.atlassian.com/jira-cloud-administration/docs... but little in the way of actual schemas and DTOs to work from) and successfully imported everything including a number of custom fields in Redmine and comments and attachments.
The only "oops" part of the Great Import was that the users that were in Redmine but not in Jira (people who left the org and thus were never imported into Jira) had entries created as the sysadmin who ran the import.
The only "oops" part of the Great Import was that the users that were in Redmine but not in Jira (people who left the org and thus were never imported into Jira) had entries created as the sysadmin who ran the import.
You mean as hard as when Git obliterated every other VCS within the span of a few years? If products are better, they get adopted. How do you think every single company in the world started to develop for iOS between 2008 and 2010? When the upside is obvious and the path to transition is well-defined, there is very little friction.
I still don't understand how git won the source control battle so decisively. I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops.
JIRA I can take or leave, it does the job - it's hard to imagine anyone being driven to hate it, but I can believe having it badly configured would be a serious drain on productivity.
I can only speak to the comparison with hg, but for large repos, git's performance is literally 10x better in our case (we have two parallel copies, one in hg and one in git, so as to smooth the transition to git). hg seems more usable, but certain decisions are poor (e.g. baking the branch name into each commit); overall I have no strong preference between the two except for the speed.
But the speed pretty much drowns out any other signal.
But the speed pretty much drowns out any other signal.
git's performance increase came around at the right time, too. Code bases were becoming bigger and bigger, and Agile's popularity preached a lot of branching. SVN branches were a full copy, making things way worse.
Yeah that had occurred to me. But I'd used TFS (which didn't have light-weight branches) with Agile-like development practices and it wasn't that big a deal. Maybe if the codebase was 10 or 20 times bigger it would've been.
Migration was easy, it was decentralised, had a famous original author & a huge famous project using it and had a lot of "hip" source code platforms such as github, gitorious, bitbucket (pre-atlassian) and gitlab.
I'm not surprised it won tbh.
Game companies are still using Perforce though.
I'm not surprised it won tbh.
Game companies are still using Perforce though.
> I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops.
At this point git is the incumbent, which is self-sustaining: developers already know git, so you'd need a really compelling reason to use anything else and take on the burden of training your developers to use it.
It helps that git is freely available and is by far the top choice for Free and Open Source projects.
Of course, SVN used to be in the same position, but git is such a great improvement that it was able to win out. I imagine git's origins in Linux kernel development may also have been a factor in its early success.
At this point git is the incumbent, which is self-sustaining: developers already know git, so you'd need a really compelling reason to use anything else and take on the burden of training your developers to use it.
It helps that git is freely available and is by far the top choice for Free and Open Source projects.
Of course, SVN used to be in the same position, but git is such a great improvement that it was able to win out. I imagine git's origins in Linux kernel development may also have been a factor in its early success.
> You mean as hard as when Git obliterated every other VCS within the span of a few years
There's not a concept impedance mismatch going from CVS->SVN->GIT. The concepts are so similar that git-svn exists to convert a SVN repo into a git repo (and a similar conversion tool exists for CVS->SVN)
Jira is so flexible and configurable that no such tool could exist. Migrating to a new tracking system requires that you either lose all currently tracked issues and their history OR you spend the money and effort handcrafting for your org a Jira->Foo translator to preserve some semblance of history. The larger and more diverse the org, the harder such a tool will be to craft.
> How do you think every single company in the world started to develop for iOS between 2008 and 2010?
Because ignoring a company that commands 30% of the market is a bad idea? How do you explain the flop of WebOS which was, IMO, a far better UX and OS compared to either IOS or Android?
There's not a concept impedance mismatch going from CVS->SVN->GIT. The concepts are so similar that git-svn exists to convert a SVN repo into a git repo (and a similar conversion tool exists for CVS->SVN)
Jira is so flexible and configurable that no such tool could exist. Migrating to a new tracking system requires that you either lose all currently tracked issues and their history OR you spend the money and effort handcrafting for your org a Jira->Foo translator to preserve some semblance of history. The larger and more diverse the org, the harder such a tool will be to craft.
> How do you think every single company in the world started to develop for iOS between 2008 and 2010?
Because ignoring a company that commands 30% of the market is a bad idea? How do you explain the flop of WebOS which was, IMO, a far better UX and OS compared to either IOS or Android?
How about when every single company rewrote their frontend stack in React after angular.js was done, circa 2015? Or when everyone moved to k8s within 2 years around 2017-2019? Hell, now even companies that definitely wouldn't benefit from anything related to k8s are diving into it.
What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. Yarn got adopted within a year above npm, the "default node package manager". Everything is always up for grabs, if you can show the benefits, however small they are. And the history aspect of Jira isn't an unsolvable problem, pretty much every single issue tracker in the world offers a Jira import, and losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. If a company can show that their alternative to Jira solves a percentage of common complaints against Jira, while offering the same capabilities of scaling that Jira does, people will follow. Nobody wants to deal with crappy products. Especially since the ones suffering the most from Jira are usually the ones in charge of setting up the very processes that Jira is supposed to help with, and to procure the tooling.
What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. Yarn got adopted within a year above npm, the "default node package manager". Everything is always up for grabs, if you can show the benefits, however small they are. And the history aspect of Jira isn't an unsolvable problem, pretty much every single issue tracker in the world offers a Jira import, and losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. If a company can show that their alternative to Jira solves a percentage of common complaints against Jira, while offering the same capabilities of scaling that Jira does, people will follow. Nobody wants to deal with crappy products. Especially since the ones suffering the most from Jira are usually the ones in charge of setting up the very processes that Jira is supposed to help with, and to procure the tooling.
> How about when every single company rewrote their frontend stack in React
God I wish that were the case. My company is still rocking Angular unfortunately :(
> Or when everyone moved to k8s within 2 years around 2017-2019
That did not happen. k8s got a good share of the market, but it's far from "everyone moved".
> What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools.
The tools you are listing are all dev tools picked, used, and curated by development. Jira isn't a dev tool, it's a product management tool. There's a major difference between tools that devs can pick and choose and tools that an organization gets to pick and choose.
Even with your "yarn" example, while it took over it didn't replace "npmjs" as the centralized repository server. Just like gradle still gets it's artifacts primarily from maven central.
I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written? Why does it remain one of the most popular programming languages even though most people are VERY quick to point out it's major flaws. Even though other better alternatives exist (Rust, Nim, D, etc).
> losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days.
Assuming you like everyone else went from svn->git I don't see how you'd have lost commit history. I personally converted a BUNCH of repos to git and didn't see any cases of lost history.
God I wish that were the case. My company is still rocking Angular unfortunately :(
> Or when everyone moved to k8s within 2 years around 2017-2019
That did not happen. k8s got a good share of the market, but it's far from "everyone moved".
> What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools.
The tools you are listing are all dev tools picked, used, and curated by development. Jira isn't a dev tool, it's a product management tool. There's a major difference between tools that devs can pick and choose and tools that an organization gets to pick and choose.
Even with your "yarn" example, while it took over it didn't replace "npmjs" as the centralized repository server. Just like gradle still gets it's artifacts primarily from maven central.
I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written? Why does it remain one of the most popular programming languages even though most people are VERY quick to point out it's major flaws. Even though other better alternatives exist (Rust, Nim, D, etc).
> losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days.
Assuming you like everyone else went from svn->git I don't see how you'd have lost commit history. I personally converted a BUNCH of repos to git and didn't see any cases of lost history.
> I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written?
Because C++ is very very much a living and, most importantly, evolving language. It gives modern conveniences, while benefiting from existing user base and maturity. Alternatives may be better for specific emerging use cases but can’t just yet challenge the incumbent for the reasons above. One day C++ may have to yield, but at the moment it’s been actively renewed and the effort to migrate codebases to a new standard is smaller than porting onto entirely new language.
Because C++ is very very much a living and, most importantly, evolving language. It gives modern conveniences, while benefiting from existing user base and maturity. Alternatives may be better for specific emerging use cases but can’t just yet challenge the incumbent for the reasons above. One day C++ may have to yield, but at the moment it’s been actively renewed and the effort to migrate codebases to a new standard is smaller than porting onto entirely new language.
Migrating very large SVN repos to Git is far from trivial.
> embedded into the core of how a company works.
Doubtful. Unless you are working for a shitty company in the first place, bad tools essentially just get skipped and disused by autonomous teams and none of this matters. If the company 'embeds' a product in place of a workflow, that's not something a product is ever going to fix, that's an organisational problem.
Doubtful. Unless you are working for a shitty company in the first place, bad tools essentially just get skipped and disused by autonomous teams and none of this matters. If the company 'embeds' a product in place of a workflow, that's not something a product is ever going to fix, that's an organisational problem.
It isn't that surprising that a programming language has inertia, it has lots of 'mass' so to speak -- programmers have to specialize in the language, and an ecosystem of libraries has to be built. It is more surprising to me that an issue tracker like Jira does. Surely people aren't specialized in... Jira-ing or whatever.
> Surely people aren't specialized in... Jira-ing or whatever.
There are people who build their careers on this. Their are consultants who do this, and only this. And the unfortunate reality is, Jira is so complicated, there actually is a reason for these people to exist.
There are people who build their careers on this. Their are consultants who do this, and only this. And the unfortunate reality is, Jira is so complicated, there actually is a reason for these people to exist.
> And the unfortunate reality is, Jira is so complicated, there actually is a reason for these people to exist.
So, easy benchmark for when something has become too complicated to be worthwhile: An industry of consultants is making a living off it.
SAP consultants, Oracle consultants, JIRA consultants... You don't see very many Excel consultants, do you? (Whaddoino, maybe there are.)
So, easy benchmark for when something has become too complicated to be worthwhile: An industry of consultants is making a living off it.
SAP consultants, Oracle consultants, JIRA consultants... You don't see very many Excel consultants, do you? (Whaddoino, maybe there are.)
You get a few projects in JIRA…and you’re stuck. Then you add JIRA Service Desk or Service Management or whatever the hell it’s called these days…and you’re stuck. Then you add some Confluence docs linked to your tickets…
Unless one is really willing to throw institutional knowledge out, changing tracking systems is extremely costly.
Unless one is really willing to throw institutional knowledge out, changing tracking systems is extremely costly.
Here's a better answer to that question:
Crowns don't come from inherent value. They come from monarchy.
Jira holds the crown because so many are convinced the "industry" in which it leads is worthy or valuable.
What value does a monarch provide? Order. Structure. Authority. Corporate environments value these because - art its core - that is what "Corporation" is: a new system of governance.
Most of the complaints about Jira can be turned to Corporatism itself.
Crowns don't come from inherent value. They come from monarchy.
Jira holds the crown because so many are convinced the "industry" in which it leads is worthy or valuable.
What value does a monarch provide? Order. Structure. Authority. Corporate environments value these because - art its core - that is what "Corporation" is: a new system of governance.
Most of the complaints about Jira can be turned to Corporatism itself.
The new Thomas Jeffer(y)son? ;-)
We start new companies all the time and nothing has been able to replace JIRA past the 5-10 engineers who know exactly what they are supposed to do stage.
> It is more about inertia.
Can't agree more. A few years ago, I joined a large healthcare organization to take a break from the startup grind. During my tenure, I witnessed the selection process of an issue tracking system and a chat platform.
They picked Teams for chat even though Slack ruled, and Teams was way behind in features. Why? Because it was the easy choice. They had the typical Microsoft stack just like every other large company, so go with Teams even though it sucked.
They picked Jira for issue tracking. Why? Because it was the easy choice. No one knew how to fully leverage it, and there was no way workflows would get buy in across the whole organization.
In large companies, especially non-tech ones, tooling decisions are driven more by laziness and CYA than what's the superior product.
Can't agree more. A few years ago, I joined a large healthcare organization to take a break from the startup grind. During my tenure, I witnessed the selection process of an issue tracking system and a chat platform.
They picked Teams for chat even though Slack ruled, and Teams was way behind in features. Why? Because it was the easy choice. They had the typical Microsoft stack just like every other large company, so go with Teams even though it sucked.
They picked Jira for issue tracking. Why? Because it was the easy choice. No one knew how to fully leverage it, and there was no way workflows would get buy in across the whole organization.
In large companies, especially non-tech ones, tooling decisions are driven more by laziness and CYA than what's the superior product.
Jira's core positioning is huge companies with complex organizations that will be willing to adjust tooling to their needs. Sure small and middle size companies can be happy with it too, but they're far from being the main profit center.
At that level, there isn't much competition. It costs a lot to develop a product that does everything and throws in the kitchen sink. It doesn't make sense for a startup, Open Source project could fit the bill (bugzilla ?) but they'd still need a service providing company, probably some corporate backing for the contracts etc.
Basically, JIRA is the Microsoft (or Oracle?) of the field, and any other company wanting to fight that turf would need incredibly deep pockets with an upfront investment that would only be recouped way way down the line, if they ever make it that far, and fighting JIRA would mean lower margins than if they dominated the market alone. Overall that doesn't look like a sane bet in any shape or form.
At that level, there isn't much competition. It costs a lot to develop a product that does everything and throws in the kitchen sink. It doesn't make sense for a startup, Open Source project could fit the bill (bugzilla ?) but they'd still need a service providing company, probably some corporate backing for the contracts etc.
Basically, JIRA is the Microsoft (or Oracle?) of the field, and any other company wanting to fight that turf would need incredibly deep pockets with an upfront investment that would only be recouped way way down the line, if they ever make it that far, and fighting JIRA would mean lower margins than if they dominated the market alone. Overall that doesn't look like a sane bet in any shape or form.
I feel like a lot of great programming talent has been wasted by very smart engineers who felt the pain of their current ticketing system and spent years building countless startups only to end up with something occasionally marginally better than Trac (2004).
Back in 2008-ish a lot of projects I came across tried to use Redmine because their company had a sucky JIRA or sometimes even Mantis implementation. Redmine turned out to be highly unsuitable in a matter of a few months and after trying out a few options that are mostly just tickets+kanban boards, it turned out that the simplest 'fix' was just setting up an individual JIRA just for the team so it could be used properly instead of some heavy handed top-down "use this tool in this specific way" approach. Once more teams started to do it, the 'company-wide' JIRA essentially just contained managers and a few product owners and it got deleted in a year or so.
Afterwards, all the 'team JIRAs' got merged into a normal JIRA again, but this time everyone had full control over their own projects and boards, problem, solved.
Afterwards, all the 'team JIRAs' got merged into a normal JIRA again, but this time everyone had full control over their own projects and boards, problem, solved.
What necessary features did Jira give you that Redmine and/or "tickets + kanban boards" didn't?
>why don't you think some other company has come along and toppled the Jira crown?
Why haven't cowboys found a different way besides horses to get around? They're not interested in what those under their asses think or feel.
Why haven't cowboys found a different way besides horses to get around? They're not interested in what those under their asses think or feel.
> "Jira is the worst project management tool, except for all the others"
I came here to say precisely this. In addition to Jira, I've used Clubhouse, Trello, monday.com, and GitHub Issues. Jira sucks slightly less than the alternatives I've used.
I came here to say precisely this. In addition to Jira, I've used Clubhouse, Trello, monday.com, and GitHub Issues. Jira sucks slightly less than the alternatives I've used.
> I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now).
I feel totally the opposite. If you've ever had to administer Jira at a large company than team-managed projects are the bane of your existence. If you think, there's even a small chance that your company will grow to 300+ engineers any time in the next several years then do yourself a favor and turn off team managed projects entirely or else you'll face a painful migration away from them.
Though I will generally defend Jira as a product for many of the reasons you said.
I feel totally the opposite. If you've ever had to administer Jira at a large company than team-managed projects are the bane of your existence. If you think, there's even a small chance that your company will grow to 300+ engineers any time in the next several years then do yourself a favor and turn off team managed projects entirely or else you'll face a painful migration away from them.
Though I will generally defend Jira as a product for many of the reasons you said.
I upvoted your comment because I believe it's a perfect example of what I was trying to point out: it is impossible to please everyone with a company-wide project management tool, but the fact remains that it is a necessity.
For all the people bitching about how Jira makes it hard to work like they want to work, their are folks like you who will complain that Jira makes it to easy to get around a company-wide standard.
To emphasize, I'm not saying either side is right or wrong, I'm just saying it's impossible to build a project management tool where large subsets of people won't complain about the exact same set of features that another subset of stakeholders likes.
For all the people bitching about how Jira makes it hard to work like they want to work, their are folks like you who will complain that Jira makes it to easy to get around a company-wide standard.
To emphasize, I'm not saying either side is right or wrong, I'm just saying it's impossible to build a project management tool where large subsets of people won't complain about the exact same set of features that another subset of stakeholders likes.
> but the fact remains that it is a necessity
I am interested on why people think that.
It doesn't look like a necessity to me. Ok, in a medium company, with dozens or maybe a hundred or two people, centralizing all the workflow is probably cheaper and more productive than siloing teams. But in a large company the inverse can very easily be true.
I am interested on why people think that.
It doesn't look like a necessity to me. Ok, in a medium company, with dozens or maybe a hundred or two people, centralizing all the workflow is probably cheaper and more productive than siloing teams. But in a large company the inverse can very easily be true.
What fails to scale?
We added a team-managed project a while back, and built a really good workflow around it that satisfied the needs of everyone who works in that project.
We can’t easily replicate that workflow anywhere else. This isn’t the end of the world, but I should be able to create a new team-managed project based on another team-managed project and then modify its workflow separately. So far, I can’t figure out how to do that.
I’d love to take the team-managed workflow and promote it to a company-managed workflow now that we’ve experimented with it. So far, I can’t figure out how to do that.
Don’t get me wrong, I really hate JIRA. I’ve written my own bug tracking system. I’ve tried lots of other tracking systems. JIRA is wrong on so many levels, but eventually you hit something in one of the other tools that you cannot address with those tools, but is possible (but painful to configure, and it might cost you extra money) in JIRA.
The only other tracking system I really like is GitHub issues, but it also has problems and limitations. And then you have things on GitHub that actively make things much worse (the autoclose bots; forms like the ones that Vue puts up, etc.).
I’ve never seen any organization need the level of complexity that they end up using in JIRA (especially the access permissions, which consistently get borked sideways), but most organizations eventually need something better than Bugzilla, Trac, or Github Issues.
The other difficulty is that switching bug tracking systems is tough. I want to really try Tara, or ClickUp, or Monday or a few different ones, but adding another tool is literally adding another tool. This is the same reason we’re using Confluence, even though it’s objectively the worst wiki in existence.
I hate Atlassian products with a passion. There’s nothing better, and the cost of switching is too high.
We can’t easily replicate that workflow anywhere else. This isn’t the end of the world, but I should be able to create a new team-managed project based on another team-managed project and then modify its workflow separately. So far, I can’t figure out how to do that.
I’d love to take the team-managed workflow and promote it to a company-managed workflow now that we’ve experimented with it. So far, I can’t figure out how to do that.
Don’t get me wrong, I really hate JIRA. I’ve written my own bug tracking system. I’ve tried lots of other tracking systems. JIRA is wrong on so many levels, but eventually you hit something in one of the other tools that you cannot address with those tools, but is possible (but painful to configure, and it might cost you extra money) in JIRA.
The only other tracking system I really like is GitHub issues, but it also has problems and limitations. And then you have things on GitHub that actively make things much worse (the autoclose bots; forms like the ones that Vue puts up, etc.).
I’ve never seen any organization need the level of complexity that they end up using in JIRA (especially the access permissions, which consistently get borked sideways), but most organizations eventually need something better than Bugzilla, Trac, or Github Issues.
The other difficulty is that switching bug tracking systems is tough. I want to really try Tara, or ClickUp, or Monday or a few different ones, but adding another tool is literally adding another tool. This is the same reason we’re using Confluence, even though it’s objectively the worst wiki in existence.
I hate Atlassian products with a passion. There’s nothing better, and the cost of switching is too high.
Yeah. My employer has company managed projects on by default, and there are several features which still haven't been re-implemented from OG team-managed Jira, particularly around workflow automation, that have tickets from 4 years ago saying "we're looking into implementing this in the next year!"
I'm on the same page as you, I don't love Jira either, it's not something I think about in the conversation of "software/services I enjoy using" - but I think it's _fine_.
Jira cloud in our organisation is also reasonably fast, the front end can be a bit janky sometimes, but overall considering the complexity of the application, it's not too bad.
Jira cloud in our organisation is also reasonably fast, the front end can be a bit janky sometimes, but overall considering the complexity of the application, it's not too bad.
Yeah I've been defended Jira here in the past, too.
My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some internal specialist Jira admin(s) to make your changes.
Also, in the last couple of years it's got a lot better. It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
In detraction: configuring it can be a huge PITA. So many screens, concepts, and so much clicking. But when it's done it works, and I think most of the hassle is just inherent complexity from such a configurable tool (if you haven't Admined Jira: you can change almost anything).
My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some internal specialist Jira admin(s) to make your changes.
Also, in the last couple of years it's got a lot better. It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
In detraction: configuring it can be a huge PITA. So many screens, concepts, and so much clicking. But when it's done it works, and I think most of the hassle is just inherent complexity from such a configurable tool (if you haven't Admined Jira: you can change almost anything).
Jira doesn't just reflect, it drives convoluted unhelpful bureaucracy. The tool drives the organization to look like the tool wants it to, which is disorganized half broken "organization" with silly overcomplicated rules that give people something to discuss enthusiastically instead of the actual work that needs doing.
Jira is organization poison, not just a reflection of what an organization is.
Jira is organization poison, not just a reflection of what an organization is.
No, it isn't. We have plenty of setups in multiple organisations where even within the org only the administrative settings of the server are locked down and everyone else is free to do whatever they need. Lots of teams just use it as a kanban board, while others setup a state machine-based funnel to process user/business input into usable tickets.
JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration. Now, there are plenty of products out there that suck no matter how you configure it (looking at you, ServiceNow).
Especially the comments about "I would rather use trello" seem extremely uninformed as you pretty much *are* trello when you just stick to one kanban board and one project.
JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration. Now, there are plenty of products out there that suck no matter how you configure it (looking at you, ServiceNow).
Especially the comments about "I would rather use trello" seem extremely uninformed as you pretty much *are* trello when you just stick to one kanban board and one project.
> JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration.
That's kind of the point, JIRA has been made into monstrosity at many organizations because the "create anything" mindset.
That's kind of the point, JIRA has been made into monstrosity at many organizations because the "create anything" mindset.
How does that make it a monstrosity? Unless we're talking about things that are shared across multiple teams, does it really matter how people use it? Nobody is going to care what someone else does in JIRA when they aren't touching that part anyway. Even with 1000 differently configured projects, your 1 or 2 projects you actually work with and configure are the only ones that matter.
Because it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common Jira platform for everybody and then you don't control how your project is run and then Jira becomes the enemy, a faceless micromanager driving your work life that has strong opinions on how you do everything, a dozen steps that need to be done "right" or you get your half a dozen managers asking if you read the memo about TPS reports, er, Jira tickets.
So that is not a JIRA problem since you can do a
> it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common
with pretty much everything, including a spreadsheet or a plain text file.
Conflating bad business practises with tool configuration or products in general doesn't help anyone. If a business is very stiff and scared of its employees, they will try out all sorts of useless control methods hoping it will somehow make some metric 'better'. You can do that with Trello too. Doesn't make Trello a bad product, and it doesn't make JIRA a bad product.
At the same time, pretending a larger organisation with many teams can function without any form of state tracking is a nice dream but not a reality either, so it's not like you can do without anything at all. But like reposted a bunch of times, how you do it and who is responsible for it is pretty important.
> it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common
with pretty much everything, including a spreadsheet or a plain text file.
Conflating bad business practises with tool configuration or products in general doesn't help anyone. If a business is very stiff and scared of its employees, they will try out all sorts of useless control methods hoping it will somehow make some metric 'better'. You can do that with Trello too. Doesn't make Trello a bad product, and it doesn't make JIRA a bad product.
At the same time, pretending a larger organisation with many teams can function without any form of state tracking is a nice dream but not a reality either, so it's not like you can do without anything at all. But like reposted a bunch of times, how you do it and who is responsible for it is pretty important.
The point is that there are tools that enable and encourage bad behavior. The kinds of organizational toxicity simply aren’t possible with some tools, sure an ambitious executive could try but the attempt would fail very quickly. Such attempts to do the broken overburdened nonsense that frequently comes with Jira don’t fail, they are enabled and encouraged. What is technically possible and what is likely are two very distant things.
"The tool can't do it" is an excuse. Excuses aren't tolerated. Now, make it happen.
Tools can't prevent bad management because bad managers don't care about tools. They care about getting what they want, and if the tool doesn't enable it, that's their underlings' problem, not theirs. Jira doesn't stand in their way because nothing stands in their way.
Tools can't prevent bad management because bad managers don't care about tools. They care about getting what they want, and if the tool doesn't enable it, that's their underlings' problem, not theirs. Jira doesn't stand in their way because nothing stands in their way.
That's precisely why Jira sucks: Because it doesn't stand in their way. And why you want simpler software, which by not being able to bend to their misguided will, does stand in their way.
JIRA really doesn't encourage anything in any direction except writing down what you are up to in a reasonably friendly way. Anything beyond that is up to the implementors, and there is nothing in the world that can prevent bad top-down behaviour within a company.
> JIRA really doesn't encourage anything in any direction
Given the amount of effort you devoted to replying to multiple posts, it feels disingenuous when you make an obvious and inaccurate statement as fact.
There is very little dependency graph organization (eg subtasks), which isn't reflected in most of the UI anyway as JIRA does push toward treating all tickets as a flat set. Work is a practical hierarchy of concerns and JIRA never made much progress away from a checklist (same as ASANA, Rike, etc).
Given the amount of effort you devoted to replying to multiple posts, it feels disingenuous when you make an obvious and inaccurate statement as fact.
There is very little dependency graph organization (eg subtasks), which isn't reflected in most of the UI anyway as JIRA does push toward treating all tickets as a flat set. Work is a practical hierarchy of concerns and JIRA never made much progress away from a checklist (same as ASANA, Rike, etc).
> Anything beyond that is up to the implementors
"Implementors". Anything that needs to be "implemented" is either a) not finished, b) too big and complex, or c) both.
Dunno for sure how much less code Jira has compared to, say, MS Excel or Adobe Acrobat, but I could imagine it might be up to an order of magnitude. But you don't have to "implement" those; you just install them.
"Implementors". Anything that needs to be "implemented" is either a) not finished, b) too big and complex, or c) both.
Dunno for sure how much less code Jira has compared to, say, MS Excel or Adobe Acrobat, but I could imagine it might be up to an order of magnitude. But you don't have to "implement" those; you just install them.
Better comparison product is MS Teams, not Excel.
We're just talking past each other, I'm saying Jira is bad because "it's a foot gun, and bad people keep shooting me in the foot" and you're saying "they shot you in the foot because they are bad". We are both right, technically, but I don't like working with foot-guns for this reason.
JIRA empowers bad management to be so, so much worse. JIRA is the assault rifle of footguns.
And how long is this going to last before someone further up decides that Jira needs to be unified for reporting purposes?
Eventually somebody with the organization obsession is going to get hired and put somewhere important and their goal is going to be making something complicated and unified and dissent will be "discouraged".
Eventually somebody with the organization obsession is going to get hired and put somewhere important and their goal is going to be making something complicated and unified and dissent will be "discouraged".
Depends on where you work I guess. In reality, reporting really has nothing to do with SWE state tracking. You can also just write a report in a letter and mail it to the board. It's not like they are going to log in to JIRA or even have an account or SSO-allowed credentials since they don't need to be there.
On the other hand, like almost copy-pasted here, if a top-down 'unification make it worse for everyone' effort is started, no vendor or tool is going to stop that and your work will get worse.
On the other hand, like almost copy-pasted here, if a top-down 'unification make it worse for everyone' effort is started, no vendor or tool is going to stop that and your work will get worse.
Spot on. One of the reasons we created Atlas (new product) was precisely this: help stakeholders and dependent teams focus on common language between teams over this misconception that task-level reporting is how they help understand the true state of work. Disclaimer: I work for Atlassian on Atlas, and I didn’t think I could ever get so passionate about soling this problem.
“Data needs to be unified for my executive use case” sounds like an org problem not a JIRA one. I’ve encountered it at companies that didn’t use JIRA at all
This happened to me!
It amazes me how much hate Jira gets compared to ServiceNow. My last two roles have been heavy on the ServiceNow, and I'd take a fresh breath of Jira any time.
My guess is it's because Jira actively targets SMB, while ServiceNow is almost strictly enterprise, and folks in enterprise have already resigned to their fate.
My guess is it's because Jira actively targets SMB, while ServiceNow is almost strictly enterprise, and folks in enterprise have already resigned to their fate.
And try to get a straight answer on pricing from the ServiceNow rep…
The answer is "way more than is sensible, even factoring in how absurd pricing on crap like this has gotten."
We dropped SN a couple years back over this. They were charging us about 6-7x what we pay for Jira, and we still use the on-site enterprise version of Jira.
We dropped SN a couple years back over this. They were charging us about 6-7x what we pay for Jira, and we still use the on-site enterprise version of Jira.
We have a few of those around as well. While they work fine, I don't really get why anyone would want to self-host JIRA or any COTS product like that anymore. Most instances now seem to be just a case of "our hosting company is fully responsible for it and it's pretty cheap and reliable" and until it starts failing or falling behind the cloud offering it'll probably stay like that.
Usually, if it isn't better from a staff-perspective or better for the customer, self-hosting or self-building is less likely to be the answer these days.
Usually, if it isn't better from a staff-perspective or better for the customer, self-hosting or self-building is less likely to be the answer these days.
Self hosting is sometimes easier to do than to argue with data governance about putting the information out a system that is offprem. The additional precautions for HIPAA or PII data that may show up in the comments or attachments can problematic. There are far too many users of all stripes that copy and paste data that they have access to without doing a check on it to see if it really does belong there (and if it does belong in the issue, then applying appropriate permissions to the object).
“Let’s have a kickoff, invite everyone in the company who may be interested, and white board out all the possible use cases. We have an exciting new pricing model that will greatly simplify pricing on your existing business. But I can’t tell you that price until after the kickoff.”
I have only ever seen servicenow used for… well, service requests. Reset my password, grant access, create this resource. Always administration, never product development.
I've seen it used for way more than that. Their sales (and customer support) people will gladly tell you it can, or soon will, do everything you may want it to do.
I think the comparison mostly stems from the legacy enterprise where badly configured tools are pushed top-down and workers are told to 'deal with it'. Either you'll be a developer mostly using JIRA or a non-developer mostly using ServiceNow, and if you're really unlucky in such an organisation you'll be using both.
Having a Service Desk that actually provides usable and composable tooling is a benefit for all. Having a random contractor "implement" ServiceNow because Gartner said so is a pain for all. This is of course a bit of opposing extremes, but the same applies to JIRA and AD and pretty much anything else. Hard-pushed bad implementation will ruin your workday.
Teams that are capable and allowed to self-steer and deviate from company policy if they come up with a good enough reason seems to be the sweet spot of attainable & realistic.
Having a Service Desk that actually provides usable and composable tooling is a benefit for all. Having a random contractor "implement" ServiceNow because Gartner said so is a pain for all. This is of course a bit of opposing extremes, but the same applies to JIRA and AD and pretty much anything else. Hard-pushed bad implementation will ruin your workday.
Teams that are capable and allowed to self-steer and deviate from company policy if they come up with a good enough reason seems to be the sweet spot of attainable & realistic.
Well said. I have to deal with both of them in my current role, and while Jira is... not great, ServiceNow is next-level-clunky.
ServiceNow is just about the most user hostile software I know. I know that any request I make that ends up in SN will take 2-4 times as long and i will never be sure that anything is happening or that they person on the other actually knows what I want.
Jira is highly flexible and customizable, almost to a fault. One Jira can look and operate almost totally different to another with enough customization. If Jira feels inflexible and bureaucratic to you, I'd argue that's only a reflection of how your Jira admins operate or the rules they are forced to implement.
>customizable, almost to a fault
Customizable, absolutely to a fault. It is the infinite customizability of a tool targeted towards middle management which is why Jira can go to hell.
It is indeed possible to not be in Jira hell, but inflation of complexity is inevitable and almost entirely irreversible. It encourages and accelerates the path towards bureaucratic hell. Any avoidance of this is a temporary aberration.
Customizable, absolutely to a fault. It is the infinite customizability of a tool targeted towards middle management which is why Jira can go to hell.
It is indeed possible to not be in Jira hell, but inflation of complexity is inevitable and almost entirely irreversible. It encourages and accelerates the path towards bureaucratic hell. Any avoidance of this is a temporary aberration.
Jira admins....says it all
It seems the pro-Jira comments here are basically, "It's fine if your organization isn't a mess and you don't abuse it."
That's the problem with any tool, framework, language, etc where the defenders main argument is, "It's great as long as you don't abuse it." or to put the former bluntly "It's not the tool, it's your organization." Over and over and over again, if an organization is allowed to abuse and misuse something, it eventually will.
Good tooling has opinions and will give you guardrails to not hang yourself.
That's the problem with any tool, framework, language, etc where the defenders main argument is, "It's great as long as you don't abuse it." or to put the former bluntly "It's not the tool, it's your organization." Over and over and over again, if an organization is allowed to abuse and misuse something, it eventually will.
Good tooling has opinions and will give you guardrails to not hang yourself.
Exactly, it's the same with C++. You can do great stuff with it as long as every single developer on the project is extremely disciplined and knowledgeable about its pitfalls.
As organizations and projects grow you or someone else will at some point hire incompetent people that mess up this delicate balance.
Better to have guardrails.
As organizations and projects grow you or someone else will at some point hire incompetent people that mess up this delicate balance.
Better to have guardrails.
> Jira doesn't just reflect, it drives convoluted unhelpful bureaucracy.
I though so too, but now I no longer believe that's the case. This is because of two reasons: one questions the statement itself - and the other one questions whether the statement correctly identifies the organizational issue.
Firstly, almost every tool I ever used for project organization has grown to similar degree of complexity. All _software_ employed was strongly incentivized to implement new mechanisms of automation and regulation - thus right now I would struggle to name a non-defunct and non-single-user tool that doesn't have the issue. And certainly no tool that that I would call "established" - an arbitrary designation, to be sure, but that largely reflects that the complexity almost _defines_ establishment for a project management tool.
Secondly, because I think the issue isn't, truly, the _bureaucracy_. Right now I believe it's the _technocracy_. It's the belief that every process has to be codified into software, and enforced in a manner that would make exceptions impossible without a pull request. This leads to - increase in complexity (because corner cases that would be easily solved with a quick email exchange now require weird workarounds - and if they are too common, actual change to the software) - reduction in real organizational flexibility (any special case is now discouraged on a technical level).
Worst part is, it's very hard to sell a shift away from this. Technocratic adherence to software-enforced processes became nearly synonymous to "accountability." In itself that's frustrating to me - I believe this serves to paint organizational failures as forces of nature, effectively reducing accountability. But, so far, I have failed to effectively communicate it to most people - with exception of the very few who, themselves, have a considerable interest in social dynamics, one that goes beyond the professional interest expected of a manager. And to those, those are generally truisms - I'm under no impression I'm particularly original here.
---
Aaaanyway, I went back to liking Jira - because, under all the cruft, there's still (or at least there still was) the basic bug tracker software that's almost like Bugzilla, but slightly less painful. And I like bug trackers, as long as they're used to track bugs - not manage projects. Projects are managed by people, and these days I believe that the reason all this software, as complex as it is, keeps failing to accurately communicate the project state, is because you would need the software to be a person.
I though so too, but now I no longer believe that's the case. This is because of two reasons: one questions the statement itself - and the other one questions whether the statement correctly identifies the organizational issue.
Firstly, almost every tool I ever used for project organization has grown to similar degree of complexity. All _software_ employed was strongly incentivized to implement new mechanisms of automation and regulation - thus right now I would struggle to name a non-defunct and non-single-user tool that doesn't have the issue. And certainly no tool that that I would call "established" - an arbitrary designation, to be sure, but that largely reflects that the complexity almost _defines_ establishment for a project management tool.
Secondly, because I think the issue isn't, truly, the _bureaucracy_. Right now I believe it's the _technocracy_. It's the belief that every process has to be codified into software, and enforced in a manner that would make exceptions impossible without a pull request. This leads to - increase in complexity (because corner cases that would be easily solved with a quick email exchange now require weird workarounds - and if they are too common, actual change to the software) - reduction in real organizational flexibility (any special case is now discouraged on a technical level).
Worst part is, it's very hard to sell a shift away from this. Technocratic adherence to software-enforced processes became nearly synonymous to "accountability." In itself that's frustrating to me - I believe this serves to paint organizational failures as forces of nature, effectively reducing accountability. But, so far, I have failed to effectively communicate it to most people - with exception of the very few who, themselves, have a considerable interest in social dynamics, one that goes beyond the professional interest expected of a manager. And to those, those are generally truisms - I'm under no impression I'm particularly original here.
---
Aaaanyway, I went back to liking Jira - because, under all the cruft, there's still (or at least there still was) the basic bug tracker software that's almost like Bugzilla, but slightly less painful. And I like bug trackers, as long as they're used to track bugs - not manage projects. Projects are managed by people, and these days I believe that the reason all this software, as complex as it is, keeps failing to accurately communicate the project state, is because you would need the software to be a person.
Lighten up Francis. Jira is simply a tool. if you care that much, apply to be on the team at your company that defines the workflow rules and strip away what isn't needed.
The central problem with JIRA is that, once you've gotten beyond the overly customizable functionality and difficult-to-reason about permissions, and once you've managed to avoid organizations that go too far off of the deep-end and once you've finally found a happy simplicity in a kanban-ish board,
once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.
once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.
As someone who uses both, let me recommend to you Microsoft Teams, the only enterprise software that manages to be slower.
There’s a screen in jira if you change multiple items with a progress bar. I looked once and the operation seems to happen instantly and the progress bar is just there because of some bad designers ego…
> It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
My understanding is that the Cloud offering is the slower one, assuming you can dedicate a beefy server (but probably under $200/mo on hetzner or ovh for most businesses) to running your Atlassian stuff.
My understanding is that the Cloud offering is the slower one, assuming you can dedicate a beefy server (but probably under $200/mo on hetzner or ovh for most businesses) to running your Atlassian stuff.
"My opinion is that Jira reflects the organisation that manages it."
Came here to say EXACTLY this. I've used Jira across 3 companies, and in the first 2, I always felt like folks complaining about Jira were just being picky developers wanting the sun, moon and the stars, because Jira worked perfectly fine for me and my team (in fact, it was the backbone of our process).
Then in the third org, I felt like I was hit with a brick wall of every single issue folks complaining about jira point out. Needless workflows, Middle Managers wanting to "control" how stories/epics get closed, multiple levels of convoluted manual configurations, automated processes creating Jiras that for trivial non-issues which clogged notifications and team backlogs and brought jira to a crawl etc. Heck, at one point, the mess got so bad, that the company considered hiring a third party to "fix" our Jira workflows. And note that this was a <100 person startup!
On introspecting, I completely felt that in the first 2 companies, the organization was structured around "getting stuff done" and "keeping stuff as simple as possible, but no simpler" and that naturally flowed into how Jira was set up as well, while in the latter, the focus was entirely on top-down "process", and that showed in the Jira setup as well.
Honestly, I now think I can say a lot about a company's engineering/product culture just by spending 15 minutes on their Jira ;-)
Came here to say EXACTLY this. I've used Jira across 3 companies, and in the first 2, I always felt like folks complaining about Jira were just being picky developers wanting the sun, moon and the stars, because Jira worked perfectly fine for me and my team (in fact, it was the backbone of our process).
Then in the third org, I felt like I was hit with a brick wall of every single issue folks complaining about jira point out. Needless workflows, Middle Managers wanting to "control" how stories/epics get closed, multiple levels of convoluted manual configurations, automated processes creating Jiras that for trivial non-issues which clogged notifications and team backlogs and brought jira to a crawl etc. Heck, at one point, the mess got so bad, that the company considered hiring a third party to "fix" our Jira workflows. And note that this was a <100 person startup!
On introspecting, I completely felt that in the first 2 companies, the organization was structured around "getting stuff done" and "keeping stuff as simple as possible, but no simpler" and that naturally flowed into how Jira was set up as well, while in the latter, the focus was entirely on top-down "process", and that showed in the Jira setup as well.
Honestly, I now think I can say a lot about a company's engineering/product culture just by spending 15 minutes on their Jira ;-)
This applies to all enterprise software. It’s also called Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
https://en.wikipedia.org/wiki/Conway's_law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
https://en.wikipedia.org/wiki/Conway's_law
It's not a neutral tool. Jira makes micromanagement easy and trusting people hard; you can use it for good, but you're working against the grain of it the whole time. Everything is default deny (issues can only go through approved transitions, by default regular users can't change the available transitions), the default issue forms have way too many mandatory fields, and a bunch of reports that only micromanagers want or need are front and center in the UI.
> the default issue forms have way too many mandatory fields
I only fill points and name for my issues. My company never customized anything.
I only fill points and name for my issues. My company never customized anything.
I find Jira isn't a tracker, it's a tracker construction kit.
You can make it be pretty much anything you want - except, you know, fast.
You can make it be pretty much anything you want - except, you know, fast.
I view Jira as the embodiment of the misguided software engineering practice of trying to generalize and abstract too high level of a task of something like "project management" and distill it down into one tool.
While the Golden perfect abstraction handed down for the heavens by the gods is what you seek, it ultimately passes down complexity to end users through its generic approach. You need to create opinions within the generic world and then your team needs to understand Jira's abstraction combined with the opinion your company builds around it that's probably not documented.
The end result is unless you're running a large project that really requires the functionality possible in Jira where creating the overhead or overloading something simpler isn't practical, then you're probably better off using something simpler and more opinionated--a nice simple solid framework to keep everyone on track.
While the Golden perfect abstraction handed down for the heavens by the gods is what you seek, it ultimately passes down complexity to end users through its generic approach. You need to create opinions within the generic world and then your team needs to understand Jira's abstraction combined with the opinion your company builds around it that's probably not documented.
The end result is unless you're running a large project that really requires the functionality possible in Jira where creating the overhead or overloading something simpler isn't practical, then you're probably better off using something simpler and more opinionated--a nice simple solid framework to keep everyone on track.
I realize company-wide planning is extremely hard, especially when there are many inter-dependencies that can block entire departments if a single deadline slips. But in my experience, the only thing that Jira brings to the table is the ability to document, in a centralized place, the pieces of work that need to be done, and what stage they are currently in. In my field, anything software related is really hard to estimate accurately, which makes the whole aggregate estimation in Jira not only worthless, but actively harmful because management will treat it as truth. We could replace Jira with a big whiteboard of TODOs and we'd likely get things done faster, and with higher quality. My favorite excerpt from the site:
> Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.
> Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.
Almost none of that is true depending on which version of Jira we are talking about and what type of project you have chosen.
I'm in the Jira is actually pretty good camp. I've administered Jira instances from the ground up, including installation, integrating it with directory services, customizing workflows or just as a user in large and small organizations.
The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable. Some transitions make more sense than others. It was also quite tedious to create transitions from "all other states" to some state. So admins were incentivized to only allow transitions that immediately made sense to them and not bother with the others. From the end user perspective this obviously looks like draconian overlordship. While in reality in many cases its just too tedious. Atlassian has heard user complaints though and an "all states can transition here" option is available since some time ago and the default workflow for some types of projects are basically just a few workflow states that all have this transition as the only possible one. Basically transition from any state to any other state. No transition screens. That's pretty open.
If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira. Locked down workflows and transitions, restructured editability etc do have their place in many valid use cases. A simple one being as a customer facing tool where you need to enforce certain things directly because your customer is not first going to learn your conventions and then self apply these.
The same goes for mandatory fields. The only mandatory field you have to choose yourself really is the issue summary. Everything else if mandatory by default has default values. I have used many a Jira instance where Priority (a default mandatory field that also has a default value though) was all but ignored by everyone even if it was still on screen.
Can you elaborate on the reports that only micromanagers would ever use? I agree that some of them can be used by micromanagers as can a lot of Jira functionality. There are many that can also be very useful directly in the hands of teams.
Team managed projects are awesome because sharing Jira admin rights in a large org was hard. Because things are so configurable a good set of naming rules were essential. It was usually easier to set up individual instances for projects instead of having a shared instance for large orgs. And if you centralize administration too much then changes grind to a halt. I have shared admin right with many others successfully though where these standards were adhered to by everyone and changes to work flows, issue and custom field definitions and such were easy to get through. Just required discipline.
I'm in the Jira is actually pretty good camp. I've administered Jira instances from the ground up, including installation, integrating it with directory services, customizing workflows or just as a user in large and small organizations.
The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable. Some transitions make more sense than others. It was also quite tedious to create transitions from "all other states" to some state. So admins were incentivized to only allow transitions that immediately made sense to them and not bother with the others. From the end user perspective this obviously looks like draconian overlordship. While in reality in many cases its just too tedious. Atlassian has heard user complaints though and an "all states can transition here" option is available since some time ago and the default workflow for some types of projects are basically just a few workflow states that all have this transition as the only possible one. Basically transition from any state to any other state. No transition screens. That's pretty open.
If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira. Locked down workflows and transitions, restructured editability etc do have their place in many valid use cases. A simple one being as a customer facing tool where you need to enforce certain things directly because your customer is not first going to learn your conventions and then self apply these.
The same goes for mandatory fields. The only mandatory field you have to choose yourself really is the issue summary. Everything else if mandatory by default has default values. I have used many a Jira instance where Priority (a default mandatory field that also has a default value though) was all but ignored by everyone even if it was still on screen.
Can you elaborate on the reports that only micromanagers would ever use? I agree that some of them can be used by micromanagers as can a lot of Jira functionality. There are many that can also be very useful directly in the hands of teams.
Team managed projects are awesome because sharing Jira admin rights in a large org was hard. Because things are so configurable a good set of naming rules were essential. It was usually easier to set up individual instances for projects instead of having a shared instance for large orgs. And if you centralize administration too much then changes grind to a halt. I have shared admin right with many others successfully though where these standards were adhered to by everyone and changes to work flows, issue and custom field definitions and such were easy to get through. Just required discipline.
> The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable.
That's probably where the wide-spread (and arguably correct) impression that it has become worse comes from: To begin with, people just installed and used it as-is, but by now corporate bureaucracies have had time to "implement" it -- i.e. set it up -- to mirror their organisation's bureaucratic structure and processes.
And yes, that impression is correct; it is Jira's fault: If it didn't have that customisability, they couldn't (ab)use it that way.
> If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira.
Of course you can: If it didn't offer the possibility to set up those bureaucratic locks, they wouldn't be set up.
That's probably where the wide-spread (and arguably correct) impression that it has become worse comes from: To begin with, people just installed and used it as-is, but by now corporate bureaucracies have had time to "implement" it -- i.e. set it up -- to mirror their organisation's bureaucratic structure and processes.
And yes, that impression is correct; it is Jira's fault: If it didn't have that customisability, they couldn't (ab)use it that way.
> If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira.
Of course you can: If it didn't offer the possibility to set up those bureaucratic locks, they wouldn't be set up.
I can tell you that a lot of other tools before Jira that I have had to use were really quite good at mirroring that structure in a much worse way ;) Most of those tools from my experience were not usable in a good way.
You and other people are obviously entitled to the opinion that Jira made it worse.
In my book, that's like saying it's the Swiss Army knife's fault that someone was killed with it.
You and other people are obviously entitled to the opinion that Jira made it worse.
In my book, that's like saying it's the Swiss Army knife's fault that someone was killed with it.
Victorinox's fault. If there were no Swiss Army knives, nobody would get killed with one.
If you sign up to Jira today and start a new project, you'll get the options of a simple workflow with a minimum of fields. The beginning statuses are basically "to do", "in progress", and "done". There's a fair amount of trust in those steps, IMO.
> by default regular users can't change the available transitions
I can't imagine allowing this. This would be a recipe for chaos. The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
If that's okay on a team then that team probably shouldn't use Jira. I also would not want to be the team-lead, or anyone else trying to figure out what's going on or keep track of work!
> by default regular users can't change the available transitions
I can't imagine allowing this. This would be a recipe for chaos. The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
If that's okay on a team then that team probably shouldn't use Jira. I also would not want to be the team-lead, or anyone else trying to figure out what's going on or keep track of work!
> The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
Everywhere I've worked the states have been the steps, the transitions have just been there for Jira's own bookkeeping. And in the real world it's always possible to move a piece of work to any other step in your workflow - things like "the designer's realised he messed up the wireframes, put it back to design even though it was currently in code review" happen all the time. I don't think that's the same as not having any process.
In the Jira way of doing things you can't do that if that transition doesn't exist, and you probably don't have the required permissions to add that transition (if you can even figure out what they are). Couple that with Jira's terrible performance and I've been in more than one company where you could accidentally drag and drop a ticket to the wrong column (because Jira decides to finish loading at the wrong time) at which point it's permanently fucked up and your only option is to copy and paste the data (one field at a time, natuarlly) into a new ticket.
Everywhere I've worked the states have been the steps, the transitions have just been there for Jira's own bookkeeping. And in the real world it's always possible to move a piece of work to any other step in your workflow - things like "the designer's realised he messed up the wireframes, put it back to design even though it was currently in code review" happen all the time. I don't think that's the same as not having any process.
In the Jira way of doing things you can't do that if that transition doesn't exist, and you probably don't have the required permissions to add that transition (if you can even figure out what they are). Couple that with Jira's terrible performance and I've been in more than one company where you could accidentally drag and drop a ticket to the wrong column (because Jira decides to finish loading at the wrong time) at which point it's permanently fucked up and your only option is to copy and paste the data (one field at a time, natuarlly) into a new ticket.
Yes, we switched to Jira from a piece of abandonware (simple php based bug tracker) several years ago. Jira is kinda slow sometimes, but not horrible. And yes, like you said, once you get it configured it works great.
Overall, we are very happy with Jira and it's worth the cost for the value it brings to the organization (still hurts the wallet, but it's at least justified).
...and then Atlassian comes along and rug-pulls on-prem Jira.
We only have ~80 users, so 1000-user-minimum data center isn't going to cut it for us. And there is an on-prem requirement, so no cloud option either (wouldn't want to anyway). And for that, I bitch. Fuck Atlassian and everything they do to appease their shareholders before the customers.
Overall, we are very happy with Jira and it's worth the cost for the value it brings to the organization (still hurts the wallet, but it's at least justified).
...and then Atlassian comes along and rug-pulls on-prem Jira.
We only have ~80 users, so 1000-user-minimum data center isn't going to cut it for us. And there is an on-prem requirement, so no cloud option either (wouldn't want to anyway). And for that, I bitch. Fuck Atlassian and everything they do to appease their shareholders before the customers.
Yeah that's a bit rough. Though I think for most people the cloud solution is the way to go, though - even if it's an evil Saas-recurring-revenue play. I was close enough to a previous team that used to admin an on-prem Jira (~7 years ago) to know it wasn't just set-and-forget, and also that almost all the slowness users complained about was due to under-provisioned hardware.
Honestly I reckon half of Jira's reputation for slowness could have come from bad on-prem installs. The cloud version is not slow, and Atlassian does do work on performance
https://community.atlassian.com/t5/Confluence-articles/Confl...
Honestly I reckon half of Jira's reputation for slowness could have come from bad on-prem installs. The cloud version is not slow, and Atlassian does do work on performance
https://community.atlassian.com/t5/Confluence-articles/Confl...
funny you should say that given a bunch of these rants on the article link sound very much like the cloud version in terms of amount of JS loaded and network requests.
Also no shortage of folks elsewhere in this discussion talking about cloud slowness.
We've had plenty of irritations with our on-prem, but slowness, not so much. And yeah, for us it's mostly about keeping the data internal.
Also no shortage of folks elsewhere in this discussion talking about cloud slowness.
We've had plenty of irritations with our on-prem, but slowness, not so much. And yeah, for us it's mostly about keeping the data internal.
I’m not convinced the cloud version isn’t terribly slow.
There’s a ton more indirection for userids. Screens that used to be part of my standard workflow have Ajax handlers. Even name completion is slow.
The #1 question answer on the old ui survey workaround asking why are you using the old ui: slowness.
Confluence also got clobbered. I can count page load times.
There’s a ton more indirection for userids. Screens that used to be part of my standard workflow have Ajax handlers. Even name completion is slow.
The #1 question answer on the old ui survey workaround asking why are you using the old ui: slowness.
Confluence also got clobbered. I can count page load times.
> all the slowness users complained about was due to under-provisioned hardware
I think it's more of a software problem tbh.
I think it's more of a software problem tbh.
>The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve.
I think the core problem with Jira is organizations trying to use it to solve complex organization-wide problems. It is an enormous time sink, and using Jira to rule the workdays of employees is the problem.
Anything much more complicated than a checklist is wrong. Jira is an attractor for middle management growth that gives people who don't need to be doing anything something to do, and adding complexity gives more opportunities for more people to not do very much and generally get in the way of execution. It is also a way to give people who aren't very necessary or very good at understanding the big picture something that they can do to do.
Take away Jira and tools that you can order other people to use and you end up with middle management that literally doesn't know what to do because they couldn't organize or ease productivity to save their lives. Jira becomes the thing being managed instead of whatever is actually to be done.
I think the core problem with Jira is organizations trying to use it to solve complex organization-wide problems. It is an enormous time sink, and using Jira to rule the workdays of employees is the problem.
Anything much more complicated than a checklist is wrong. Jira is an attractor for middle management growth that gives people who don't need to be doing anything something to do, and adding complexity gives more opportunities for more people to not do very much and generally get in the way of execution. It is also a way to give people who aren't very necessary or very good at understanding the big picture something that they can do to do.
Take away Jira and tools that you can order other people to use and you end up with middle management that literally doesn't know what to do because they couldn't organize or ease productivity to save their lives. Jira becomes the thing being managed instead of whatever is actually to be done.
Agreed, it’s like a big flashing neon sign that promises middle management a stage on which to act out all their worst impulses. It’s the exact opposite of “keep it simple and communicate with each other like humans.”
100% agree, in my current role it’s used this, if what you’re working on doesn’t have an issue, you’re a naughty person.
If a company is trying to use JIRA for more than state communication they are doing it wrong IMO. Planning goes into calendars, ephemeral stuff goes into chats and calls, and code and code-level issues goes into repositories. I have seen plenty of attempts to make a product like JIRA the 'interface' between some management person and 'the subordinates' and it never works, simply because trying to place an 'interface' there in itself doesn't work.
I think what other tools miss that JIRA did well is giving engineering managers tools to communicate with upper management. You're right that actually attempting to use JIRA as the medium of communication with people outside the product org is hopelessly, fatally flawed, but being able to visualize an issue like an unmanageable backlog, or team productivity, or quality issues is invaluable, and a lot of simple tools throw the baby out with the bathwater by completely failing to give any tools to analyze how your team is doing.
If it's configured properly, JIRA can be a fairly effective tool that mostly stays out of the way of developers but can help team leads and managers communicate things about the team.
If it's configured properly, JIRA can be a fairly effective tool that mostly stays out of the way of developers but can help team leads and managers communicate things about the team.
That is indeed what happens with the simpler JIRA clones. On top of that, usually the org has no idea what is going on, who is working on what or what is still waiting to be looked at by anyone.
Normally those issues would be handled with a simple 5 minute meeting (DSU or some variant thereof) where everyone shares their current state, and then a few times per month some form of "where are we and where are we going" type of planning. (Be it a sprint planning or something like it) Combining that with a state tracker seems like a fairly obvious thing to do, and having the tools to then report on that over time (graphs can be a helpful visualisation that simple tools usually lack) gives everyone some context as to how healthy the team is.
But even that last bit, the concept of periodically having a bit of a check up to see how things are going is often lacking in "we can do it better and simpler" types of setups. In then end, it gets reduced back to the manager walking around with a whip shouting "work harder!" instead of teams having some autonomy and figuring their own state out themselves.
Normally those issues would be handled with a simple 5 minute meeting (DSU or some variant thereof) where everyone shares their current state, and then a few times per month some form of "where are we and where are we going" type of planning. (Be it a sprint planning or something like it) Combining that with a state tracker seems like a fairly obvious thing to do, and having the tools to then report on that over time (graphs can be a helpful visualisation that simple tools usually lack) gives everyone some context as to how healthy the team is.
But even that last bit, the concept of periodically having a bit of a check up to see how things are going is often lacking in "we can do it better and simpler" types of setups. In then end, it gets reduced back to the manager walking around with a whip shouting "work harder!" instead of teams having some autonomy and figuring their own state out themselves.
>If a company is trying to use JIRA for more than state communication they are doing it wrong IMO.
This is why tools that don't allow this kind of doing-it-wrong are significantly superior to Jira.
This is why tools that don't allow this kind of doing-it-wrong are significantly superior to Jira.
That's a nice theory, but in practise people have been mailing to Slack, using meetings to read emails and using JIRA to track Git commits.
Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. Complaining about a tool that has no influence over your work process really doesn't change anything.
Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. Complaining about a tool that has no influence over your work process really doesn't change anything.
> Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company.
That's naive; tools influence the way they're used. When a tool defaults to having manager accounts that can change how things get done and developer accounts that can't, it nudges the organisation in that direction.
That's naive; tools influence the way they're used. When a tool defaults to having manager accounts that can change how things get done and developer accounts that can't, it nudges the organisation in that direction.
> It's always taken on from the position of "well, it didn't make my specific use case easy"
For customers, their own specific use cases are the only ones they should care about.
I don't know why there isn't a good solution to the problems Jira attempts to tackle, but that's no reason to get philosophical. It's OK to hate every existing option.
For customers, their own specific use cases are the only ones they should care about.
I don't know why there isn't a good solution to the problems Jira attempts to tackle, but that's no reason to get philosophical. It's OK to hate every existing option.
> The fact is, building a generic project management and tracking tool is a really difficult, hard problem.
This is pretty much the core of it. I use Jira daily, but my exposure to it is the tip of the iceberg in terms of what it can do.
I think what most people forget is that this Jira is basically an ERM but for development-focused organizations. (Where the resources are time and people instead of processes and inventory.) If you've ever seen the complexity (or price tag!) of a real ERM, Jira actually looks very reasonable.
That said, smaller companies and teams should definitely use simpler tools that are more appropriate for their scale. Hire a Jira consultant and make the switch only when you're big enough to justify it.
This is pretty much the core of it. I use Jira daily, but my exposure to it is the tip of the iceberg in terms of what it can do.
I think what most people forget is that this Jira is basically an ERM but for development-focused organizations. (Where the resources are time and people instead of processes and inventory.) If you've ever seen the complexity (or price tag!) of a real ERM, Jira actually looks very reasonable.
That said, smaller companies and teams should definitely use simpler tools that are more appropriate for their scale. Hire a Jira consultant and make the switch only when you're big enough to justify it.
I get paid for developing plugins for Jira since 2014. One can complain about UX and speed of this software, but I saw it being the hearth of businesses of all kinds and sizes.
Just like you won't get fired for using React in your project, you won't get fired for using Jira. It will support whatever your workflow is (and I don't mean only software development, but things like hiring or office management). If the built-in features are not enough, you will find a plugin that meets your needs.
I think long-term it's important to use a tool that give you this flexibility.
Just like you won't get fired for using React in your project, you won't get fired for using Jira. It will support whatever your workflow is (and I don't mean only software development, but things like hiring or office management). If the built-in features are not enough, you will find a plugin that meets your needs.
I think long-term it's important to use a tool that give you this flexibility.
Does Linus use JIRA on that little project called the Linux kernel? Why is git with good readmes and clear pull requests not enough project management?
If you're not doing PR's you are just LARPing software development.
I don't hate JIRA, I hate "IT" employees that can't program.
No Linus uses Bugzilla [1]. Have you ever used it? You'll be begging for Jira once you've used Bugzilla.
Also Linux doesn't use pull requests. GIT doesn't even know the concept of a PR. You are supposed to generate a patch with 'git format-patch' and submit it to a mailinglist.
[1] https://bugzilla.kernel.org/
Also Linux doesn't use pull requests. GIT doesn't even know the concept of a PR. You are supposed to generate a patch with 'git format-patch' and submit it to a mailinglist.
[1] https://bugzilla.kernel.org/
git doesn't know the concept of a Pull Request? https://git-scm.com/docs/git-request-pull
Bugzilla is for bugs and that's the point, right? A project is not a set of bugs...
Bugzilla is for bugs and that's the point, right? A project is not a set of bugs...
A GIT "request-pull" generates a (mail) text with a patch which is to be send to a mailinglist. It's just the automated version of 'git format-patch' which also generates the e-mail message text. It is nothing like a Github PR.
What's wrong with Bugzilla?
The Kernel isn’t managed solely through patches and README files. There is often a lot of up-front communication and documentation.
My takeaway is that the planning and the issue/bug-tracking and the patch submissions are three seperate somewhat independent processes. There are no managers trying to group all the tickets into patches and patches into projects in some sort of neat (but illusionary) hierarchy.
My takeaway is that the planning and the issue/bug-tracking and the patch submissions are three seperate somewhat independent processes. There are no managers trying to group all the tickets into patches and patches into projects in some sort of neat (but illusionary) hierarchy.
> I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve.
I think the problem is that Jira is optimized for productivity theater and top-down management.
When an organization deploys Jira it is usually because upper management thinks that it needs a deluge of task tracking so that everyone can stay perfectly "aligned" all the time.
This creates an annoying amount of make-work on the part of Engineers and their immediate managers, slows down velocity and the vast majority of the time spent on inputting data into Jira never results in anything actionable.
Jira is just a symptom of the disease though.
I think the problem is that Jira is optimized for productivity theater and top-down management.
When an organization deploys Jira it is usually because upper management thinks that it needs a deluge of task tracking so that everyone can stay perfectly "aligned" all the time.
This creates an annoying amount of make-work on the part of Engineers and their immediate managers, slows down velocity and the vast majority of the time spent on inputting data into Jira never results in anything actionable.
Jira is just a symptom of the disease though.
> Jira is optimized for productivity theater and top-down management
Hit the nail on the head.
I don't hate Jira.
I hate working for companies and with "micromanagers" that prioritize bs metrics over improving customer satisfaction, and busywork over impactful projects. And these kinds of people / companies always use Jira.
Hit the nail on the head.
I don't hate Jira.
I hate working for companies and with "micromanagers" that prioritize bs metrics over improving customer satisfaction, and busywork over impactful projects. And these kinds of people / companies always use Jira.
>The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve.
This is a lot of hearsay which tends to devolve into a debate of "we absolute need this!" vs "no you don't, see X".
>Obviously some of the complaints (speed, stability) are very valid
I don't think people defending it fully grasp just how important speed and stability are, or at least live in a corporation where Jira was optimized better than the average corporation does. Given not everything is the fault of Jira, but when Jira is expected to be the place you go to all the time and it is that slow, it becomes very impactful to morale.
>"Jira is the worst project management tool, except for all the others".
This doesn't work until big corps actually try something different, but pretty much all of them push back on the mere idea of trying alternatives. If you can't invest a few months trying a different system, you can't judge it. And since those few months are seen as a "great risk", no manager is going to push the issue any further, even if Jira's costs per developer could easily run into the hundreds (or thousands, for 6-figures) a year on morale loss and time loss alone.
And this is the crux of the matter. Management likes concrete numbers. Management likes mimicking what other successful companies do. Management does not like fairly abstract things with great risks. Management does not like big risks with abstract rewards.
This is a lot of hearsay which tends to devolve into a debate of "we absolute need this!" vs "no you don't, see X".
>Obviously some of the complaints (speed, stability) are very valid
I don't think people defending it fully grasp just how important speed and stability are, or at least live in a corporation where Jira was optimized better than the average corporation does. Given not everything is the fault of Jira, but when Jira is expected to be the place you go to all the time and it is that slow, it becomes very impactful to morale.
>"Jira is the worst project management tool, except for all the others".
This doesn't work until big corps actually try something different, but pretty much all of them push back on the mere idea of trying alternatives. If you can't invest a few months trying a different system, you can't judge it. And since those few months are seen as a "great risk", no manager is going to push the issue any further, even if Jira's costs per developer could easily run into the hundreds (or thousands, for 6-figures) a year on morale loss and time loss alone.
And this is the crux of the matter. Management likes concrete numbers. Management likes mimicking what other successful companies do. Management does not like fairly abstract things with great risks. Management does not like big risks with abstract rewards.
I don't use Jira. I'm aware of what it basically is. We're small, we use a pin board, 3x5 cards, and a drawer.
Do open source projects of any size use Jira? If not, do they use a basic knock off? The few not-so-big ones I've contributed to seem to get by without it, but maybe I just don't have enough exposure with these. If the open source world can be semi-productive without Jira, I think that's telling. The interested student can decide the details of what it's telling.
Do open source projects of any size use Jira? If not, do they use a basic knock off? The few not-so-big ones I've contributed to seem to get by without it, but maybe I just don't have enough exposure with these. If the open source world can be semi-productive without Jira, I think that's telling. The interested student can decide the details of what it's telling.
Groovy does - I assume all Apache products do too, and I assume they get a good deal because they're doing open source stuff.
The problem with Jira is that it is checkbox software, designed to sail through the checkbox procurement processes that large organizations have. "It checks all the boxes!"
Because of this, it is basically jello. It is everything, and it is nothing.
It makes nothing simple, and encourages people to overachieve with the tool. If you overachieve with the tool, you will underachieve on what it is you're really trying to do.
This is why much simpler tools are better. They are usually free, or at least a lot less expensive, and they come with constraints that you have to live within. Usually those constraints prevent you from going tool crazy, and guide you to actually focus on getting work done instead of doing performance art with Jira.
Because of this, it is basically jello. It is everything, and it is nothing.
It makes nothing simple, and encourages people to overachieve with the tool. If you overachieve with the tool, you will underachieve on what it is you're really trying to do.
This is why much simpler tools are better. They are usually free, or at least a lot less expensive, and they come with constraints that you have to live within. Usually those constraints prevent you from going tool crazy, and guide you to actually focus on getting work done instead of doing performance art with Jira.
> The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve.
No, I have a really good understanding of that. My problem is that Jira, in actual implementation, tends to be how some parts of the organization (often Product) tries to exert fine grained control over other parts of the organization (design, qa, development, operations, etc.) by micromanaging the process.
Also, sometimes your organization is just not that complicated. I've been in startups using Jira with dozens of states, with complicated transitions and approval steps, that would have been over kill in medical companies I've worked at.
No, I have a really good understanding of that. My problem is that Jira, in actual implementation, tends to be how some parts of the organization (often Product) tries to exert fine grained control over other parts of the organization (design, qa, development, operations, etc.) by micromanaging the process.
Also, sometimes your organization is just not that complicated. I've been in startups using Jira with dozens of states, with complicated transitions and approval steps, that would have been over kill in medical companies I've worked at.
Your point is admirable but its also short sighted. You're right that building a one size fits all tool is a large task and it's easy to complain about something hard.
But the flaw is in assuming it's a problem that should be solved in a one size fits all way. In my experience the pain points come from top down process that's at odds with the reality of the work.
But the flaw is in assuming it's a problem that should be solved in a one size fits all way. In my experience the pain points come from top down process that's at odds with the reality of the work.
People who hate Jira need to spend a year working in VersionOne
Same here, I really don't get the cargo cult hate against Jira.
Before I got to use Jira for the first time around 2006, everything I used before was crap, either in-house solutions out of CGI scripts or crap like ClearQuest.
Stuff like Trello just seems too basic for typical enterprise workflows that overlap sprint planning, with project roadmap, milestones and change requests, mapping of tickets to source code, pull requests, documentation,...
If I have decision power, I will always pick the Atlassian product suit versus the competition.
Before I got to use Jira for the first time around 2006, everything I used before was crap, either in-house solutions out of CGI scripts or crap like ClearQuest.
Stuff like Trello just seems too basic for typical enterprise workflows that overlap sprint planning, with project roadmap, milestones and change requests, mapping of tickets to source code, pull requests, documentation,...
If I have decision power, I will always pick the Atlassian product suit versus the competition.
I think those of us who have had to suffer through ClearQuest, Lotus notes etc have an entirely different scale on how bad things can be compared to those who appear to really really hate Jira today. I'm not a fan of Jira but atleast it loads, eventually.
Those things were like 20 years ago ? JIRA is working years old. We’ve developed better more simple issue trackers since, such as GitHub issues and projects. Much simpler.
It is like Google Docs vs Office.
Good for casual users, while at the enterprise level everyone wants a different set of 90% Jira features.
It is no accident that Microsoft is turning GitHub into an ecosystem that combines Azure DevOps with GitHub.
Good for casual users, while at the enterprise level everyone wants a different set of 90% Jira features.
It is no accident that Microsoft is turning GitHub into an ecosystem that combines Azure DevOps with GitHub.
>Same here, I really don't get the cargo cult hate against Jira.
That's funny, because I've always thought of Jira's most ardent defenders as a cargo cult. As this comment section indicates, Jira can do no wrong. It can only be done wrong. Cult.
That's funny, because I've always thought of Jira's most ardent defenders as a cargo cult. As this comment section indicates, Jira can do no wrong. It can only be done wrong. Cult.
Jira is like democracy, it isn't perfect and is full of flaws, yet it still is better than the alternatives.
> yet it still is better than the alternatives.
Not in my experience. I'd much rather use GitHub issues or a range of similar products. Finding and searching works well. Performance is good. Organization is feasible. Labels work fine for customization.
> Jira is like democracy, it isn't perfect and is full of flaws, ...
Using a pithy cross-disciplinary metaphor to try to bolster support for an argument doesn't do much for me.
I would appreciate, on the other hand, if you elaborated on the details of other alternatives you've tried and what problems you've seen.
Not in my experience. I'd much rather use GitHub issues or a range of similar products. Finding and searching works well. Performance is good. Organization is feasible. Labels work fine for customization.
> Jira is like democracy, it isn't perfect and is full of flaws, ...
Using a pithy cross-disciplinary metaphor to try to bolster support for an argument doesn't do much for me.
I would appreciate, on the other hand, if you elaborated on the details of other alternatives you've tried and what problems you've seen.
I mentioned on the previous comment, but it was labeled as Jira cult.
Developing software for 30+ years.
Before Jira came to be, in-house stuff based in Perl CGIs, Lotus, DOORS. ClearQuest, Bugzilla, among others.
After Jira came to be, Trello, GitHub, Azure DevOps, TFS.
None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
Developing software for 30+ years.
Before Jira came to be, in-house stuff based in Perl CGIs, Lotus, DOORS. ClearQuest, Bugzilla, among others.
After Jira came to be, Trello, GitHub, Azure DevOps, TFS.
None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
> Developing software for 30+ years.
Cool. Similar over here, though admittedly not with source control or bug trackers for that long. :)
> None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
I think I see where you are coming from. But Jira's cost (efficiency, complexity, confusion about how to use them, etc) for all these integrations is tremendous. It is easily to make a tremendously better user experience over Jira, even with a pile of integrations.
And yes, I understand that building software for enterprises can be demoralizingly painful and frustrating. To paraphrase another quote, I like everything about enterprise software except the enterprise part. I find the general claimed philosophy of "we are risk averse" often is insincere, a rationalization for inefficiency, and a confusion about what risk means over different time scales. Sure, constant churn is risky. But falling into a pattern of not trying new things inevitably leads to stagnation. Better to have some failures than never to try.
Cool. Similar over here, though admittedly not with source control or bug trackers for that long. :)
> None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
I think I see where you are coming from. But Jira's cost (efficiency, complexity, confusion about how to use them, etc) for all these integrations is tremendous. It is easily to make a tremendously better user experience over Jira, even with a pile of integrations.
And yes, I understand that building software for enterprises can be demoralizingly painful and frustrating. To paraphrase another quote, I like everything about enterprise software except the enterprise part. I find the general claimed philosophy of "we are risk averse" often is insincere, a rationalization for inefficiency, and a confusion about what risk means over different time scales. Sure, constant churn is risky. But falling into a pattern of not trying new things inevitably leads to stagnation. Better to have some failures than never to try.
> None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
Indeed. Often less is more. Your comment may inadvertently be making my point for me. :)
For example, a hyperlink (implied is fine, added in a view is fine) between a commit message and a ticket in my view, is possibly the perfect level of integration.
Integration does not have to (nor should it) mean poor performance or usability.
Indeed. Often less is more. Your comment may inadvertently be making my point for me. :)
For example, a hyperlink (implied is fine, added in a view is fine) between a commit message and a ticket in my view, is possibly the perfect level of integration.
Integration does not have to (nor should it) mean poor performance or usability.
I think the problem is not what it does or solve. I have used jira in 8 companies, maintained an instance in 2 of them and I have never seen a fast one nor figured out to make them fast.
Any single click you do on it reminds you of the time when people were waiting literally minutes to be able to do anything when booting windows on a laptop with 5400rpm hard disk.
Whatever help it is for your company, it makes you pay for it with billions of swears.
Any single click you do on it reminds you of the time when people were waiting literally minutes to be able to do anything when booting windows on a laptop with 5400rpm hard disk.
Whatever help it is for your company, it makes you pay for it with billions of swears.
Trac has been around nearly as long as Jira and I'd much rather use it.
> Trello just seems too basic for typical enterprise workflows
This is essentially it.
The developer facing UI of Jira's competitors is MILES ahead of Jira.
Jira's "director level" UI is miles ahead of its competitors.
This is essentially it.
The developer facing UI of Jira's competitors is MILES ahead of Jira.
Jira's "director level" UI is miles ahead of its competitors.
I agree. I routinely explore JIRA replacements b/c of various JIRA annoyances, but none of the ones I find will hook into our process as neatly as JIRA.
JIRA is a lot like agile though where everyone is using a different version ranging from this works fine, to this is a dumpster fire.
JIRA is a lot like agile though where everyone is using a different version ranging from this works fine, to this is a dumpster fire.
JIRA is the medium that cranky devs interact with disinterested managers. It's just a vessel for data and metadata. And as far as I'm concerned it's one of the best at doing what it does. There's no tool I prefer to JIRA. Asana is a joke by comparison. TFS is just Bad JIRA. Issue trackers like Trello or GitHub issues are fine for creating a dumping ground for ideas but not for organizing.
If you can get away with less structure than JIRA affords then congratulations for not having a budget or timeline but the rest of us need some deniability. Every other problem in the world of software projects is human and can't be solved with tickets.
If you can get away with less structure than JIRA affords then congratulations for not having a budget or timeline but the rest of us need some deniability. Every other problem in the world of software projects is human and can't be solved with tickets.
> Issue trackers like Trello or GitHub issues are fine for creating a dumping ground for ideas but not for organizing.
There’s an argument that you should use an issue tracking system for tracking issues and not planning. Features and stories don’t necessarily neatly subdivide into tasks and issues. Issues don’t always neatly fit into a story or feature.
There’s an argument that you should use an issue tracking system for tracking issues and not planning. Features and stories don’t necessarily neatly subdivide into tasks and issues. Issues don’t always neatly fit into a story or feature.
I’m not sure what “the usual complaint” about Jira is. It sounds like you perceive the usual complaint to be about feature bloat. You only briefly mention speed, which is the only complaint I had about using Jira as an IC developer. From the perspective of an IC I think all these systems are incredibly similar. Jira is the only one that was, very simply, ridiculously slow. As in 5-10 seconds to load any page.
I'm not sure that is quite the right take. When someone says "Jira" they are referring to the style of product management that Jira enables, not the specific tool. Like how "Google" is used to refer to web search, even if one actually uses Bing.
Jira, the software, is far from perfect, but when one talks about hating Jira, they are really talking about the people who use Jira. The same people moving over to a competing product that offers the same feature set perfectly implemented would still leave people hating it. The software itself doesn't matter that much here. It's a people problem.
So, why do people cling to a project management style that everyone hates? There is a lot of friction. Nobody wants to be the guy who pushed for an alternative that turns out to be just as bad. "Nobody ever got fired for buying IBM", as they say. You know that IBM will deliver a failure, so everyone is ready when it does fail. If you hired Mom and Pop, you are doing so expecting them to be better than IBM, so when they fail equally there is a buildup of blame to go around. That's not a comfortable position to be in.
I would suggest that winds of change are in the air, but it is indeed a slow process to find a critical mass willing to take new risks.
Jira, the software, is far from perfect, but when one talks about hating Jira, they are really talking about the people who use Jira. The same people moving over to a competing product that offers the same feature set perfectly implemented would still leave people hating it. The software itself doesn't matter that much here. It's a people problem.
So, why do people cling to a project management style that everyone hates? There is a lot of friction. Nobody wants to be the guy who pushed for an alternative that turns out to be just as bad. "Nobody ever got fired for buying IBM", as they say. You know that IBM will deliver a failure, so everyone is ready when it does fail. If you hired Mom and Pop, you are doing so expecting them to be better than IBM, so when they fail equally there is a buildup of blame to go around. That's not a comfortable position to be in.
I would suggest that winds of change are in the air, but it is indeed a slow process to find a critical mass willing to take new risks.
>It's always taken on from the position of "well, it didn't make my specific use case easy", but never with an appreciation with some of the complexity that Jira needs to solve for other users
Your insight is the same reason why people hate boarding selection for planes, or McDonalds breakfast ending at 10:30am or fill in the blank.
Your insight is the same reason why people hate boarding selection for planes, or McDonalds breakfast ending at 10:30am or fill in the blank.
> the organization-wide problem Jira is trying to solve
Yeah that problem is that in many places management sucks and can't trust their developers to get shit done, so you have to put metrics on it to bring down anxiety brought about by incompetence.
There are large open source projects that don't use jira; the extreme complexity of managing a distributed team with all sorts of interests -geneally even more complex than what a company has to deal with- is empirically doable without jira.
When an organization pivots to using jira it is a sign that their managers are no longer capable of respecting the programmers that work for them. If an organization starts out using jira, that means they never were.
To be charitable I'm sure there are a few corner cases where a manager came up through the ranks and "only knew jira" but that really means they don't understand open source IC, especially in the era of GitHub and gitlab issues.
(Btw GitHub issues is absolutely the thing that is slowly replacing jira)
Yeah that problem is that in many places management sucks and can't trust their developers to get shit done, so you have to put metrics on it to bring down anxiety brought about by incompetence.
There are large open source projects that don't use jira; the extreme complexity of managing a distributed team with all sorts of interests -geneally even more complex than what a company has to deal with- is empirically doable without jira.
When an organization pivots to using jira it is a sign that their managers are no longer capable of respecting the programmers that work for them. If an organization starts out using jira, that means they never were.
To be charitable I'm sure there are a few corner cases where a manager came up through the ranks and "only knew jira" but that really means they don't understand open source IC, especially in the era of GitHub and gitlab issues.
(Btw GitHub issues is absolutely the thing that is slowly replacing jira)
Jumping on the "Jira isn't the problem" bandwagon, 99% of what people hate about Jira now is that the people who manage it make Jira hard to deal with.
I'm at an early startup and we use Jira; it's great because I'm an admin and I can make Jira reflect whatever I need it to reflect.
It's also highly compatible with compliance nonsense -- if you can say, "Every change to code is tracked in Jira" (the decision process not the literal diff) the auditor's eyes glaze over and they just move on.
I'm at an early startup and we use Jira; it's great because I'm an admin and I can make Jira reflect whatever I need it to reflect.
It's also highly compatible with compliance nonsense -- if you can say, "Every change to code is tracked in Jira" (the decision process not the literal diff) the auditor's eyes glaze over and they just move on.
> building a generic project management and tracking tool is a really difficult, hard problem
I would say building a good one is an impossible problem, because of conflicting needs both across and within companies. The primary job of Jira isn't to help work get done. It's to give managers and executives feelings of knowledge and control even when that makes everything worse.
You don't need fancy planning systems to get good work done. Indeed, I think it's the opposite. I've done many years of work with only index cards. E.g.: https://williampietri.com/writing/2015/the-big-board/
As Poppendieck has talked about, we live in a "Tyrrany of the Plan" age, but that's not necessary and it often makes things worse: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
I think this has happened because of the rise of managerialism, where management becomes a self-justifying caste. : https://en.wikipedia.org/wiki/Managerialism
I would say building a good one is an impossible problem, because of conflicting needs both across and within companies. The primary job of Jira isn't to help work get done. It's to give managers and executives feelings of knowledge and control even when that makes everything worse.
You don't need fancy planning systems to get good work done. Indeed, I think it's the opposite. I've done many years of work with only index cards. E.g.: https://williampietri.com/writing/2015/the-big-board/
As Poppendieck has talked about, we live in a "Tyrrany of the Plan" age, but that's not necessary and it often makes things worse: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
I think this has happened because of the rise of managerialism, where management becomes a self-justifying caste. : https://en.wikipedia.org/wiki/Managerialism
>>"You don't need fancy planning systems to get good work done"
I mean, as a single individual, in some circumstances, sure.
If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that?
Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.
I mean, as a single individual, in some circumstances, sure.
If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that?
Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.
I'll ask you the reverse. What proof is there we absolutely need all this to function? If people are so sure of this, surely they can substantiate it with more than just rationality. If the similarities are fine, just pull that information from the other disciplines you insist know better than the "special snowflakes".
>Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing
You're conflating "needing to align thousands of people" with "needing a fancy system which pulls everyone in its web to deal with multiple times a day". If anything, construction shows just how little ICs need to know to function. You don't boggle your construction workers with bureaucracy, you take it away and let architects, managers and foremen deal with it.
>Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing
You're conflating "needing to align thousands of people" with "needing a fancy system which pulls everyone in its web to deal with multiple times a day". If anything, construction shows just how little ICs need to know to function. You don't boggle your construction workers with bureaucracy, you take it away and let architects, managers and foremen deal with it.
If you've worked in large construction, you'll realize just how many project managers large projects need to function.
There are an incredible amount of project managers running from place to place on a construction project keeping teams in line. Construction work, design blueprints, government regulator, there are SO many teams and SO many project managers running between them.
JIRA is absolutely a net positive in that environment. A centralized system like JIRA alleviates that.
There are an incredible amount of project managers running from place to place on a construction project keeping teams in line. Construction work, design blueprints, government regulator, there are SO many teams and SO many project managers running between them.
JIRA is absolutely a net positive in that environment. A centralized system like JIRA alleviates that.
You haven't addressed the part where the ICs have to be part of the system so thoroughly. You've only addressed that project managers need to communicate with one another and with their teams, and you've only done so by using anecdotal evidence, before drawing a conclusion that JIRA is a net positive.
Again, give some actual proof. It's about time we stop clashing rationalities and face the music. If it's this easy to come to a "rational conclusion", it shouldn't be much harder to pull evidence.
Again, give some actual proof. It's about time we stop clashing rationalities and face the music. If it's this easy to come to a "rational conclusion", it shouldn't be much harder to pull evidence.
It is an issue in all fields. The reason why we have delays in major infrastructure projects and why software projects are notoriously hard to plan both boil down to unplanned and unexpected changes to requirements. The fact that it’s easy to change software makes it that much more vulnerable to last minute requirement changes. If something is exactly the same we can just reuse existing software and we don’t call that “development”. It simply becomes “buying” instead. And that makes most software development explorative in nature. Now tell me how many explorative real world, non-software projects have a well-adhered to and exact plan.
You're exactly right about software being exploratory, but I think the whole notion of fixed, up-front requirements is part of the problem.
In the lean analysis, the problem isn't changing requirements, which is a natural consequence of changing circumstances and people learning over time. The problem is building up a large inventory of poorly-tested, underinformed plans and then doing a lot of work based on them without taking advantage of the opportunities to learn.
Especially here on HN, we know that startups don't succeed because they come up with a fixed initial plan and then spend years marching to it. Instead we have all set of techniques for releasing early and often so we can see what really works for users. A key competitive advantage for startups is how their fast OODA loops allow them to run rings around larger companies that slowly drift into being very plan-based.
In the lean analysis, the problem isn't changing requirements, which is a natural consequence of changing circumstances and people learning over time. The problem is building up a large inventory of poorly-tested, underinformed plans and then doing a lot of work based on them without taking advantage of the opportunities to learn.
Especially here on HN, we know that startups don't succeed because they come up with a fixed initial plan and then spend years marching to it. Instead we have all set of techniques for releasing early and often so we can see what really works for users. A key competitive advantage for startups is how their fast OODA loops allow them to run rings around larger companies that slowly drift into being very plan-based.
I was talking about software, not spaceships. Software, being soft, is fundamentally different.
However, you should watch the Poppendieck talk I linked. The Empire State Building had construction start before they finished designing it. The waterfall hallucination, where people imagine perfect results come from perfect plans perfectly executed, has been hugely enabled by software. But if we look at the actual results of heavily planned activities, like buildings, roads, and weapons development, the track record is terrible.
So if modern planning techniques don't work well even in areas, like construction, that they are most suited for, then it should be no surprise that people are skeptical when they are applied to domains that are very different, like software.
However, you should watch the Poppendieck talk I linked. The Empire State Building had construction start before they finished designing it. The waterfall hallucination, where people imagine perfect results come from perfect plans perfectly executed, has been hugely enabled by software. But if we look at the actual results of heavily planned activities, like buildings, roads, and weapons development, the track record is terrible.
So if modern planning techniques don't work well even in areas, like construction, that they are most suited for, then it should be no surprise that people are skeptical when they are applied to domains that are very different, like software.
I agree, but wish/think this can change if the product is good enough.
Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it.
It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.
Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it.
It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.
I hope you're right, but I'm suspicious. For the ones I know well there, they worked because the didn't need permission from the powerful Git, Slack, and Docker were definitely like that in the early days. But planning systems are chosen by the powerful and cater to their needs first.
There are plenty of minimal planning tools out there. Github issues, for example. Or I use KanbanFlow quite a bit. But having driven adoption of simple tools, I think you at least need an environment of benign neglect, as with a skunkworks project, or a tech project at a non-tech company. From what I've seen, in a lot of companies systems like Jira are too entrenched and too visible to management to allow for guerilla-style adoption of something that's more developer/worker friendly.
There are plenty of minimal planning tools out there. Github issues, for example. Or I use KanbanFlow quite a bit. But having driven adoption of simple tools, I think you at least need an environment of benign neglect, as with a skunkworks project, or a tech project at a non-tech company. From what I've seen, in a lot of companies systems like Jira are too entrenched and too visible to management to allow for guerilla-style adoption of something that's more developer/worker friendly.
Yes this is exactly right, it’s all about top down feeling of control. You can very easily manage even a large organization with just basic Kanban boards
> why don't you think some other company has come along and toppled the Jira crown?
Because the people who get to decide whether or not to use JIRA aren't the people who it causes the most suffering for.
Because the people who get to decide whether or not to use JIRA aren't the people who it causes the most suffering for.
[deleted]
+1 to all this. Plus, Jira *scales* - all the cutesy drag-and-drop tools are good for 100 tickets/issues/etc and then fall over.
JQL and bulk edit are just warming up at 1,000 tickets.
JQL and bulk edit are just warming up at 1,000 tickets.
You must have been using some alternate-universe Jira. The Jira installations I've had to suffer with fall over bulk editing a handful of issues. I've never seen a "bulk edit" like feature implemented as poorly as it is in Jira. It shouldn't take 15 seconds to complete a simple bulk edit of a handful (single-digits) of issues.
For the most part, I agree.
But...
If the UX wasn't garbage I'd defend it, too. It has a lot of nice features and integrations. But the UX changes they have made in the recent past (few years-ish), made it worse, for me.
And, in my opinion, the reason some other company hasn't come along and toppled it: critical mass. It's the same reason Epic is king in the hospital IT world. The UI/UX can be garbage (and it's so much worse with Epic than with JIRA), but organizations will still stick with it, because it's what they know.
But...
If the UX wasn't garbage I'd defend it, too. It has a lot of nice features and integrations. But the UX changes they have made in the recent past (few years-ish), made it worse, for me.
And, in my opinion, the reason some other company hasn't come along and toppled it: critical mass. It's the same reason Epic is king in the hospital IT world. The UI/UX can be garbage (and it's so much worse with Epic than with JIRA), but organizations will still stick with it, because it's what they know.
It's not that I think is a particularly good or bad implementation of project management software (though I think as others have pointed out, in its effort to be all things to all people, I think it has converged on a lowest common denominator solution). I reject the concept of general purpose project management software. I think that at best these tools are primarily surveillance tools for middle management. They disempower workers and make them fungible. The workers are evaluated on tool points rather than the actual value they create (sometimes these may be alignment, but often they are not). At worst, I think they actually lower product quality because of the poor incentives that are inherent in a system that rewards closing issues and creating "features".
I believe the best workers (at both the management and IC level) are not going to want to waste a significant chunk of their professional lives in Jira world and the worst workers just want to keep their paycheck coming every month so they will just submit to it and keep cashing their checks. The organization will thus rot and converge on the lowest common denominator employee, which is indeed what the tool kind of promised: fungible, low skill workers with predictable (low) output.
I believe the best workers (at both the management and IC level) are not going to want to waste a significant chunk of their professional lives in Jira world and the worst workers just want to keep their paycheck coming every month so they will just submit to it and keep cashing their checks. The organization will thus rot and converge on the lowest common denominator employee, which is indeed what the tool kind of promised: fungible, low skill workers with predictable (low) output.
You need SOME kind of tool to provide a repository of issues and assignments, and Jira could probably be fine.
But the simplest things are baffling in Jira. Any issue-tracking system that requires the users to learn some obscure syntax (or even to use SQL to refer to its internal data structures is a failure.
But the simplest things are baffling in Jira. Any issue-tracking system that requires the users to learn some obscure syntax (or even to use SQL to refer to its internal data structures is a failure.
> "Jira is the worst project management tool, except for all the others"
This is key. The problem with Jira is less about Jira as a tool and more about how we approach project management.
I've seen some teams thrive with Jira. I wouldn't say they "loved" Jira but they had a light weight project management structure that let them get work done and enough control over Jira to set it up to stay out of their way. They didn't give Jira credit for their ease of working because it was their processes that were good. Jira just gave them a way to not have to write everything down on paper.
I've seen other organizations create a horrible project management structure and then use Jira to "enforce" those structures in ways that magnify all the worst aspects of what they are doing. In those situations it is usually more politically palatable to blame Jira rather than the management processes. Those type of organizations usually blame the tool while hoping that a different tool will force the organizational changes that are needed to make life better.
This is key. The problem with Jira is less about Jira as a tool and more about how we approach project management.
I've seen some teams thrive with Jira. I wouldn't say they "loved" Jira but they had a light weight project management structure that let them get work done and enough control over Jira to set it up to stay out of their way. They didn't give Jira credit for their ease of working because it was their processes that were good. Jira just gave them a way to not have to write everything down on paper.
I've seen other organizations create a horrible project management structure and then use Jira to "enforce" those structures in ways that magnify all the worst aspects of what they are doing. In those situations it is usually more politically palatable to blame Jira rather than the management processes. Those type of organizations usually blame the tool while hoping that a different tool will force the organizational changes that are needed to make life better.
> why don't you think some other company has come along and toppled the Jira crown?
Jira is the way it is because Jira ISN'T built for developers.
Devs may have to use Jira, but they're not the ones who have to pay for it.
I wrote about this a while back:
"Who is Jira’s target customer? It’s certainly not the poor developer who struggles to add a link to his bug report. (I’m still mad at them)
Take a look at Jira’s site and see what they emphasize:
Those pages glamorize having an overview of what work your employees are doing. It’s a tool made for managers. Especially higher level ones. The VP won’t be filing work items, but they’ll be very interested in the insights those dashboards offer.
Jira spends all their software cycles building new features for that VP, ignoring what you and I might consider critical user bugs."
Source: https://www.zainrizvi.io/blog/never-focus-on-the-user#jira-s...
Jira is the way it is because Jira ISN'T built for developers.
Devs may have to use Jira, but they're not the ones who have to pay for it.
I wrote about this a while back:
"Who is Jira’s target customer? It’s certainly not the poor developer who struggles to add a link to his bug report. (I’m still mad at them)
Take a look at Jira’s site and see what they emphasize:
Those pages glamorize having an overview of what work your employees are doing. It’s a tool made for managers. Especially higher level ones. The VP won’t be filing work items, but they’ll be very interested in the insights those dashboards offer.
Jira spends all their software cycles building new features for that VP, ignoring what you and I might consider critical user bugs."
Source: https://www.zainrizvi.io/blog/never-focus-on-the-user#jira-s...
Which is funny because 99% of what project managers seem to be about is making sure work gets done. So the first thing they do is deploy a hurdle to this by ensuring they use a tool which is time consuming and confusing for the people who do the work (usually developers to use) and enforce it's usage.
JIRA is so slow and the UI so clunky the project managers where I work use some type of spreadsheet upload mechanism with XML spreadsheets to automate the cruft creation. It's fun to watch.
JIRA is so slow and the UI so clunky the project managers where I work use some type of spreadsheet upload mechanism with XML spreadsheets to automate the cruft creation. It's fun to watch.
> Which is funny because 99% of what project managers seem to be about is making sure work gets done
Unfortunately, from the project manager's perspective the emphasis is on the words making sure
And Jira lets them think they're doing that
Unfortunately, from the project manager's perspective the emphasis is on the words making sure
And Jira lets them think they're doing that
I agree this is where it goes wrong. Chasing an nice looking burn down chart.
The issue is that software developers (correctly) identify the burndown chart as useless due to estimation in software being a joke.
Software developers' mistake is not realizing that "linking the tickets" into Epics that managers can search is hugely important.
If the project director has no clue about what tickets people are working on things go south fast.
All developers should agree on that.
Software developers' mistake is not realizing that "linking the tickets" into Epics that managers can search is hugely important.
If the project director has no clue about what tickets people are working on things go south fast.
All developers should agree on that.
They don’t because no matter how well my tasks are mapped to tasks it rarely reflects reality.
The only reason stuff gets done as it should it because me and my peers are responsible, and because we have a good understanding of what needs to be done, not because of how things are mapped in JIRA.
The only reason stuff gets done as it should it because me and my peers are responsible, and because we have a good understanding of what needs to be done, not because of how things are mapped in JIRA.
I was asked during a merger, which work management tool do you think we should keep/use? I replied, don't ask me, I'll hate it anyways.
It's not because I hate Agile, Scrum, or even Waterfall (although I do hate SAFe). I just know these tools all suffer from similar drawbacks, and somebody will ultimately codify all our organizational problems into the tool. Then, rather than spend an hour a week of their own time, they'll create a new mandatory field and ask thousands of people to spend an hour a week each populating that field.
It's not because I hate Agile, Scrum, or even Waterfall (although I do hate SAFe). I just know these tools all suffer from similar drawbacks, and somebody will ultimately codify all our organizational problems into the tool. Then, rather than spend an hour a week of their own time, they'll create a new mandatory field and ask thousands of people to spend an hour a week each populating that field.
Sounds like a strong argument for using a tool that doesn't have custom mandatory fields. They do exist.
I think the answer to your question is that it's because the complaints aren't actually mostly about the tool, but about the processes the tool targets. Jira competes both with different tools and with different processes that use neither Jira nor its competitors.
I worked at a company once (not programming, more like an online shop) which did everything via email. And I mean everything. Tickets, issues, orders, repair requsts, refunds, you name it.
It worked flawlessly — in fact I haven't been at a place that was as well organized since. And it all came down to one thing: everybody understood that there is only email and that if it isn't an email it will be forgotten and fall in some crack, so you better make it an email, that has a propper subject, is searchable, etc. That meant everybody was writing emails with nearly military rigour, while the asynchronous nature of the electronic letter always reminded you, that you just needed your emails done and then you were fine. Depending on your position you had multiple (shared) inboxes that corresponded to the tasks. Of course there were some old emails, that were more of a "if anybody finds the time and will" type and sometimes emails from the guy from the day before had to be done etc. But all in all it was surprisingly pleasant to work just with email.
The point of the story is: You can turn any tool to shit if people use it in a bad way. And you can make anything work if people use it in the right way. Most problems with communications are people-problems, not tool-problems. Sure certain tools may lend themselves to certain behavior more than to others but ultimately a team can decide how they wanna communicate effectively and which behavior produces chaos and problems.
It worked flawlessly — in fact I haven't been at a place that was as well organized since. And it all came down to one thing: everybody understood that there is only email and that if it isn't an email it will be forgotten and fall in some crack, so you better make it an email, that has a propper subject, is searchable, etc. That meant everybody was writing emails with nearly military rigour, while the asynchronous nature of the electronic letter always reminded you, that you just needed your emails done and then you were fine. Depending on your position you had multiple (shared) inboxes that corresponded to the tasks. Of course there were some old emails, that were more of a "if anybody finds the time and will" type and sometimes emails from the guy from the day before had to be done etc. But all in all it was surprisingly pleasant to work just with email.
The point of the story is: You can turn any tool to shit if people use it in a bad way. And you can make anything work if people use it in the right way. Most problems with communications are people-problems, not tool-problems. Sure certain tools may lend themselves to certain behavior more than to others but ultimately a team can decide how they wanna communicate effectively and which behavior produces chaos and problems.
What was the size of the company?
Generally speaking any organisation, given enough time, can establish processes that are better than JIRA with a certain amount of luck.
However, that's the best case scenario.
It's a standard distribution. Sometimes a 100 person project gets by fine with email. Sometimes it all goes to shit.
A tool like JIRA is, on average, a lot better than doing it via email only.
Generally speaking any organisation, given enough time, can establish processes that are better than JIRA with a certain amount of luck.
However, that's the best case scenario.
It's a standard distribution. Sometimes a 100 person project gets by fine with email. Sometimes it all goes to shit.
A tool like JIRA is, on average, a lot better than doing it via email only.
Small, 20 people maybe, but a lot of remote people that had their own small "domains" within the project. Sometimes one "domain" had multiple shifts (e.g. shipping). Communication between shifts was just done by writing yourself an email.
Granted, such a thing would not scale up to infinity, but for that size it was perfect and extremely hackable (just email + SMTP after all).
Granted, such a thing would not scale up to infinity, but for that size it was perfect and extremely hackable (just email + SMTP after all).
> Obviously some of the complaints (speed, stability) are very valid, but here's a question I think is just as valid: why don't you think some other company has come along and toppled the Jira crown? Certainly tons of them have tried, and while many have their supporters, they are almost equally likely to have their detractors.
Trello was a much better solution to the problem, that's why Atlassian made sure to buy it and is now hard at work ruining it.
Trello was a much better solution to the problem, that's why Atlassian made sure to buy it and is now hard at work ruining it.
I think the issue is that because Jira offers the hope of a tractable customizable management process, it invites management to put in more process to improve their visibility of a project. This should not result in micromanagement, but it usually does. From a programmer's vantage point this is lose-lose, because your day to day tasks are weighted down by Jira-related bureaucracy, and your mastery of your schedule is continuously threatened by managers peering down from above to ask questions about this and that individual item on your work list.
I suppose its a necessary evil for an organization of a certain scale, but for whatever reason, I've chosen to work in teams that are small enough that we can dispense with JIRA all together.
I suppose its a necessary evil for an organization of a certain scale, but for whatever reason, I've chosen to work in teams that are small enough that we can dispense with JIRA all together.
Totally agree with this argument, INCLUDING almost making the same Churchill quotation joke at the end.
Additionally, people's associations with Jira are not strictly related to the software itself.
Jira is often the domain of PMs, management, and other leadership; if you have bad people / product leaders, you're used to Jira being a source of great stress.
Jira is often the domain of PMs, management, and other leadership; if you have bad people / product leaders, you're used to Jira being a source of great stress.
Honestly, the app called Shortcut is the Jira killer. It really is that good.
I really, really love Shortcut. Unfortunately our org is looking for a traditional Gantt chart, and Shortcut is a bit lacking in that.
However, up to this point in our company, it's been great. It's very deliverable-centered. Stories are the deliverables and are the centerpiece of the flow. Tasks just make up a to-do checklist for a story - there's no endless wrangling about that is a task, there's no credit for doing a task (shitty devs can't game the system). Shortcut feels like it hits a nice spot between the monster that is Jira and too-basic tools like Trello. Shortcut is made for developers.
However, up to this point in our company, it's been great. It's very deliverable-centered. Stories are the deliverables and are the centerpiece of the flow. Tasks just make up a to-do checklist for a story - there's no endless wrangling about that is a task, there's no credit for doing a task (shitty devs can't game the system). Shortcut feels like it hits a nice spot between the monster that is Jira and too-basic tools like Trello. Shortcut is made for developers.
>The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve.
The problem being: "how to create BS data and metrics to satisfy a bureucracy"?
The problem being: "how to create BS data and metrics to satisfy a bureucracy"?
"I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve."
What is that problem exactly?
What is that problem exactly?
Maybe they are trying to solve too many problems with one piece of software.
For really large, complex enterprises managing a complex portfolio of products with dependencies between them I have found Rally to be a little better than Jira. It isn't any simpler or faster than Jira, but it's better at tying the whole enterprise effort together.
https://www.broadcom.com/products/software/value-stream-mana...
https://www.broadcom.com/products/software/value-stream-mana...
The developer facing UI of Jira's competitors is MILES ahead of Jira. Trello etc.
Jira's "director level" UI is miles ahead of its competitors.
Jira's "director level" UI is miles ahead of its competitors.
There is the saying that a poor workman blames his tools. (Sorry for the sexism, but let's assume were all guys for this.)
I claim something more specific. A totally powerless workman who's afraid of his bosses blames his tools.
An individual in the face of indomitable authority blames anything else.
Jira is a wonderful proxy for all the bureaucracy and *managers you hate. So hate Jira, because you're powerless to change anything that matters.
I claim something more specific. A totally powerless workman who's afraid of his bosses blames his tools.
An individual in the face of indomitable authority blames anything else.
Jira is a wonderful proxy for all the bureaucracy and *managers you hate. So hate Jira, because you're powerless to change anything that matters.
the funniest thing to me is that you used a throwaway to defend Jira .
But yea, I agree, they are trying to solve a huge problem. And good on them for it. I still dislike the results though, and that's ok. We still use it.
But yea, I agree, they are trying to solve a huge problem. And good on them for it. I still dislike the results though, and that's ok. We still use it.
A few years ago I worked for a company that used https://shortcut.com/ (at that point, it was named clubhouse I think). I loved it. I think that tool can do everything Jira does in a much better and saner way. It looks a lot more organised, more flexible, more polished, more performant and it doesn't look like it will force you into full SCRUM if you don't want to. You even get to use the same syntax (markdown!) everywhere. Last time I had to use Jira I needed to keep in mind the syntax for writing links in the issue description was different than the syntax for writing links in comments. Tell me that's not some top level suckery.
Jira sucks big time, and there are better tools now. The reason no one "toppled the Jira crown" is just inertia, specially management inertia who are the ones deciding what tool to use. For the same reason we're still mostly using petrol for cars, not because there aren't better options, it is because it is not easy to change.
Jira sucks big time, and there are better tools now. The reason no one "toppled the Jira crown" is just inertia, specially management inertia who are the ones deciding what tool to use. For the same reason we're still mostly using petrol for cars, not because there aren't better options, it is because it is not easy to change.
Jira drives me crazy. Why do I need to mark an epic as closed two different ways? Why is it really difficult to see what tickets were in a closed sprint? Why is it so slow or why does it sometimes get in infinite reload loop? Features randomly break like the ability to create tickets from confluence. My company is locked in and I doubt we would change, I just wish Atlassian focused on performance and consistency
I’m starting to wonder if one of the best features of Jira is that it directs all of the developer hatred away from management and toward the task-management software. I’ve worked on projects that used Jira very effectively, so I’m convinced that all of the complainers actually not fully aware of how bad their managers are.
JIRA configs are usually the visible manifestation of your organisation's processes. It's Conway's law applied to task management workflows.
I don't remember Jira as being that bad.
It was mostly the Scrummy culture that seemed like a bit of a waste of time.
I wasn't a big fan of the wysiwyg editor. This seems to address mostly non-technical people. I would always go for "Markdown with preview" (HackMD split-screen, or GitHub issue tabs, or Discord apply-formatting-to-codes).
I also don't like that it isn't an integrated part of a pull request system. GitHub/Gitea issues inter-linking with PRs in the same namespace is... golden. With the right habits, you can become an effective time-traveler.
It was mostly the Scrummy culture that seemed like a bit of a waste of time.
I wasn't a big fan of the wysiwyg editor. This seems to address mostly non-technical people. I would always go for "Markdown with preview" (HackMD split-screen, or GitHub issue tabs, or Discord apply-formatting-to-codes).
I also don't like that it isn't an integrated part of a pull request system. GitHub/Gitea issues inter-linking with PRs in the same namespace is... golden. With the right habits, you can become an effective time-traveler.
I was one of the Jira admins two jobs ago (in additional to more normal responsibilities of product management & engineering). I finally got back to Jira at my current company and I texted an ex-colleague who was also an admin of the same Jira server (also part-time):
"We're starting the migration to Jira. The next sprint will be entirely in Jira. Honestly, I kind of missed it."
She replied: "That's the real test of a tool. Not 'would you recommend it to a friend?', but 'if you were to start a company, would you use it again?'"
And - I would and did with Jira. If you know the tool well, and your company doesn't have stupid technical workflows and human processes, it's just great. Too many people suffered from using it wrong or suffered from using it with the wrong colleagues.
"We're starting the migration to Jira. The next sprint will be entirely in Jira. Honestly, I kind of missed it."
She replied: "That's the real test of a tool. Not 'would you recommend it to a friend?', but 'if you were to start a company, would you use it again?'"
And - I would and did with Jira. If you know the tool well, and your company doesn't have stupid technical workflows and human processes, it's just great. Too many people suffered from using it wrong or suffered from using it with the wrong colleagues.
What's the secret of making it acceptably responsive? Asking for a friend.
From what I've read it's the cloud hosted version that's slow. Seems to be fine locally hosted, and probably if you host yourself with another cloud provider.
Unless by "responsive" you mean works well on tiny screen devices...
The self-hosted version is discontinued and you can't buy it any more if you aren't already a customer.
Incorrect. The cheapest license version is discontinued, ”server”. Data center license is not.
Guessing that's prohibitively expensive for smaller shops though? There's remarkably little info on Atlassian's site about the difference between server and data center license...
Examples escape me at the moment, but there have honestly been so many times I've hit a wall trying to do - what seem to me like - basic things in JIRA; I couldn't comprehend how such a complex tool could not accommodate them.
And the stuff that can be done is often so comically painful it's mind-blowing. Trying to do something as seemingly simple as create a useful saved search in JIRA is so painful I can't imagine its creation was not an act of sabotage.
And the stuff that can be done is often so comically painful it's mind-blowing. Trying to do something as seemingly simple as create a useful saved search in JIRA is so painful I can't imagine its creation was not an act of sabotage.
Due to the slow loading, I ended up writing some simple Jira API wrapper scripts for submitting bug reports quicker in our systems. I don't see our organisation switching anytime soon.
> Also LOL to SourceTree. The git command line commands aren’t exactly rocket science.
This one caught me off guard. I know of no other free GUI for git that's as easy to use or install.
This one caught me off guard. I know of no other free GUI for git that's as easy to use or install.
<!--
Atlassian, please don't sue me.
"<!-- Atlassian, please don't sue me. -->"
One real benefit of Jira is that almost everything else out there has an importer for Jira. We chose to move from FogBugz to Jira ~3 years ago, in part because we knew if it didn't end up working for us, it would be relatively easy to move to another platform.
Many of the competitors don't fully understand this. They offer importers for Jira, but not an *exporter to* Jira. It's a pretty hard sell to even consider something else if I know I'm going to be stuck there. I wrote the tools for FogBugz to Jira migration and it took a stupid amount of time to do.
FYI: FogBugz provided a Jira exporter but it was abandoned (much like FogBugz as a whole), and was totally unusable for the migration.
Many of the competitors don't fully understand this. They offer importers for Jira, but not an *exporter to* Jira. It's a pretty hard sell to even consider something else if I know I'm going to be stuck there. I wrote the tools for FogBugz to Jira migration and it took a stupid amount of time to do.
FYI: FogBugz provided a Jira exporter but it was abandoned (much like FogBugz as a whole), and was totally unusable for the migration.
I also hate:
The gray text. Cmon, we have a roomful of ppl and 1 monitor.
Subtasks fuck up the whole layout. And appear above everything.
Suggestions that only include the 1st N values from a list. You have to know what youre searching for.
Can't preview fakeSprint until it's started.
No easily-available view of each developer's workload.
The gray text. Cmon, we have a roomful of ppl and 1 monitor.
Subtasks fuck up the whole layout. And appear above everything.
Suggestions that only include the 1st N values from a list. You have to know what youre searching for.
Can't preview fakeSprint until it's started.
No easily-available view of each developer's workload.
OK, so what don't I like about Jira?
1. It's extremely slow.
2. It's difficult to predict the effect of making any kind of change.
3. The permissions system is so convoluted, I can be the admin of a board, and yet not have permission to see a ticket on it.
4. It relegates the conversation to a second-class UI element, when this is the most important part of any project management system.
5. Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time.
6. Every Jira setup is so different, trying to compare a piece of work from one area of the organisation to a similar piece of work elsewhere is useless.
7. The UI is extremely buggy. I can add a mandatory field to a ticket, then when I try to use a shortcut to create a new ticket, it won't work because I can't fill out that mandatory field.
8. There are random side-effects when one person does something on one bit of the system, and VOILA everybody's workflow is broken, with no obvious warning that would happen.
1. It's extremely slow.
2. It's difficult to predict the effect of making any kind of change.
3. The permissions system is so convoluted, I can be the admin of a board, and yet not have permission to see a ticket on it.
4. It relegates the conversation to a second-class UI element, when this is the most important part of any project management system.
5. Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time.
6. Every Jira setup is so different, trying to compare a piece of work from one area of the organisation to a similar piece of work elsewhere is useless.
7. The UI is extremely buggy. I can add a mandatory field to a ticket, then when I try to use a shortcut to create a new ticket, it won't work because I can't fill out that mandatory field.
8. There are random side-effects when one person does something on one bit of the system, and VOILA everybody's workflow is broken, with no obvious warning that would happen.
I still can’t figure out how to search it
This is a solved problem. The most efficient way to search Jira is to type random characters into the search bar until you find the ticket you were looking for on page 3 of the results.
I just wrote the search query to our PM, since I was unable to find anything myself... I don't understand why just couldn't use, IDK, a shared spreadsheet, even that would be more productive (from my perspective)
Find the person in your organization who knows JIRA. After he doesn't manage to find it, open outlook and search for it in the notifications@jira folder, where you would most likely find it
9. The text editor is still busted and I just don't understand why. It's one of the most important parts of the UX, please please fix it. Writing any kind of nicely formatted long form posts is a lost cause.
At the very least, use the same markup language for both Confluence and Jira.
Jira/Confluence Cloud use the same markup and editor.
But neither supports a markup language AFAIK. They used to support Markdown but they dropped that long ago and never replaced it. Now the only choice is their garbage WYSIWYG editor.
Jira isn't great but the Confluence editor causes me more frustration than anything. And good luck getting anything in or out of Confluence with their document model.
Confluence is definitely their worst product. It's like they took the idea of a Wiki, but removed all it's good aspects and then combined it with a terrible CMS system. A competitor could just use an ancient WikiWikiWeb installation and be better.
Amusingly, it used to be great! When I first started using JIRA, it was just markdown. Then they introduced their WYSIWYG editor, but at least they still had the button to see the raw markdown and you could still edit the raw markdown (but the GUI made terrible markdown so if you wanted to use markdown you better start with that and never touch the GUI).
And then I guess at some point they just removed the markdown part?
And then I guess at some point they just removed the markdown part?
It boggles the mind. Who made that call? What were their reasons?
markdown is too hard for product people
Definitely this 100% I proposed for company game night: Predict where the Jira cursor goes next in response to right arrow. There’s so many possibilities: right left up down, teleports, disappears. My favorite is when the cursor splits into two at two different seemingly unrelated locations. Two cursors?? How do you even do that in a text area?
My gripe for the text editor—if you navigate away from the page, by an accidental click or keypress, all your text is lost. This kind of thing was solved 15 years ago; it's table stakes!
My favourite gripe about text editing in Jira is that the ticket body and ticket comments require subtly different formatting mark-up, and the wysiwyg widgets for formatting are also ever-so-slightly different.
This results in a fun game of me trying out single backticks, triple backticks, braces, double braces, other miscellaneous punctuation symbols, and various indents before giving up and trying the formatting toolbar, only to waste another couple of minutes clicking around to see what works.
Somehow I can never remember what worked either, so I find myself repeating this ridiculous dance on at least a weekly basis.
Although IIRC, there was a recent update that at least harmonised the code formatting syntax between editors, although I can't remember if it actually worked....
This results in a fun game of me trying out single backticks, triple backticks, braces, double braces, other miscellaneous punctuation symbols, and various indents before giving up and trying the formatting toolbar, only to waste another couple of minutes clicking around to see what works.
Somehow I can never remember what worked either, so I find myself repeating this ridiculous dance on at least a weekly basis.
Although IIRC, there was a recent update that at least harmonised the code formatting syntax between editors, although I can't remember if it actually worked....
> This results in a fun game of me trying out single backticks, triple backticks, braces, double braces, other miscellaneous punctuation symbols, and various indents before giving up and trying the formatting toolbar, only to waste another couple of minutes clicking around to see what works.
I thought I was the only one who is annoyed with this. Not only that, but the editor when you first create the ticket and the one used to later edit it are different too. I can't think of any sane technical reason that might explain using more than one rich text editor.
I thought I was the only one who is annoyed with this. Not only that, but the editor when you first create the ticket and the one used to later edit it are different too. I can't think of any sane technical reason that might explain using more than one rich text editor.
So frustrating! Not sure if it's just in team-managed projects, but they look to have fixed this, e.g Description field maintains a draft across page-loads, until you hit save now :)
This is my biggest gripe.
I make an effort to write detailed comments about what I did, what I discovered etc. This is really helpful to reproduce the issues, and a few months down the line it helps to clarify exactly what happened.
JIRA text editor is FUCKED. Try adding bullet points after a code insertion. Does not work. I have to first create all the bullets, then step through them and write out whats on my mind. For more complex stuff, I just write in my code editor. How can you fuck up the most basic functionality?!
I make an effort to write detailed comments about what I did, what I discovered etc. This is really helpful to reproduce the issues, and a few months down the line it helps to clarify exactly what happened.
JIRA text editor is FUCKED. Try adding bullet points after a code insertion. Does not work. I have to first create all the bullets, then step through them and write out whats on my mind. For more complex stuff, I just write in my code editor. How can you fuck up the most basic functionality?!
The worst thing is that I nod along in agreement with all 9 points, and still find myself easily preferring a pragmatic well set up Jira (yes a unicorn) to juggling things around 25 trello boards or a siloed top down micromanaging corporate hellscape overconfigured Jira.
But the last time I enjoyed using Confluence was in the 1.x days with non wysiwyg wiki markup. Confluence been truly awful for a while now - eg why can't I ever find what I'm searching for?
But the last time I enjoyed using Confluence was in the 1.x days with non wysiwyg wiki markup. Confluence been truly awful for a while now - eg why can't I ever find what I'm searching for?
In defense of complex permissions, this often ends up being necessary to avoid single points of failure. For example, if someone can turn off the setting preventing force push to the master/main branch, that person should not be able to commit code thereby requiring more than one person for a commit to be force pushed in practice. Even better would be to require a config change like that to be approved by more than one person, but that can be difficult to implement compared to adding in narrow permissions. Even if you just prevent force pushing in general, another common bypass would be disabling CI for certain commits (such as in cases where the CI infrastructure is down and the commit is necessary to fix some ongoing incident). Yes trusting developers is always going to be necessary to some degree, but that doesn't mean absolute trust is required all the time.
For your specific example of not being able to see tickets as admin, I imagine that feature was added for teams where sensitive information is stored in the ticketing system for things like user reported issues. User reported issues often has PII or other personal data and while developers need to see that information, admins often don't. When I worked at a bank, any remotely sensitive columns in the database were either inaccessible to developers by configuration or by encrypting them to and from client code when the DB didn't support column level permissions (while Sybase could manage column level permissions, Mongo and Elasticsearch didn't at the time).
For your specific example of not being able to see tickets as admin, I imagine that feature was added for teams where sensitive information is stored in the ticketing system for things like user reported issues. User reported issues often has PII or other personal data and while developers need to see that information, admins often don't. When I worked at a bank, any remotely sensitive columns in the database were either inaccessible to developers by configuration or by encrypting them to and from client code when the DB didn't support column level permissions (while Sybase could manage column level permissions, Mongo and Elasticsearch didn't at the time).
That's the thing about Jira.
I don't understand why I can't see a ticket on my board because some team in another company once requested a seemingly unrelated feature. It's trying to be too many things to too many companies all at the same time, and thus ends up as an unusable mess of complex settings.
I don't understand why I can't see a ticket on my board because some team in another company once requested a seemingly unrelated feature. It's trying to be too many things to too many companies all at the same time, and thus ends up as an unusable mess of complex settings.
> Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time.
Have you used the bulk issue change tool? The UI isn't necessarily very user-friendly but I would not label it as requiring a lot of time, I actually feel it works quite well for this use case.
Have you used the bulk issue change tool? The UI isn't necessarily very user-friendly but I would not label it as requiring a lot of time, I actually feel it works quite well for this use case.
Awesome list and objective.
I'd like to add another point:
#. There are too many "views" or ways of visualizing the work that needs to be done, ie the plan view and the kanban view, my issues etc.
If I'm not looking at the 'right' view I'll miss something and maybe get in trouble from project management.
I'd like to add another point:
#. There are too many "views" or ways of visualizing the work that needs to be done, ie the plan view and the kanban view, my issues etc.
If I'm not looking at the 'right' view I'll miss something and maybe get in trouble from project management.
Wait until you use notion. I’ve been forced to use it for the last year, and I miss jira. I never thought I’d say this, but I really do miss it.
[deleted]
Jira is practically called out in the phoenix project. Their solution?
1. Don’t use it
2. Do a manual process
3. Get buy in and deliver actual value
4. Run into scalability issues
5. Now automate which could be Jira but now you know what value your process is achieving
6. Don’t let Jira be the end in itself. Focus on the value of the process and tune that
https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
1. Don’t use it
2. Do a manual process
3. Get buy in and deliver actual value
4. Run into scalability issues
5. Now automate which could be Jira but now you know what value your process is achieving
6. Don’t let Jira be the end in itself. Focus on the value of the process and tune that
https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
Jira is as good or bad as you configure it to be. It's a tool. We long ago learned how to use JavaScript effectively despite its numerous flaws. If you're at an organization where you have to use Jira, surely you can find a way to make it work.
That said, it's certainly not the Right Answer for everyone. But unilaterally hating on it is just kinda childish.
That said, it's certainly not the Right Answer for everyone. But unilaterally hating on it is just kinda childish.
You cannot really configure Jira so that the interface is free of lags and loads faster, though. Or that it does not make tons of network requests in the background. It's a tool, but there are bad also tools.
Maybe the web is/was shit for this kind of application which has caused it to become the beast it is.
The main problem with Jira is that it echoes the people who manage it almost perfectly. Crappy Management = Jira Hate, but it's really Manager Hate. I figured this out at my last job. Then I left.
Ooh ooh! Now do git.
I fucking hate JIRA because it encourages people to create and abandon tickets for years, creating an alternate dimension of irrelevant trash that gets in the way of doing things.
If your team has an append-only doctrine to information, like most tech debt mills in the industry have, JIRA will become an extension of that ever increasing pile of unmaintained, disgusting, revolting monolith of excrement that captures every activity in software development.
Nothing can be done about the gigantic monolith of soul crushing chaos therefore we need to embrace it, at the expense of our sanity. Nothing can be done about the hopeless hoarding of irrelevant, duplicate tickets that distract people from work.
JIRA makes it very easy to create new tickets, and much harder to close them. So naturally it becomes a virtual sewer. JIRA is about being able to present a large amount of information to easily impressionable people so that so some people can justify their job.
If your team has an append-only doctrine to information, like most tech debt mills in the industry have, JIRA will become an extension of that ever increasing pile of unmaintained, disgusting, revolting monolith of excrement that captures every activity in software development.
Nothing can be done about the gigantic monolith of soul crushing chaos therefore we need to embrace it, at the expense of our sanity. Nothing can be done about the hopeless hoarding of irrelevant, duplicate tickets that distract people from work.
JIRA makes it very easy to create new tickets, and much harder to close them. So naturally it becomes a virtual sewer. JIRA is about being able to present a large amount of information to easily impressionable people so that so some people can justify their job.
I wanted to make a site very similar to this but for Jenkins. Even bought a domain for it.
And never built the thing.
Some of these made me chuckle.
And never built the thing.
Some of these made me chuckle.
I suspect issue tracking software is one of those domains where if a piece of code hangs around for long enough it will become a mess due to incentives. Which begs the question: What are y'all's opinion on the open source competitors? Redmine, OpenProject, Apache Bloodhound, and whatever else exists?
I used to like JIRA, back when it was only issues/tickets. It was essentially a nice, organized database for humans that you could sift through with precise filters & searches. Bug applies here, workflow describes where handling it is in the pipeline, issue types meant you could filter by "what is this", etc.
I loved using "basic" JIRA, mentioning issue IDs in places to clearly reference a web of "why this bit of code is the way it is", so someone digging into source code can self-answer stuff like "why not do X". (e.g.: because it caused a bug for Y)
Now there's stories, and boards, and sprints, and agile, and the worst part is that they all interact like crap. Why do "tasks" and "stories" exist? Why not the old: New Feature, Bug, Improvement? At least with those you could always see at a glance what that issue is.
I loved using "basic" JIRA, mentioning issue IDs in places to clearly reference a web of "why this bit of code is the way it is", so someone digging into source code can self-answer stuff like "why not do X". (e.g.: because it caused a bug for Y)
Now there's stories, and boards, and sprints, and agile, and the worst part is that they all interact like crap. Why do "tasks" and "stories" exist? Why not the old: New Feature, Bug, Improvement? At least with those you could always see at a glance what that issue is.
I don't. I use it every day and rarely ever have an issue. It's well integrated with Confluence. There's even some decent CLI tools now (still young but have promise) that mean we could automate away the interface.
All the reviews I see on that site seem to be upset that it might require training, or that their project's admins have made it a nightmare. It's not a nightmare out of the box.
All the reviews I see on that site seem to be upset that it might require training, or that their project's admins have made it a nightmare. It's not a nightmare out of the box.
What I really hate is not Jira itself, it's the company behind it and its engineering practices. Their mediocrity goes beyond Jira.
They've had server-side-rendered features that while slow, contained the slowness to the backend and bundled it into one single slow request - once you waited for that, you had a fully-working page in your browser. Since it was all on the backend, your browser remained responsive while waiting.
Nowadays however there's no longer a single operation to wait for - they've split their pile of shit and offloaded it to your browser. You have to wait for the backend which is slow, but then you also have to wait for megabytes of JS to load & execute in your browser, all while the page moves around and your CPU is pegged at 100%. And God help you if you click on something by accident, as "undoing" that means waiting for another load. To add insult to injury, everything is clickable and triggers some actions, even elements that represent content and that you wouldn't normally expect to be clickable (nor would want to - let's say you wanted to copy the text).
Recently they've added another annoyance - in Bitbucket they've done some changes with regards to diff rendering and obviously have to let you know. They do so via a persistent floating popover in the bottom-left of the screen that you have to manually dismiss and the dismissal status seems to be contained to the browser - if you switch browsers or use private mode you have to deal with it continuously.
My experience with Atlassian products has actually deteriorated despite CPU speeds, browser performance & network connections improving. I used to have a mostly positive opinion of the company 5 years ago but that's no longer the case.
They've had server-side-rendered features that while slow, contained the slowness to the backend and bundled it into one single slow request - once you waited for that, you had a fully-working page in your browser. Since it was all on the backend, your browser remained responsive while waiting.
Nowadays however there's no longer a single operation to wait for - they've split their pile of shit and offloaded it to your browser. You have to wait for the backend which is slow, but then you also have to wait for megabytes of JS to load & execute in your browser, all while the page moves around and your CPU is pegged at 100%. And God help you if you click on something by accident, as "undoing" that means waiting for another load. To add insult to injury, everything is clickable and triggers some actions, even elements that represent content and that you wouldn't normally expect to be clickable (nor would want to - let's say you wanted to copy the text).
Recently they've added another annoyance - in Bitbucket they've done some changes with regards to diff rendering and obviously have to let you know. They do so via a persistent floating popover in the bottom-left of the screen that you have to manually dismiss and the dismissal status seems to be contained to the browser - if you switch browsers or use private mode you have to deal with it continuously.
My experience with Atlassian products has actually deteriorated despite CPU speeds, browser performance & network connections improving. I used to have a mostly positive opinion of the company 5 years ago but that's no longer the case.
I think calling Atlassian mediocre is a bit generous. Confluence is a steaming pile of burn garbage that still can't get basic thing's like SVG working[1]. Atlassian can't give a darn, they have their captive market and they are just riding the gravy train now. The last good thing they did seems to be to buy trello, but they will likely turn it into garbage if the rest of their portfolio is any indication of what to expect.
[1]: https://jira.atlassian.com/browse/CONFSERVER-1762
[1]: https://jira.atlassian.com/browse/CONFSERVER-1762
> The last good thing they did seems to be to buy trello, but they will likely turn it into garbage if the rest of their portfolio is any indication of what to expect.
Either that (turn it into a "JIRA Light", with just a little less of the annoyances?) or just kill it off altogether -- either way, it eliminates the competition from what Trello used to be.
Which was of course precisely why they bought it, so them doing that was actually not at all a good thing.
Either that (turn it into a "JIRA Light", with just a little less of the annoyances?) or just kill it off altogether -- either way, it eliminates the competition from what Trello used to be.
Which was of course precisely why they bought it, so them doing that was actually not at all a good thing.
That diff message is really annoying indeed, but that is not the only thing that leaves in the browser session. I have set up my browse to be wipe clean every time I close it, and a lot of things like PR notification for update also live in the session. So if I reopen the browser all the PR are marked with blue circle.
I don’t like Jira, though I can its positive points, but Bitbucket is just the worst tooling I have ever had the displeasure to work with. I can’t believe a single developer in Atlassian actually uses that.
> company behind it and its engineering practices. Their mediocrity goes beyond Jira.
100% agree. Bamboo bitbucket, confluence, Jira all of them made my development workflow worse.
I don’t like Jira, though I can its positive points, but Bitbucket is just the worst tooling I have ever had the displeasure to work with. I can’t believe a single developer in Atlassian actually uses that.
> company behind it and its engineering practices. Their mediocrity goes beyond Jira.
100% agree. Bamboo bitbucket, confluence, Jira all of them made my development workflow worse.
It appeals to companies that think they only have to pay for one tool. It's awful for agile work but your boss sees the "agile" tickbox and says "fine"
In my experience, Jira is the dog that begins to resemble its owner. If you are working in a toxic, dysfunctional organization, Jira will reflect that:
- Giant forms with dozens upon dozens of nonsensical fields (preferably with abbreviations as names, like "IFE App.") half of which are required so you just stuff random words in them to make it shut up
- Thousands of tickets that would probably take 30+ software devs 100+ years to implement
- Can't find your project because your project's name is nonsense (also preferably with abbreviations)
- Task descriptions have hundreds of words of nonsensical boilerplate but don't actually say anything at all
- 50 different ways each to say "Finished", "Started" or "Abandoned"
- Workflow state transitions reminiscient of the outdoor maze in The Shining (crazy man with axe optional)
- Giant forms with dozens upon dozens of nonsensical fields (preferably with abbreviations as names, like "IFE App.") half of which are required so you just stuff random words in them to make it shut up
- Thousands of tickets that would probably take 30+ software devs 100+ years to implement
- Can't find your project because your project's name is nonsense (also preferably with abbreviations)
- Task descriptions have hundreds of words of nonsensical boilerplate but don't actually say anything at all
- 50 different ways each to say "Finished", "Started" or "Abandoned"
- Workflow state transitions reminiscient of the outdoor maze in The Shining (crazy man with axe optional)
One I found particularly annoying was having too many hierarchical levels for taks. Something like : Client, Contract, Deliverable, Product, Release, Change Request, Requirement, Task, Sub-tasks
> - Thousands of tickets that would probably take 30+ software devs 100+ years to implement
I feel like the company I'm working for has a reasonable attitude towards Jira, and they recently just batch closed all tickets that were older than some date in many projects. So you'd have to actively re-open tickets you had created to keep them alive, if needed. Great decision IMO.
It's an interesting exercise to be forced to deal with old tickets you've created. It gets you thinking.. "well, this thing should probably be done at some point, but then if it's actually important we'll probably think of it again and can re-create the ticket then". Might give you experience that encourages you to be careful when creating new tickets too.
I feel like the company I'm working for has a reasonable attitude towards Jira, and they recently just batch closed all tickets that were older than some date in many projects. So you'd have to actively re-open tickets you had created to keep them alive, if needed. Great decision IMO.
It's an interesting exercise to be forced to deal with old tickets you've created. It gets you thinking.. "well, this thing should probably be done at some point, but then if it's actually important we'll probably think of it again and can re-create the ticket then". Might give you experience that encourages you to be careful when creating new tickets too.
We've automated this in our propriety system. After an amount of time with no activity, change requests expire and someone can resubmit if they're still valid, otherwise they close after a number of days. They also get a notification in advance in case they want to investigate validity before expiration. Has worked well for us since our software is decades old and the number of change requests are substantial.
I worked somewhere where there
were 500 backlog tickets that disappeared and reappeared depending on the ethos of the current team leader.
Closing issues without actually fixing them is depressing. It may be beneficial overall.
There could be alternatives e.g., label such task as "fun" and hide them all the views by default, then allow developers to spent say 10% on any of "fun" task of their choosing (no expectations).
It may help with burn-out for some devs and the issues that are worth fixing according to at least by some devs are getting closed eventually.
There could be alternatives e.g., label such task as "fun" and hide them all the views by default, then allow developers to spent say 10% on any of "fun" task of their choosing (no expectations).
It may help with burn-out for some devs and the issues that are worth fixing according to at least by some devs are getting closed eventually.
I've probably said this before here but I just don't see what was wrong with Bugzilla. We spent years getting it honed to suit a good bug lifecycle model. Everything since has been fubar one way or another.
Jira isn't perfect, but it fit our agency's needs well enough and the short comings haven't been bad enough to cause us to rethink it.
The truth is that there's very few project management tools out there that offer the flexibility to run individual projects the way an individual team wants to. When you're an agency with hundreds of projects in the system, that's invaluable. I researched 2-3 dozen competitors to find a better solution and there just wasn't. Other than maybe Redmine and its derivatives, which the team basically dismissed for being too outdated.
ETA: I should clarify that I'm using Jira Cloud and we don't have many issues with speed (at least today, anyway. Maybe in a few years, who knows)
The truth is that there's very few project management tools out there that offer the flexibility to run individual projects the way an individual team wants to. When you're an agency with hundreds of projects in the system, that's invaluable. I researched 2-3 dozen competitors to find a better solution and there just wasn't. Other than maybe Redmine and its derivatives, which the team basically dismissed for being too outdated.
ETA: I should clarify that I'm using Jira Cloud and we don't have many issues with speed (at least today, anyway. Maybe in a few years, who knows)
Shout out to the programme manager at my old company. His attitude was "Use jira in the way that works for you". He could set up and modify workflows for me, he had good useful advice, and in total I probably spent 20 minutes a week dealing with jira. Which as a manager of a decent sized team I think is fairly good. As one of the comments on that site said "I'd rather use trello" I disagree, it was much better for having multiple views on things and by standardising across the company it was much easier to just get an informal view on what other teams were doing.
Most of the problems with jira are the people using it.
Most of the problems with jira are the people using it.
So say we all
These people are pampered brats. Try being forced to document all your time and projects in Rally or Version1. You will beg to get Jira back. Software “engineers” are such divas. “I don’t play other people’s song.” As if they are some kind of celebrity.
Its like you can't be fired for buying Microsoft (as an IT purchase decision). You can't be fired for buying JIRA. JIRA makes everything, the most broken or dodgy processes look respectable. It keeps Managers and scrum masters busy. They have a toy to play with, and why not?, why should only devs have toys. I'm not saying I hate JIRA, or that it doesn't work. Its just that sometimes the tail wags the dog.
Not going to read this rant because of time. But let me guess. Jira is a giant time waster. My main problem with Jira though is that it takes a lot of effort to configure it in good way. Jira is a piece of software that comes with plain horrible defaults.
I think Jira development is secretly supported by Microsoft to make sure there's always at least one enterprise software product that developers hate more than Windows
I’ve used it at three companies and thought it was fine. Maybe my tastes aren’t refined enough or something but I thought it was fine.
Confluence is terrible but that’s a different product.
Confluence is terrible but that’s a different product.
For me, the worst part is how the search feature naturally defaults to searching over the entire organization and there is no setting to preserve space preference. I'm sure a product manager or sales person pitched this as a wonderful thing, but in a massive organization I really only want to search within a small number of spaces, over and over again. I rarely, if ever, want to access the entire company's confluence but that's what the search bar does.
You should try VersionOne :) That tool made me appreciate JIRA.
Issue tracking is difficult in general. Any piece of software can be improved or extended in an infinite number of ways. Ideas for improvements are often too eagerly turned into issues, which looks like an easiest way to quickly deal with an idea, but soon issues management becomes an overwhelming activity.
Where I work got rid of Jira and switched to some other, ostensibly better(?) competing product. I never had strong opinions about Jira before the switch, but now, after nearly 2 years of a Jira free existence... I miss Jira dearly. The grass is always greener.
Does Jira suck? sure maybe, but my personal experience suggests that everything else sucks equally as bad if not worse, and I know where all the buttons are in Jira.
Does Jira suck? sure maybe, but my personal experience suggests that everything else sucks equally as bad if not worse, and I know where all the buttons are in Jira.
I've used Jira in my last 3 jobs. I tried to like it, I tried to tolerate it, now I just try to spend as little time using it as possible.
I'm an engineer, I'm a problem solver. I want to add a task, move task to "doing" and then "done" and that's it. But Jira is not created for me. Jira is created for SAFe expert who wants to create workflow so complex nobody understands it. Jira is created for Scrum master who wants to create 25 reports to show their boss how beautifully our burndown looks sprint after sprint. Yes, Jira doesn't force anyone to do this stuff, but it enables it, because Jira is created for process managers, for people who just report things.
But that's not me. Jira is not for me and the best I can do it to use it as little as possible.
I'm an engineer, I'm a problem solver. I want to add a task, move task to "doing" and then "done" and that's it. But Jira is not created for me. Jira is created for SAFe expert who wants to create workflow so complex nobody understands it. Jira is created for Scrum master who wants to create 25 reports to show their boss how beautifully our burndown looks sprint after sprint. Yes, Jira doesn't force anyone to do this stuff, but it enables it, because Jira is created for process managers, for people who just report things.
But that's not me. Jira is not for me and the best I can do it to use it as little as possible.
Not affiliated but linear.app looking good
Jira is a product which serves two masters - one are development teams which use it to track bugs, tickets, projects, etc. The other one are middle management types who use it for project tracking, reporting to upper management, tracking metrics of different teams (no matter how dubious) etc.
The people who decide which software gets adopted internally generally care about the latter, and thus Jira is selected, and thus Jira grows to their needs - where complexity is often a bonus, and poor day to day performance a minimal concern.
The people who decide which software gets adopted internally generally care about the latter, and thus Jira is selected, and thus Jira grows to their needs - where complexity is often a bonus, and poor day to day performance a minimal concern.
Ironically, most of the stuff seems to be about Confluence. And almost all of the commentary is about bad company workflows and bad company processes and not really about the product itself at all.
I can't take credit for this, but I also don't recall where I heard/read it from:
"Most teams would be better off using a shared spreadsheet for task management than they would using Jira"
Rings true to me to this day.
"Most teams would be better off using a shared spreadsheet for task management than they would using Jira"
Rings true to me to this day.
part of the hatred has to come from the fact that it's a tool used for hidden micromanagement. Whenever I experienced Jira being introduced into the workflow, human connection vanished, work became laboring and many times the better devs left the team due to lack of autonomy. Who remained were the people who didn't mind to just work and never question, like factory workers of the 1900's.
I don't mind using Jira as a verbose platform which aims to map project state and helps communication BETWEEN all participants, but this is rarely the case, especially with all those pseudo-agile practices that are part of mainstream software development.
Another part of the hatred may come from the fact that it's an overcomplicated tool for a moderately simple task. This complexity is standing in the way most of the time. I just want a simple board for a simple project with simple issues/user stories/whatevers and update their state which gets reflected on the board. For additional features i want to install/write a plugin and that's it. If I need a manual for software in 2022 it's either trash or something far from mainstream (in which case complexity and/or lack of ux might be acceptable).
I don't mind using Jira as a verbose platform which aims to map project state and helps communication BETWEEN all participants, but this is rarely the case, especially with all those pseudo-agile practices that are part of mainstream software development.
Another part of the hatred may come from the fact that it's an overcomplicated tool for a moderately simple task. This complexity is standing in the way most of the time. I just want a simple board for a simple project with simple issues/user stories/whatevers and update their state which gets reflected on the board. For additional features i want to install/write a plugin and that's it. If I need a manual for software in 2022 it's either trash or something far from mainstream (in which case complexity and/or lack of ux might be acceptable).
The worst thing about jira is it leaves the door open for confluence which is the actual worst thing.
Thankfully my company built its own internal tool similar to Jira. Unfortunately this is not the case for other companies or smaller companies since it can be cost-prohibitive.
Jira is bad, but the worst part about it is that it makes it non-trivially more likely you'll also be using Confluence, which is an absolute blight upon the software landscape.
JIRA is the definition of building everything for everybody and let them customize it, it's got complex and to a point highly productive engineers don't want it anymore, it's a OVERKILL!
I fucking hate software.
Jira should just start configured out of the box to look and work like Trello.
This is the experience team-managed projects should have out of the box in Cloud if using kanban.
You create a kanban team-managed project and it'll pretty much be a Trello board. If you want sprints or a backlog or reports you can go into the project features page and flip a switch.
You create a kanban team-managed project and it'll pretty much be a Trello board. If you want sprints or a backlog or reports you can go into the project features page and flip a switch.
Part of our company started using Click-up. If JIRA is really bad, Click-up is levels worse than it.
I hate JIRA too, but maybe there is no a better thing out there?
Jira works well for my organization. I think the simplicity of our setup is the key. We have just 4 issue statuses: Not Started, In Progress, QA, Done… also no restrictions on state transitions. Any status can move to any other status. Each team gets their own project so that they can easily manage their own issue backlog. That’s pretty much it. My team also uses a plug-in for async planning poker which is useful.
Jira does for software engineering what software engineering does for everything else.
Meh Jira is OK and people who hate Jira I feel like they really hate any process. I've used other tools and they are mostly the same.
I enjoyed working with RT, though someone had gone to the effort of making it easy to use and integrated nicely with IRC (in much the same way we have jira issues in Slack I guess).
In comparison I feel like Jira hides stuff from me, that the UI is excessively slow, that it's easy to get wrong and add oodles of mandatory fields..
In comparison I feel like Jira hides stuff from me, that the UI is excessively slow, that it's easy to get wrong and add oodles of mandatory fields..
Wait until you try Microsoft DevOps boards
I'm fine with Jira now. As long as I don't have to use it that much. I agree about conversation being a second class citizen. I wish I could get integration with my mac notification system more easily. But the positive is that I can do a screen recording and drag and drop that video straight into a comment which is cool
I don't really get the hate to be honest. Maybe it's just me, but our DevOps team seems to have squeezed the best out of Jira. They organized the workflow very well, the Bitbucket Integration is seemless and I can easily get to the builds of my current issue and see what happens there.
The only gripe I have about Atlassian suite is confluence. It's a mess.
I think it really depends on how Jira and the overall workflow is taken care of. For our part, it has been a pretty good experience and the DevOps team used the APIs pretty well and wrote their own tools.
To be honest, I don't have used many other tools, but it seems like our company has made a good choice in configuring the whole system "just right".
I think it really depends on how Jira and the overall workflow is taken care of. For our part, it has been a pretty good experience and the DevOps team used the APIs pretty well and wrote their own tools.
To be honest, I don't have used many other tools, but it seems like our company has made a good choice in configuring the whole system "just right".
Jira was supposed to help us do the work, not become the work.
We have at least three people employed who's sole responsibility is to pester people about ticket status, apply bulk changes in Jira, define conventions, and ultimately make life harder for individual teams who wanna follow their own processes. As an EM, my higher-ups would rather have me ensuring ticket status is perfect to the T instead of pairing with and assisting my engineers.
I kid you not, we have directors of engineering who spend half their working day making bump/nudge comments on tickets.
We have at least three people employed who's sole responsibility is to pester people about ticket status, apply bulk changes in Jira, define conventions, and ultimately make life harder for individual teams who wanna follow their own processes. As an EM, my higher-ups would rather have me ensuring ticket status is perfect to the T instead of pairing with and assisting my engineers.
I kid you not, we have directors of engineering who spend half their working day making bump/nudge comments on tickets.
I hate BitBucket more!
Is there a way (setting?) to completely disable keyboard shortcuts (hotkeys) on Jira sites?
After spending some time with Trac, Redmine and IBM ClearCase, I have to say that Jira and MS AzureDevOps are not THAT tragic. However it's a tool targeted at managers, not us, developers. At my previous company one of the KPIs was a number of closed Jira issues. Total BS, needless to say.
I agree that Jira isn't wonderful, but I can't think of any of any task management system that I have used, that I would recommend.
Are GitHub Issues the answer? I have only tried those for small open source projects and not big enterprise projects.
Are GitHub Issues the answer? I have only tried those for small open source projects and not big enterprise projects.
The people hating on JIRA never worked in a shop without it.
If you're old enough to remember before Atlassian came along - just how was it better? Spreadsheets? Trax?
You don't want structured workflow? Don't work in a company with more than 5 people.
"I am an accountant and hate ERP" .. tough shit, for real.
If you're old enough to remember before Atlassian came along - just how was it better? Spreadsheets? Trax?
You don't want structured workflow? Don't work in a company with more than 5 people.
"I am an accountant and hate ERP" .. tough shit, for real.
For the first 20 years of my career I worked with organizations that used Gantt charts and MS project combined with a dedicated project manager to keep things in sync with actual progress. It was minimally invasive to engineers and didn't require them to do the soul-sucking JIRA dance. It also generally delivered dozens of projects on time or with reasonable delays and surprises.
Even when working on 'buckets of tasks/bugs' where Gantt charts don't make sense, a locally customized version of Bugzilla or other bug tracking software(i.e. Phabricator or whatever) worked very well.
There is a generation of engineers that has only known Agile, 2 week sprints, and shitty software to manage it. After having used Jira at two companies for the last 4 years I can say it is one of the worst pieces of software I have ever been forced to use and lowers productivity from multiple angles.
Even when working on 'buckets of tasks/bugs' where Gantt charts don't make sense, a locally customized version of Bugzilla or other bug tracking software(i.e. Phabricator or whatever) worked very well.
There is a generation of engineers that has only known Agile, 2 week sprints, and shitty software to manage it. After having used Jira at two companies for the last 4 years I can say it is one of the worst pieces of software I have ever been forced to use and lowers productivity from multiple angles.
Just be glad you don't have to use VersionOne.
Anyone who's coped with VersionOne will nope back to Jira in a hot second.
Anyone who's coped with VersionOne will nope back to Jira in a hot second.
My Jira experience improved a lot when I wrote a tool that parses and serves the content of HTTP Archive files - not having to wait for all those panels, menus etc. was a huge boon, even if this view was necessarily read-only.
Also I'm pretty sure Jira saved my friend's marriage because he used the free version to coordinate finishing up their house.
Lastly while JQL has limited capabilities, it's better than having a bunch of API endpoints.
That being said it still baffles me how badly some UI elements are done there. Especially the menus would benefit greatly from some caching or preloading.
Also I'm pretty sure Jira saved my friend's marriage because he used the free version to coordinate finishing up their house.
Lastly while JQL has limited capabilities, it's better than having a bunch of API endpoints.
That being said it still baffles me how badly some UI elements are done there. Especially the menus would benefit greatly from some caching or preloading.
The problems with Jira can be extended to the rest of Atlassian and all of their offerings. Their company culture is very much one of "we're right, no matter how many people bring up the same issues." Things like:
- Shoving political messaging into git terminal messages - Renaming "blame" to something else without notifying the userbase ("annotate"? It's been a while) because, despite "blame" being a git term, its usage hurt someone's feelings (yes, seriously, even though no proof or elaboration has ever been provided) - Not fixing a bug for 6+ years where, if someone's typing a comment and accidentally hit the escape key, the entire post gets deleted with no option to recover it (I'm not sure if this ever actually was resolved)
That said, for a while, Jira had a lot of good things going for it. But by now, enough competitors have popped up with similar offerings that are easier to use without all of the unnecessary self-importance buried within it.
For a Jira alternative specifically, I've been using Linear.app for the last 8 months and enjoying it overall
- Shoving political messaging into git terminal messages - Renaming "blame" to something else without notifying the userbase ("annotate"? It's been a while) because, despite "blame" being a git term, its usage hurt someone's feelings (yes, seriously, even though no proof or elaboration has ever been provided) - Not fixing a bug for 6+ years where, if someone's typing a comment and accidentally hit the escape key, the entire post gets deleted with no option to recover it (I'm not sure if this ever actually was resolved)
That said, for a while, Jira had a lot of good things going for it. But by now, enough competitors have popped up with similar offerings that are easier to use without all of the unnecessary self-importance buried within it.
For a Jira alternative specifically, I've been using Linear.app for the last 8 months and enjoying it overall
Annotate was the SVN term, have you considered it might just pre-date git?
That's interesting. This change certainly came post-SVN. I don't recall that ever being used as an explanation, though. Still, quite a silly thing to do based on the presumption that a benign word hurt a hypothetical person's feelings
Git actually also has annotate: https://git-scm.com/docs/git-annotate
That's not the same as blame, though, which is the functionality that was renamed in Atlassian's products
I promise I am not a shill: Our team is on the verge of switching 100% to ClickUp. Are we crazy?
Nobody really loves Jira, and we've gotten our Product, Design, Sales, and Customer Success teams using ClickUp and everyone is really happy so far (especially with the speeeeeeeeeeed. OMG coming from Jira it's a breath of fresh air).
We are chasing the dragoon of having a single tool and everything in one place. So far the eng team seems amenable to give it a shot (although we're going to transition slowly).
Are we crazy?
Nobody really loves Jira, and we've gotten our Product, Design, Sales, and Customer Success teams using ClickUp and everyone is really happy so far (especially with the speeeeeeeeeeed. OMG coming from Jira it's a breath of fresh air).
We are chasing the dragoon of having a single tool and everything in one place. So far the eng team seems amenable to give it a shot (although we're going to transition slowly).
Are we crazy?
[deleted]
Jira's web interface I can live with. I've internalized the workaround for the UI bugs and I've learned to live with the slowness. Sure it reflects all the worst aspects of your organizations structure and process but that's not really it's fault.
What is it's fault is their REST API. In theory it's a well architected API. Follows REST principles. You can tell they read the whitepaper. But you have to jump through a ton of hoops to get any data beyond surface details.
Example: Want to find what epic a User Story is part of? It's a custom field. Which one? depends on how your instance has evolved over time. You'll have to scan through all the fields to find the field id.
This is what happens when an API isn't designed to fulfill a particular need but instead is meant to be infinitely customizable. Ergonomic APIs are impossible.
What is it's fault is their REST API. In theory it's a well architected API. Follows REST principles. You can tell they read the whitepaper. But you have to jump through a ton of hoops to get any data beyond surface details.
Example: Want to find what epic a User Story is part of? It's a custom field. Which one? depends on how your instance has evolved over time. You'll have to scan through all the fields to find the field id.
This is what happens when an API isn't designed to fulfill a particular need but instead is meant to be infinitely customizable. Ergonomic APIs are impossible.
Good. I’d also like one of these but with Citrix.
I tried giving atlassian some feedback recently when they asked for it (via email). Unfortunately the very end of their survey had some fancy widget to upload a recording (which was absolutely unnecessary). The widget didn't load, and because of that the form didn't allow a submission - so I didn't bother figuring out how to give them my feedback, even after i had done a 3 page survey.
I hope it was a widespread issue.
I hope it was a widespread issue.
This is not a rant about Jira. This is a rant about doing Agile in the enterprise.
I can rant about Jira, but it's about the horrible UI. It's buggy. The settings system is a mess. It's not intuitive. Even clever people need hand holding to figure out what's going on. Things randomly break for no apparent reason.
I can rant about Jira, but it's about the horrible UI. It's buggy. The settings system is a mess. It's not intuitive. Even clever people need hand holding to figure out what's going on. Things randomly break for no apparent reason.
Edgy.
if you hate jira try Trello, "the baby version of jira"
Gitlab Enterprise.
It's _far_ from perfect, but Gitlab Issues is a damn sight better than JIRA IMHO...
It's _far_ from perfect, but Gitlab Issues is a damn sight better than JIRA IMHO...
[deleted]
I read some of those rants and almost 50% of them were not rants but people ignorant of features and how they work getting angry. I’m not saying they deserve to be angry, but if a passionate rant can be dismissed by a ”you’re holding it wrong” it isn’t really a rant.
There are tons of real issues like ages old bugs or weird design decisions years ago that make something that feels very sane feel impossible to deliver.
All in all my point is that most of these rants are against knowledge of features/design and misuse by colleagues.
There are tons of real issues like ages old bugs or weird design decisions years ago that make something that feels very sane feel impossible to deliver.
All in all my point is that most of these rants are against knowledge of features/design and misuse by colleagues.
I use Jira for 10, 20 minutes a day every day, and it almost always works just fine. Not spectacular or anything, but just fine.
Not using Jira is a red flag for me, and I won't work for any company that doesn't use Jira. The reason is, Jira is so standard at this point, if a team uses a non-Jira product, they must have an overly powerful CTO or team lead who rules with an iron fist. Sure, it sucks, but working under such conditions is worse.
That’s insane to me. Atlassian pushes very hard for everyone to use the cloud-hosted version, as the on-prem version is hella expensive. You know, that SaaS app that was recently down for over 2 weeks for some customers.[0] I don’t know many companies that would be OK with having no access to their ticket tracker for an indeterminate length of time. Do you have a customer, or worse, regulatory deadline coming up, and all your planning was done in the now-offline tool? Sucks to be you!
[0] https://www.zdnet.com/article/atlassian-estimates-cloud-outa...
[0] https://www.zdnet.com/article/atlassian-estimates-cloud-outa...
Was any data actually permanently lost?
Also looks like they've taken steps to prevent this from happening again.
https://www.zdnet.com/article/atlassian-implements-soft-dele...
Also looks like they've taken steps to prevent this from happening again.
https://www.zdnet.com/article/atlassian-implements-soft-dele...
The downtime only affected a small percentage of accounts, and unless this happens again, this is likely a freak occurrence, and just as likely to happen to any other random cloud service. As for mission-critical data in Jira, it's easier to replicate that to salesforce or something (where it belongs) than switch off of Jira entirely.
Came to the comments hoping to find some solid Jira alternatives "the community" recommends. Sadly not the case. Instead this is my take-away:
* Jira sucks big time, and people hate it.
* There are no other tools that do what jira does, that doesn't also suck.
* After trying Jira alternatives that suck worse, folks move away from the Jira sucks camp to no-longer minding using Jira.
* Jira sucks big time, and people hate it.
* There are no other tools that do what jira does, that doesn't also suck.
* After trying Jira alternatives that suck worse, folks move away from the Jira sucks camp to no-longer minding using Jira.
People here aren't going to bother talking about alternatives because there are thousands, it's just if you work at a company has invested years in trying to figure out JIRA, no one is going to admit it sucks and just let you use something simpler. I've seen many brave soul suggest something different and it didn't end well.
I've seen several comments about alternatives, and many more replies that say they suck worse than Jira.
1. Have a competent trustworthy project manager work with product to come up with a roadmap, you then document the roadmap in a simple easy to read document which is hierarchical, and contains a list of initiatives to fit the roadmap. Under each initiative you can set a status and a target date and importantly, a team or individuals name who is in-charge of the roadmap. Project managers keep this document up to date.
2. Next, don't deploy JIRA here, just make sure everyone, and I mean everyone understands the roadmap and how they fit into it.
3. Work with those in-charge (who actually do the work) can choose their issue tracker of choice, or whatever method they like and the product management team ensures and trusts those they work with will have made the correct decision here.
4. Allow the dev teams to happily work in something simple like GH issues and be productive.
When the product team wants updates, humans get together and talk about each initiative and how it's going.
Simple.
You might ask about tracking cOmPlEx iNtErDePeNdEnCiEs!!! that killer feature JIRA is about solving...I think that can be solved easily by ensuring managers have situational awareness (they should anyway) and everyone having the same issue tracker. For example GH issues so issues can be easily referenced.
2. Next, don't deploy JIRA here, just make sure everyone, and I mean everyone understands the roadmap and how they fit into it.
3. Work with those in-charge (who actually do the work) can choose their issue tracker of choice, or whatever method they like and the product management team ensures and trusts those they work with will have made the correct decision here.
4. Allow the dev teams to happily work in something simple like GH issues and be productive.
When the product team wants updates, humans get together and talk about each initiative and how it's going.
Simple.
You might ask about tracking cOmPlEx iNtErDePeNdEnCiEs!!! that killer feature JIRA is about solving...I think that can be solved easily by ensuring managers have situational awareness (they should anyway) and everyone having the same issue tracker. For example GH issues so issues can be easily referenced.
Love the idea, hate the implementation.
How can it be proper to show me the outcome of applying JQL to a db query but refuse to show me the JQL because of an ownership/acl problem.
Want automation? Chain tasks but it has no "this" or "self" so that last thing you made? Have fun reconnecting to it.
So many options but no way to flatten them and define a template with specific ones: some are baked in and some can't be easily specified as important to float to top.
Still no clean way to uplift org to confluence with native support
How can it be proper to show me the outcome of applying JQL to a db query but refuse to show me the JQL because of an ownership/acl problem.
Want automation? Chain tasks but it has no "this" or "self" so that last thing you made? Have fun reconnecting to it.
So many options but no way to flatten them and define a template with specific ones: some are baked in and some can't be easily specified as important to float to top.
Still no clean way to uplift org to confluence with native support
Yea yea yea...but you still use it because the alternatives while better performing and even more secure...are not as feature rich or as well known.
I feel like this thread comes up in one way or another every few months but in a place where people almost have a hellbent desire to reinvent wheels nobody has reinvented this one in say...go or rails or whatever.
Why? Because for all of the hate jura actually does what it does pretty well when it's working and for most people and most businesses that aren't your homelab it works just fine provided you pay someone to maintain and administer it.
I feel like this thread comes up in one way or another every few months but in a place where people almost have a hellbent desire to reinvent wheels nobody has reinvented this one in say...go or rails or whatever.
Why? Because for all of the hate jura actually does what it does pretty well when it's working and for most people and most businesses that aren't your homelab it works just fine provided you pay someone to maintain and administer it.
Not surprised that many are having a bad user experience with Jira. The interface design and usability is atrocious because it's a tool designed by developers. Developers lack the UX training and thinking that's needed to make the tool intuitive and easy to use.
All the confluence hate speaks to my soul. It's where ideas go to die. If you want to start a successful internal project and someone tells you to start documenting your ideas there, you might as well just move on to something else. Whatever you were going to do is already dead. It's just so ignorable. Nobody gives a shit about a confluence doc. Write up your thoughts and send it as an email to your boss, your peers, whoever. That demands a response and you'll get one, for good or ill! Getting outright rejected is still better than the sad withering away that is putting it into confluence. Anyways, what's the most common signal that people hate confluence? When they use it as a link repository to docs stored elsewhere.
I don’t hate Jira. I strongly dislike working with people who love it. From https://honeypot.net/post/jira-is-a-code-smell/ :
> A useful task manager will be somewhat opinionated. It will almost, but not quite, do what everyone wants, and will annoy everyone equally with the few things they think it does wrong. A tar pit of a task manager will claim to be everything to everyone after customization, meaning that a few people will think it's heavenly and everyone else will despise it with the heat of a thousand suns.
> A useful task manager will be somewhat opinionated. It will almost, but not quite, do what everyone wants, and will annoy everyone equally with the few things they think it does wrong. A tar pit of a task manager will claim to be everything to everyone after customization, meaning that a few people will think it's heavenly and everyone else will despise it with the heat of a thousand suns.
Where is dark mode???
We’re in the midsts of a move to JIRA, and my own previous experiences with it are >10 years old at this point so I assume it to be a different experience and I’m willing to give it a shot. I made a glib JIRA hate comment to a very experienced friend and he retorted with this quip which I found amusing and suspect is probably very accurate:
“There’s only two types of people that hate JIRA: 1) those that haven’t tried any of the alternatives or 2) those that didn’t have a dedicated team to configure and maintain JIRA for them”
“There’s only two types of people that hate JIRA: 1) those that haven’t tried any of the alternatives or 2) those that didn’t have a dedicated team to configure and maintain JIRA for them”
It depends on how it is used. As a bug tracker it is perfectly adequate, and I prefer having all of the information connected to a given issue in one place. It took us some time to get the flows right, but what we have now seems to work well enough. It is certainly better than the crap system we had before we adopted Jira, though that isn't saying much.
Edit: weird that an honest description of personal experience with Jira was downvoted to zero.
Edit: weird that an honest description of personal experience with Jira was downvoted to zero.
Ex project manager (few years Jira experience with local and overseas teams).
I believe a lot of the hate comes from the input rather than the software; aka what others are putting in. If you've got a really bad PM/BA your experience with the platform is going to be negative.
As far as everything else what are the alternatives? Most other platforms are horrible or lacking features.
I believe a lot of the hate comes from the input rather than the software; aka what others are putting in. If you've got a really bad PM/BA your experience with the platform is going to be negative.
As far as everything else what are the alternatives? Most other platforms are horrible or lacking features.
Lacking features is not always a bad thing. I am much happier with github issues than Jira.
And a good PM is to Jira as lipstick is to a pig. It might give the pig redder lips, but that won't make anyone want to kiss it. Even with the best PM Jira still had severe usability issues and bugs that atlassian shows no interest in fixing.
And a good PM is to Jira as lipstick is to a pig. It might give the pig redder lips, but that won't make anyone want to kiss it. Even with the best PM Jira still had severe usability issues and bugs that atlassian shows no interest in fixing.
Problem, is mostly with bad PMs, POs, Scrum masters and all the other potato heads, not Jira itself.
To everyone asking "what else works better," I remember using Product Studio at Microsoft, which was a thin client over an SQL database. It had some flexibility problems, but it was so, so fast. It's the only ticket management system I've ever used that didn't feel like it was getting in the way. Unfortunately, about 10 years ago Microsoft chose to modernize/dogfood on Team Foundation Server, which was just awful, probably worse than JIRA. I have no idea what they're using nowadays.
I wonder if the performance we got out of Product Studio had more to do with having a locally hosted instance, vs. running in the cloud, and I wonder if teams that host their own JIRA/Confluence/Bitbucket servers have a better experience. I do find that one of the major gripes people have with planning tools is that they break flow, and I wonder how much of that comes just from the amount of stamina required to maintain focus while waiting for all the spinners.
I wonder if the performance we got out of Product Studio had more to do with having a locally hosted instance, vs. running in the cloud, and I wonder if teams that host their own JIRA/Confluence/Bitbucket servers have a better experience. I do find that one of the major gripes people have with planning tools is that they break flow, and I wonder how much of that comes just from the amount of stamina required to maintain focus while waiting for all the spinners.
Just a friendly reminder that all Australian software companies are required to install backdoors at any time at the behest of law enforcement.
I used to hate Jira with all the fervor and more. And then one day I discovered go-jira. Jira command line client written in Golang (hence the name). I wrote a few tiny emacs-lisp wrappers: to read the current backlog; to find a ticket; to list all the tickets assigned to me, etc. And that was all great. I realized - I hated Jira's UI, but its API is quite all right.
At some point, our infrastructure engineers changed something that made it difficult to login to Jira without the web interface (I don't remember what that was exactly - SSO or something...), and I wrote a Puppeteer script that would login to Jira [in a headless browser] and grab the token and use it to authenticate with go-jira.
I thought about cleaning up my elisp experimentation and making a proper Emacs package. Sadly, a few month later COVID hit the US and a bunch of us got laid off. At my new job, we don't use Jira, and I never made the package. And I don't miss Jira. And I don't hate it anymore (I think). But yeah, fuck Jira all the same.
At some point, our infrastructure engineers changed something that made it difficult to login to Jira without the web interface (I don't remember what that was exactly - SSO or something...), and I wrote a Puppeteer script that would login to Jira [in a headless browser] and grab the token and use it to authenticate with go-jira.
I thought about cleaning up my elisp experimentation and making a proper Emacs package. Sadly, a few month later COVID hit the US and a bunch of us got laid off. At my new job, we don't use Jira, and I never made the package. And I don't miss Jira. And I don't hate it anymore (I think). But yeah, fuck Jira all the same.
A true hacker! Though not sure what to think about the security of that headless browser setup
I made sure that the credentials are stored in GPG encrypted file and could only be decrypted on my machine. github.com/agzam/jira-okta-puppet/blob/master/src/jira_auth/auth.cljs
Basically, it was no different if I'd have to login manually, then open browser's dev-tools, and copy&paste the token. Arguably, my automated approach made it slightly more secure, since there's no clipboard involved.
It was stupid, I should've figured out the proper way of authenticating, but something was missing, I either needed to ask admin to give me OAuth access, or some other bullcrap. Well, you know how the saying goes, right? "It ain't stupid if it works".
Basically, it was no different if I'd have to login manually, then open browser's dev-tools, and copy&paste the token. Arguably, my automated approach made it slightly more secure, since there's no clipboard involved.
It was stupid, I should've figured out the proper way of authenticating, but something was missing, I either needed to ask admin to give me OAuth access, or some other bullcrap. Well, you know how the saying goes, right? "It ain't stupid if it works".
Org-jira is in melpa and works fine with the new Atlassian token format. So much better and there are a few riders you can add for extra features.
Yes, I am aware of Org-jira, but at the time, I chose to make my own wrapper around go-jira. Unfortunately, I don't remember anymore why exactly I selected that path instead of extending Org-jira package. Perhaps that's a good argument for "every programmer should have a blog". Maybe if I had one, I'd write about the reasons.
I have no doubts that if I ever get to work with Jira again, I am definitely doing it in Emacs (or via some other way that works for me). I am a software developer, not a power user, not a weak user, not an A/B testing subject. If a software vendor forces me to use their product inefficiently because "customers don't know what they want", I am either hacking my way around it or deleting that crap. But I must admit that sticking to this principle is getting harder every day. There's way too much crap now.
I have no doubts that if I ever get to work with Jira again, I am definitely doing it in Emacs (or via some other way that works for me). I am a software developer, not a power user, not a weak user, not an A/B testing subject. If a software vendor forces me to use their product inefficiently because "customers don't know what they want", I am either hacking my way around it or deleting that crap. But I must admit that sticking to this principle is getting harder every day. There's way too much crap now.
> go-jira. Jira command line client written in Golang (hence the name).
I think I can see one more reason for the name.
I think I can see one more reason for the name.
Ah, yes of course. I loooove the band, btw. I once went to their concert. L'Enfant Sauvage is one of my favorite songs.
Huh -- it's the name of a band, too? Never heard of.
All I knew was, it's the original Japanese name of https://en.wikipedia.org/wiki/Godzilla#Name
All I knew was, it's the original Japanese name of https://en.wikipedia.org/wiki/Godzilla#Name
There are two kinds of programmers: those who hate Jira, and those with Stockholm syndrome.
This site is courtesy of folks that never used bmc remedy or ivanti heat.
I was similarly shocked when people bitched about confluence. First, do you have a better alternative? Second, do you undrstand the nightmare before jira and confluence?
I was similarly shocked when people bitched about confluence. First, do you have a better alternative? Second, do you undrstand the nightmare before jira and confluence?
Ticket := (title, description, time, tags, links, *Comment)
Comment := (name, time, text)
…and everything else is culture or auxiliary tooling. It’s a schema as old as Web 2.0 and it works because most people just want to talk to each other and search for stuff they think or know is there.
100% of the time I just want to announce either what I want to do, or comment on something that’s in progress. The communication and progress tracking are the most important things for keeping me and my team aligned.
What does Jira get wrong? Bureaucracy. Modern day online triplicate form filling disguised as “agile” is still pen pushing.
Pro-forma for bugs is friction — I should be able to file a bug without having to think about how to categorise it. Have another tool / view for nagging me about that, not the create-bug workflow.
Epics / stories / tasks / sprints / bugs: what if I make a task when I wanted a bug? What if made a spike that’s really a task? Why does this matter so much at the top level of the “task” entity — it should just be a tag on a task and nothing more fundamental than that. Let me modify the structure of my task tree myself.
Clutter, of course. Jira has 15 fields of stuff per issue that could just all be tags once we’ve spent the first week shaking out what kind of patterns are appearing in our own team’s workflow.
Projects: why is it a three stage process to move an issue between projects, and why should the issue id change when it moves? What if a piece of work is small but spans two projects? Tagging not taxonomy please.
Jira feels like it was designed for contributors and teams with zero discipline. Tech teams with any kind of serious hiring bar and leadership structure should have zero problem with trusting their staff with being succinct and meaningful with communication, including with how they track tasks. If you need Jira to enforce this, then I feel sorry for you as I pass you by to join a different team who know how to and want to work together without form filling.
Comment := (name, time, text)
…and everything else is culture or auxiliary tooling. It’s a schema as old as Web 2.0 and it works because most people just want to talk to each other and search for stuff they think or know is there.
100% of the time I just want to announce either what I want to do, or comment on something that’s in progress. The communication and progress tracking are the most important things for keeping me and my team aligned.
What does Jira get wrong? Bureaucracy. Modern day online triplicate form filling disguised as “agile” is still pen pushing.
Pro-forma for bugs is friction — I should be able to file a bug without having to think about how to categorise it. Have another tool / view for nagging me about that, not the create-bug workflow.
Epics / stories / tasks / sprints / bugs: what if I make a task when I wanted a bug? What if made a spike that’s really a task? Why does this matter so much at the top level of the “task” entity — it should just be a tag on a task and nothing more fundamental than that. Let me modify the structure of my task tree myself.
Clutter, of course. Jira has 15 fields of stuff per issue that could just all be tags once we’ve spent the first week shaking out what kind of patterns are appearing in our own team’s workflow.
Projects: why is it a three stage process to move an issue between projects, and why should the issue id change when it moves? What if a piece of work is small but spans two projects? Tagging not taxonomy please.
Jira feels like it was designed for contributors and teams with zero discipline. Tech teams with any kind of serious hiring bar and leadership structure should have zero problem with trusting their staff with being succinct and meaningful with communication, including with how they track tasks. If you need Jira to enforce this, then I feel sorry for you as I pass you by to join a different team who know how to and want to work together without form filling.
A friend once said, "You can't software your way out of an organizational problem."
The complaints on the site generally criticize Jira from a technical standpoint, but it's important to realize that every "technical" shortcoming is based on a perceived organizational need: you never need the feature just for the feature itself.
So yeah, Jira is far from my favorite software -- it's bloated, slow, and embodies many product choices that make no sense to me -- but it's also possible to hate it because it doesn't support <obscure feature X> in exactly the way your organization has been doing it since you were working with spreadsheets, and that's not Jira's fault.
The complaints on the site generally criticize Jira from a technical standpoint, but it's important to realize that every "technical" shortcoming is based on a perceived organizational need: you never need the feature just for the feature itself.
So yeah, Jira is far from my favorite software -- it's bloated, slow, and embodies many product choices that make no sense to me -- but it's also possible to hate it because it doesn't support <obscure feature X> in exactly the way your organization has been doing it since you were working with spreadsheets, and that's not Jira's fault.
1. I hate Jira, but that isn't the main issue
2. Atlassian has a terrible way of managing feature requests priorities, not unique to them, but they definitely have an impact on many developers, which is why they (deserve and) get the huge shaming
3. I managed to move my company from Bitbucket to GitLab, for many reasons, but the main reason for me was that I simply couldn't manage the settings using their APIs, they have a very weird concept of APIs
4. They send people to fill in tickets and on Uservoice, but rarely do they actually listen to reasonable requests (tickets I still get notifications: Bitbucket user public SSH keys and Archiving projects in Bitbucket)
5. So the issue is not this or that product, it is that Atlassian doesn't have the real end users in mind, just the paying users, the end users can suffer, but not many people will resign over a product used at their company, so nobody really fights the company over it, and thus Atlassian keeps getting paid for terrible products that get new terrible interfaces from time to time
Edit: line spacing
2. Atlassian has a terrible way of managing feature requests priorities, not unique to them, but they definitely have an impact on many developers, which is why they (deserve and) get the huge shaming
3. I managed to move my company from Bitbucket to GitLab, for many reasons, but the main reason for me was that I simply couldn't manage the settings using their APIs, they have a very weird concept of APIs
4. They send people to fill in tickets and on Uservoice, but rarely do they actually listen to reasonable requests (tickets I still get notifications: Bitbucket user public SSH keys and Archiving projects in Bitbucket)
5. So the issue is not this or that product, it is that Atlassian doesn't have the real end users in mind, just the paying users, the end users can suffer, but not many people will resign over a product used at their company, so nobody really fights the company over it, and thus Atlassian keeps getting paid for terrible products that get new terrible interfaces from time to time
Edit: line spacing
I'm kinda interested in the underlining element from the site. Is that some sort of sentiment analysis tool or is it just a manual "highlight" of the loud parts?
JIRA might be OK if the organization on the receiving end of the JIRA queue is OK. JIRA can be no better than that organization.
https://shortcut.com/ is your savior. Try it.
Recall the root cause here. The buyer is not the user. This isn't just true for Jira but the vast majority of enterprise software. Enterprise software is bad, not just Jira, or Confluence or whatever Atlassian product you hate most.
If you are working on enterprise software it's probably bad. Even if your sales and stock are doing well, your software is still probably very frustrating to end users because they have no say in how it's made. The only users who do are admin, governance, legal, or other non-productive user. Their voices get heard and they tell the Director/VP/CTO they are happy and then the software gets renewed and seats expanded. Nowhere in there is the end user who is beating their head against a wall consulted.
Enterprise software is bad and it's worst for people who make software because we know it could be good.
If you are working on enterprise software it's probably bad. Even if your sales and stock are doing well, your software is still probably very frustrating to end users because they have no say in how it's made. The only users who do are admin, governance, legal, or other non-productive user. Their voices get heard and they tell the Director/VP/CTO they are happy and then the software gets renewed and seats expanded. Nowhere in there is the end user who is beating their head against a wall consulted.
Enterprise software is bad and it's worst for people who make software because we know it could be good.
I watched Margin Call. The huddling that goes on between the higher ups and the peons when the chips are down is what JIRA does for companies every day. If the firm in that movie had been using JIRA (and it it were real life and not a movie); I believe they would have had daily, much better communications and coordination and could have avoided the whole scenario the movie is about. Spoiler alert, Spacey's character's dog would still have died.
The poorly optimized performance of JIRA almost makes me believe they don't even use their own product. Perhaps performance is on the backlog of the backlog.
The poorly optimized performance of JIRA almost makes me believe they don't even use their own product. Perhaps performance is on the backlog of the backlog.
Historically JIRA has toed the line of being minimally acceptable to keep teams from transitioning to competitors, but their recent outage has left such a sour impression of their engineering and operations processes that they have finally crossed the line from minimally acceptable to completely unacceptable.
We're currently evaluating alternatives and what a transition plan may look like for ~5k issues with attachments/comments/mockups etc. Any products out there with a built-in JIRA migration tool?
We're currently evaluating alternatives and what a transition plan may look like for ~5k issues with attachments/comments/mockups etc. Any products out there with a built-in JIRA migration tool?
[deleted]
The day I needed to bookmark the url to manage my options list because I couldn’t get to it intuitively due to probably be being wrong (like 90% of their current customer base I guess) was when it started to go seriously south for me.
Jira is a great example how a slow application can frustrate users. Most of my complaints went away after upgrading my broadband over 50Mb and switching away from wifi to minimise request latency and throughout.
Yes that should be ridiculous.
Yes that should be ridiculous.
What I had figured in this past ~10 years since working with Jira: it is not this software that made my life hard but the project managers, administrators etc. who are misusing it.
E.g creating lots of fields with overlapping meaning. Creating very basic/lame status-flows but not enforcing it. Or creating very hard to follow status flows. Or misreading the data from tickets status history. Or never trying to learn how to use it but find the guy at (my) table, to create the queries, dashboards etc. (and then misuse them). Or the devs who were complaining about missing info but creating one-liner comments as well (if at all). Or the devs who are not searching for duplicates, similar issues and/or link them so it can be tracked.
It is far from perfect, and JQL is so far from being intuitive, but I can live with it - until there is a better alternative that is capable AND I have to use that.
E.g creating lots of fields with overlapping meaning. Creating very basic/lame status-flows but not enforcing it. Or creating very hard to follow status flows. Or misreading the data from tickets status history. Or never trying to learn how to use it but find the guy at (my) table, to create the queries, dashboards etc. (and then misuse them). Or the devs who were complaining about missing info but creating one-liner comments as well (if at all). Or the devs who are not searching for duplicates, similar issues and/or link them so it can be tracked.
It is far from perfect, and JQL is so far from being intuitive, but I can live with it - until there is a better alternative that is capable AND I have to use that.
My org is using an in-house solution. Jira is the object of our wet dreams.
Software like Jira and Fauxgile processes like Scrum feed off and mutually reinforce each other.
All the content on this site are symptoms of not using Jira properly.
That is all.
That is all.
People, have you _used_ enterprise software? Jira is the first piece of enterprise software I've ever used that I _don't_ hate! Well, if Bugzilla counts, then I don't hate that either.
But in the past I've been exposed to BMC's products, which were, at least when I was exposed to them 10 years, horrible. And going further back, Lotus Notes, which even in the early aughts wasn't up to basic standards of UI from the 1980s.
Could Jira be better? Sure. But I think a lot of the complaints about Jira might only be relevant to the way their instance of Jira happens to be set up. Setting up a proper workflow that meets the demands of the organization is not an easy thing to do.
Now, I've never administered Jira, and maybe that's not good, but as someone who's used it for about 10 years, I'm fine with it.
But in the past I've been exposed to BMC's products, which were, at least when I was exposed to them 10 years, horrible. And going further back, Lotus Notes, which even in the early aughts wasn't up to basic standards of UI from the 1980s.
Could Jira be better? Sure. But I think a lot of the complaints about Jira might only be relevant to the way their instance of Jira happens to be set up. Setting up a proper workflow that meets the demands of the organization is not an easy thing to do.
Now, I've never administered Jira, and maybe that's not good, but as someone who's used it for about 10 years, I'm fine with it.
I thought I hated jira, then I joined a company that uses Pivotal tracker.
Problem with Jira: Its customers are not its users.
My past managers had a great time with Jira. But if I have to migrate or create tasks in Jira the only efficient and effective way I have found is paying for a desktop license. It doesn't suck -- that much.
Otherwise, it is a destroyer of productivity for its users. It is also a source of lock in, that is usually unnecessary.
I find Github projects to cover most if not all of the needs, for instance, in an efficient manner. Most managers though also don't/shouldn't care about the micro tasks of a project, so an excel sheet has done that job.
The consequence of who the Jira customer is, is its lack of efficiency and chaos. It is too customizable and fails to preserve any form of usability to offer that customizability. I have seen Managers being joyful of achieving the "ultimate Jira," only for everyone in the team to have to learn to abide by the new process, only so that 1-2 people can keep track of tasks and velocity without hitting github or gitlab.
You get great statistics, but if I have to spend 1/5 of my workweek on petting Jira, you lose that.
Managers love Jira, that is why it keeps coming up. You need one new manager to come in, say they know Jira, and using it will solve all of the company's velocity issues, to end up with people writing articles of how they hate Jira.
My past managers had a great time with Jira. But if I have to migrate or create tasks in Jira the only efficient and effective way I have found is paying for a desktop license. It doesn't suck -- that much.
Otherwise, it is a destroyer of productivity for its users. It is also a source of lock in, that is usually unnecessary.
I find Github projects to cover most if not all of the needs, for instance, in an efficient manner. Most managers though also don't/shouldn't care about the micro tasks of a project, so an excel sheet has done that job.
The consequence of who the Jira customer is, is its lack of efficiency and chaos. It is too customizable and fails to preserve any form of usability to offer that customizability. I have seen Managers being joyful of achieving the "ultimate Jira," only for everyone in the team to have to learn to abide by the new process, only so that 1-2 people can keep track of tasks and velocity without hitting github or gitlab.
You get great statistics, but if I have to spend 1/5 of my workweek on petting Jira, you lose that.
Managers love Jira, that is why it keeps coming up. You need one new manager to come in, say they know Jira, and using it will solve all of the company's velocity issues, to end up with people writing articles of how they hate Jira.
What I find the real problem is not JIRA itself, but the fact that most of the time JIRA, is abused up to a point where it's become unusable. The inability or unwillingness (or both?) of the teams I've worked with to structure their work, write good user stories and keep things simple is in my experience the root cause of any shitty JIRA experience I've had. Of course it doesn't help per se that JIRA allows you to do that, but I guess that's not the tool's fault. (You can write bad and good essays with Microsoft Word).
For me a particularly frustrating aspect is the way the UI moves around a lot. I’m quite anxious to click anything until all the loading spinners have stopped in case I click the wrong thing. Then I could be taken to a page or feature I’ve never seen before.
Also it’s really annoying when I try to copy something from a ticket description but it starts editing the whole description field.
EDIT - I'd also like to add that as a developer, once I finish my ticket I assign it to a QA. Then I can never get back to the ticket. I'd like a really easy way to see all of the tickets I've ever completed. But completed tickets aren't assigned to me, they're assigned to QA.