3 ms·

I recently joined a company that used Jira and the UX is worse than any web app I can remember. And I'm old. Jira is an excruciatingly slow and infinitely confu

I recently joined a company that used Jira and the UX is worse than any web app I can remember. And I'm old. Jira is an excruciatingly slow and infinitely confusing abstraction and I have no idea what problem it solves better than competitors in 2018. I showed the CTO and CEO ZenHub and we're off to the races.

mivanchev 9y ago
Yes, I can relate to that. Jira is extremely slow and counter intuitive to use. So much that I believe it will create friction within an organization, because people will try to avoid using it. Weird filtering system, weird keyboard shortcuts, long loading times for everything. I really don't understand why performance is not the top priority @Atlassian. A very bad example of workmanship and I don't care how well it integrates with XYZ.
- dkarl 9y ago
  Not to mention the workflows are crack for anyone looking to make themselves powerful and essential without doing any real work. I was in an organization where many meetings were spent begging the workflow czar to make minor modifications to prevent tickets getting stuck in states where the people responsible for them couldn't advance the workflow. At one point we got lectured because some managers (in a major act of rebellion) got in the habit of abandoning and re-creating tickets whenever they hit problems. In another incident, someone coopted an industrial plotter to print out the entire software development ticket workflow to embarrass the workflow czar into stopping his shenanigans, but it didn't work.
  - brazzledazzle 9y ago
    The biggest problem with JIRA is management. Workflow hell, death by a thousand fields, shiny addons, etc. It’s probably inevitable but a policy requiring strong justification for and regular review of any “aftermarket” changes might slow down or reverse the descent. The closer it is to vanilla the easier it is for (almost) everyone. Managers and workflow czars (nice one btw) of course would be inconvenienced but they should be comfortable making really strong justifications for making the lives of developers harder just to make their reporting smoother. I attended a talk by a Netflix employee where they talked about a sort of organizational immune system to aggressively prune bureaucracy and policy by forcing it’s existence to be regularly justified. It helped me connect the dots and realize that allowing heavy customization was as much a poison as it was a boon.
- viraptor 9y ago
  I'm not even sure why is performance such an issue in the first place. It's not like 50 users can cause a lot of traffic. They have time to literally pre-generate all the views that could change after every action, between the times a user actually makes any change. I get that the data behind the views is complex, but having to wait multiple second for fairly trivial pages is crazy.
wwalser 9y ago
If ZenHub works for your team, sweet. If the business is operating at a scale that ZenHub can serve adequately, you're probably not an ideal customer of JIRA. There's a tipping point along two different axes where JIRA becomes worthwhile. One axis is number of people actively using the tracker for a single project — I personally think that threshold is around 50 people^1. Another is workflow complexity — very few tools are as capable of mapping business processes to software as JIRA^2. 1. Careful, there's another threshold at which JIRA becomes painfully slow. At that point you either move to something that's less adequate in nearly-every way but scales or you start splitting JIRA instances by department or project. 2. Careful here as well! Poorly created JIRA workflows are probably _the_ #1 reason people hate using it. Users learn a highly customized JIRA workflow and think it's absolutely bonkers that Atlassian did this to them, when really it's their company's customizations that are causing the pain.
- brazzledazzle 9y ago
  They have JIRA Data Center now which is far from perfect but helps with the scalability issues. It’s costs quite a lot though. DB is typically the bottleneck after that, especially since they don’t officially support any DB clustering. Postgres is their best supported DB (it’s what they use in production themselves) so maybe as native Postgres clustering matures we’ll see support for that.
- subpixel 9y ago
  The 'threshold where JIRA becomes painfully slow' for our team of 5 was on day one, when we had to wait multiple seconds for an issue to load in the browser.

mivanchev 9y ago

Yes, I can relate to that. Jira is extremely slow and counter intuitive to use. So much that I believe it will create friction within an organization, because people will try to avoid using it. Weird filtering system, weird keyboard shortcuts, long loading times for everything. I really don't understand why performance is not the top priority @Atlassian. A very bad example of workmanship and I don't care how well it integrates with XYZ.

dkarl 9y ago
Not to mention the workflows are crack for anyone looking to make themselves powerful and essential without doing any real work. I was in an organization where many meetings were spent begging the workflow czar to make minor modifications to prevent tickets getting stuck in states where the people responsible for them couldn't advance the workflow. At one point we got lectured because some managers (in a major act of rebellion) got in the habit of abandoning and re-creating tickets whenever they hit problems. In another incident, someone coopted an industrial plotter to print out the entire software development ticket workflow to embarrass the workflow czar into stopping his shenanigans, but it didn't work.
- brazzledazzle 9y ago
  The biggest problem with JIRA is management. Workflow hell, death by a thousand fields, shiny addons, etc. It’s probably inevitable but a policy requiring strong justification for and regular review of any “aftermarket” changes might slow down or reverse the descent. The closer it is to vanilla the easier it is for (almost) everyone. Managers and workflow czars (nice one btw) of course would be inconvenienced but they should be comfortable making really strong justifications for making the lives of developers harder just to make their reporting smoother. I attended a talk by a Netflix employee where they talked about a sort of organizational immune system to aggressively prune bureaucracy and policy by forcing it’s existence to be regularly justified. It helped me connect the dots and realize that allowing heavy customization was as much a poison as it was a boon.
viraptor 9y ago
I'm not even sure why is performance such an issue in the first place. It's not like 50 users can cause a lot of traffic. They have time to literally pre-generate all the views that could change after every action, between the times a user actually makes any change. I get that the data behind the views is complex, but having to wait multiple second for fairly trivial pages is crazy.

wwalser 9y ago

If ZenHub works for your team, sweet. If the business is operating at a scale that ZenHub can serve adequately, you're probably not an ideal customer of JIRA. There's a tipping point along two different axes where JIRA becomes worthwhile. One axis is number of people actively using the tracker for a single project — I personally think that threshold is around 50 people^1. Another is workflow complexity — very few tools are as capable of mapping business processes to software as JIRA^2. 1. Careful, there's another threshold at which JIRA becomes painfully slow. At that point you either move to something that's less adequate in nearly-every way but scales or you start splitting JIRA instances by department or project. 2. Careful here as well! Poorly created JIRA workflows are probably _the_ #1 reason people hate using it. Users learn a highly customized JIRA workflow and think it's absolutely bonkers that Atlassian did this to them, when really it's their company's customizations that are causing the pain.

brazzledazzle 9y ago
They have JIRA Data Center now which is far from perfect but helps with the scalability issues. It’s costs quite a lot though. DB is typically the bottleneck after that, especially since they don’t officially support any DB clustering. Postgres is their best supported DB (it’s what they use in production themselves) so maybe as native Postgres clustering matures we’ll see support for that.
subpixel 9y ago
The 'threshold where JIRA becomes painfully slow' for our team of 5 was on day one, when we had to wait multiple seconds for an issue to load in the browser.