10 ms·

I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture. JIRA doesn't really feel any f

I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture. JIRA doesn't really feel any faster just because your input devices are fast; the application level latency dwarfs the input latency by a large margin. I would take measurements, but JIRA prohibits benchmarking for some reason... ¯\_(ツ)_/¯ they're probably just trying to save everyone else the embarrassment of seeing how incredibly fast JIRA is compared to their own sluggish offerings, right? I am confident that JIRA's application latency has nothing to do with Java (backend) or JavaScript's (frontend) garbage collector. Many companies just feel no impetus to write fast software, or to use commensurately powerful hardware.

Aeolun 8y ago
But to be fair, plain Jira can be pretty fast, it’s just when you get into an enterprise environment and people think they need 2000 different fields things fall apart.
- Skunkleton 8y ago
  Why shouldn't 2000 fields be fast? Shouldn't all of what jira does boil down to straight forward SQL queries?
  - flattone 8y ago
    or even 200000 etc. I've never used but at a glance i feel like it's just a google sheets tracker with unnecessary visual stuff?
- coder543 8y ago
  I've never seen JIRA be "pretty fast", so I can't agree. I also think "2000 different fields" is an unfair exaggeration, if we're going to focus on being fair. The 10 to 20 fields that people might use per issue should not prevent JIRA from being fast with the right architecture.
  - viraptor 8y ago
    Same. JIRA is just slow, even in basic configuration. Which is always annoying me because JIRA is 99% read-only. They could generate most of the pages and cache them until anything changes. Even pre-generate then on change. But every time you view an issue, it takes multiple seconds again.
    - WrtCdEvrydy 8y ago
      This is a common 'but sometimes' issue in software engineering. Caching works for 99.9% of cases, 'but sometimes', I click on an issue and it was just updated just before my page rendered.
  - p2detar 8y ago
    I've setup Jira (on premise) at my workplace myself. Runs behind an nginx reverse proxy and it is indeed pretty fast! We don't use much stuff and it's a bit older version 7.8, but I cannot complain so far.
  - Aeolun 8y ago
    Installed a plain Jira software instance on Docker, that wasn’t terribly slow.
- EpicEng 8y ago
  Our fresh install was noticeably slow. Even if it were fast (it's not), they sell the thing as a customizable solution. Few people get everything they need from a vanilla install. That's kinda the whole selling point.
- cimmanom 8y ago
  Don’t know about the enterprise version, but the cloud offering loads and renders like molasses.
- dnate 8y ago
  We have been using jira as a very simple issue tracker with 3 users and the standard backlog, selected for development, done workflow. Load times are atrocious. It's the slowest website I have ever seen. Maybe facebook is slower, but I don't use that as often.
ploxiln 8y ago
Jira is in a league of its own. With latest stable Firefox on a Macbook Pro from 2014, I get a full 10 seconds loading time for the notifications sidebar. Every click in Jira takes between 5 and 15 seconds. It is absolutely nuts and it seems like many people just don't understand how insanely bad it is (but obviously many engineers do ;) Meanwhile my browser can load, render, and scroll a 4000 line colored diff in less than half a second (e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=01897f3e05ede4d66c0f9df465fde1d67a1d733f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...)
- sb8244 8y ago
  Is your jira heavily customized? I haven't seen this level of slowness and use it daily. I know that customizations can be the root of evil on jira
  - notduncansmith 8y ago
    And this level of open-ended configurability is why many vendors prohibit benchmarking. While Atlassian is exceptional in some regards, this is not one of them.
    - michaelmrose 8y ago
      If jira is slow crap when used in the way real people use it then isn't this a meaningful fact worth sharing?
  - ploxiln 8y ago
    It looks pretty standard ... it does have GitHub integration enabled, and custom fields and workflow for each project, which seems like a pretty standard thing for organizations/users to do. But my key anecdote is about loading the notifications sidebar after the page has loaded, there shouldn't be any customizations in there. But I dunno, maybe Jira gives managers a bit too much rope with which to hang their development teams.
- cco 8y ago
RBerenguel 8y ago
I wrote some Python to convert a long yaml file into jira epics/stories/deploys to avoid having to use the UI for anything aside checking what I have on my todo. Has already saved me more than it took to write.
- speedplane 8y ago
  That's great for you, but I'd bet no one else can effectively use your scripts. The beauty of the UI is that anyone can use it almost immediately.
  - HelloNurse 8y ago
    The beauty of a shit-filled moat is that anybody can wade in without having to be able to jump it.
  - RBerenguel 8y ago
    Everyone in engineering can use it if they want, it’s in our “fun tools” repo. I have better things to do than to navigate through ticket creation UI 20 times
    - ThePadawan 8y ago
      > I have better things to do than to navigate through ticket creation UI 20 times. Thank you for being that sort of person. I know some people who would take great pleasure in knowing that they would get paid for spending just that time, no matter if they achieved very little doing it.
  - TeMPOraL 8y ago
    Why does this matter? There's no obligation to always make software useful for other people. There's a lot of space between doing something manually and selling a product.
    - speedplane 8y ago
      > There's no obligation to always make software useful for other people. The problem, which you basically acknowledge, is that software that isn't useful generally doesn't get used. If you write nice custom scripts to make your own workflows more efficient, that's great... for you. But to make any interface "useful" (whether it's a UI, an API, etc.), it doesn't just need to be "useful", it also has to be accessible. That should help explain why even crappy UIs are so ubiquitous. They are moderately useful, but extremely accessible.
bartread 8y ago
> I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture. No it does not: it clearly makes the point that due to device, hardware, OS, and framework latencies your application has very little time budget in which to respond and still feel fast to users. This will necessitate considerable effort in terms of architecture. I don't see how that's under-emphasising it. To have a useful discussion on architecture within the article they'd have to talk about the specifics of different software and applications, which obviously vary considerably according to the requirements for said software and applications. The danger with that sort of thing is that some people will say, "well, if we use architecture X then our application will feel fast," disregarding many of the detailed requirements of their domain that mean X won't always (or possibly even ever) perform well. To some extent that's unavoidable but I think this article was absolutely on point in that it makes clear the constraints within which software developers must operate, and sensibly leaves architecture as the responsibility of those software developers.

Aeolun 8y ago

But to be fair, plain Jira can be pretty fast, it’s just when you get into an enterprise environment and people think they need 2000 different fields things fall apart.

Skunkleton 8y ago
Why shouldn't 2000 fields be fast? Shouldn't all of what jira does boil down to straight forward SQL queries?
- flattone 8y ago
  or even 200000 etc. I've never used but at a glance i feel like it's just a google sheets tracker with unnecessary visual stuff?
coder543 8y ago
I've never seen JIRA be "pretty fast", so I can't agree. I also think "2000 different fields" is an unfair exaggeration, if we're going to focus on being fair. The 10 to 20 fields that people might use per issue should not prevent JIRA from being fast with the right architecture.
- viraptor 8y ago
  Same. JIRA is just slow, even in basic configuration. Which is always annoying me because JIRA is 99% read-only. They could generate most of the pages and cache them until anything changes. Even pre-generate then on change. But every time you view an issue, it takes multiple seconds again.
  - WrtCdEvrydy 8y ago
    This is a common 'but sometimes' issue in software engineering. Caching works for 99.9% of cases, 'but sometimes', I click on an issue and it was just updated just before my page rendered.
- p2detar 8y ago
  I've setup Jira (on premise) at my workplace myself. Runs behind an nginx reverse proxy and it is indeed pretty fast! We don't use much stuff and it's a bit older version 7.8, but I cannot complain so far.
- Aeolun 8y ago
  Installed a plain Jira software instance on Docker, that wasn’t terribly slow.
EpicEng 8y ago
Our fresh install was noticeably slow. Even if it were fast (it's not), they sell the thing as a customizable solution. Few people get everything they need from a vanilla install. That's kinda the whole selling point.
cimmanom 8y ago
Don’t know about the enterprise version, but the cloud offering loads and renders like molasses.
dnate 8y ago
We have been using jira as a very simple issue tracker with 3 users and the standard backlog, selected for development, done workflow. Load times are atrocious. It's the slowest website I have ever seen. Maybe facebook is slower, but I don't use that as often.

ploxiln 8y ago

Jira is in a league of its own. With latest stable Firefox on a Macbook Pro from 2014, I get a full 10 seconds loading time for the notifications sidebar. Every click in Jira takes between 5 and 15 seconds. It is absolutely nuts and it seems like many people just don't understand how insanely bad it is (but obviously many engineers do ;) Meanwhile my browser can load, render, and scroll a 4000 line colored diff in less than half a second (e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=01897f3e05ede4d66c0f9df465fde1d67a1d733f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...)

sb8244 8y ago
Is your jira heavily customized? I haven't seen this level of slowness and use it daily. I know that customizations can be the root of evil on jira
- notduncansmith 8y ago
  And this level of open-ended configurability is why many vendors prohibit benchmarking. While Atlassian is exceptional in some regards, this is not one of them.
  - michaelmrose 8y ago
    If jira is slow crap when used in the way real people use it then isn't this a meaningful fact worth sharing?
- ploxiln 8y ago
  It looks pretty standard ... it does have GitHub integration enabled, and custom fields and workflow for each project, which seems like a pretty standard thing for organizations/users to do. But my key anecdote is about loading the notifications sidebar after the page has loaded, there shouldn't be any customizations in there. But I dunno, maybe Jira gives managers a bit too much rope with which to hang their development teams.
cco 8y ago

RBerenguel 8y ago

I wrote some Python to convert a long yaml file into jira epics/stories/deploys to avoid having to use the UI for anything aside checking what I have on my todo. Has already saved me more than it took to write.

speedplane 8y ago
That's great for you, but I'd bet no one else can effectively use your scripts. The beauty of the UI is that anyone can use it almost immediately.
- HelloNurse 8y ago
  The beauty of a shit-filled moat is that anybody can wade in without having to be able to jump it.
- RBerenguel 8y ago
  Everyone in engineering can use it if they want, it’s in our “fun tools” repo. I have better things to do than to navigate through ticket creation UI 20 times
  - ThePadawan 8y ago
    > I have better things to do than to navigate through ticket creation UI 20 times. Thank you for being that sort of person. I know some people who would take great pleasure in knowing that they would get paid for spending just that time, no matter if they achieved very little doing it.
- TeMPOraL 8y ago
  Why does this matter? There's no obligation to always make software useful for other people. There's a lot of space between doing something manually and selling a product.
  - speedplane 8y ago
    > There's no obligation to always make software useful for other people. The problem, which you basically acknowledge, is that software that isn't useful generally doesn't get used. If you write nice custom scripts to make your own workflows more efficient, that's great... for you. But to make any interface "useful" (whether it's a UI, an API, etc.), it doesn't just need to be "useful", it also has to be accessible. That should help explain why even crappy UIs are so ubiquitous. They are moderately useful, but extremely accessible.

bartread 8y ago

> I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture. No it does not: it clearly makes the point that due to device, hardware, OS, and framework latencies your application has very little time budget in which to respond and still feel fast to users. This will necessitate considerable effort in terms of architecture. I don't see how that's under-emphasising it. To have a useful discussion on architecture within the article they'd have to talk about the specifics of different software and applications, which obviously vary considerably according to the requirements for said software and applications. The danger with that sort of thing is that some people will say, "well, if we use architecture X then our application will feel fast," disregarding many of the detailed requirements of their domain that mean X won't always (or possibly even ever) perform well. To some extent that's unavoidable but I think this article was absolutely on point in that it makes clear the constraints within which software developers must operate, and sensibly leaves architecture as the responsibility of those software developers.