[jerf]

"I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours)."

I can give you my answer: Because the ticketing system is painfully slow to log in to, create the ticket, move it to the proper status, etc. Single sign on can make things worse too. The whole process can add up to easily a minute, and not a productive minute of the actual filing (I would be fine with that) but a minute of poking at things.

This does not make you wrong. If you want to say there's some laziness there, yeah, maybe. But it's not just laziness, there's a psychological torture aspect to it all too that is, if not "objectively" true, then at least not entirely my imagination either.

I really, really, really wish Atlassian would basically drop everything for a quarter or two and work on the speed of their products. There shouldn't be a fundamental reason why their stuff is so slow.

[tharkun__]

Not to say your experience isn't awful but have you actually timed this? (also Cloud vs. Server can make a huge difference - Cloud being faster even if their recent UI changes aren't all great).

Login processes can suck. Absolutely. But like you say, single sign-on means you should at max be logging in once per day if not even less.

So just for giggles I timed various things in our instance for you. I have a logged in single sign-on session already.

Opening the Jira instance to my default dashboard until I could conceivably click on the "Create" button: 3.5s

Click the "Create" button until I could start typing into the summary field (while the rest still loads): 1.1s

Now as for filling out what you need, that obviously depends on your company and they can make it a pain, agreed. If we're talking about the "someone tells you drop everything now and to work on X" I doubt it takes more than 30 seconds to fill in even one of the "wild" issue creation screens. I mean you literally have to type something like "Exec B made me work on X" into both the summary and the description field, maybe choose an issue type and select the first value of any dropdown required fields and type "a" into any required input fields.

Actual ticket creation duration shouldn't take much longer either and even if, who cares? By that time I'm already back in my IDE.

[cweagans]

> have you actually timed this?

I'm not who you're asking, but I have timed this at multiple workplaces. The most egregious example took 32 minutes end-to-end (for many reasons: Jira was behind a VPN, which was extremely slow to login and even slower to actually use, the SSO system only allowed a session to persist for an hour, the server actually running Jira was underspec'd, the ticket template was incredibly verbose, etc, etc, etc). I am excluding the time it took to type the ticket in the first place (I wrote up the text beforehand and copy/pasted it into the fields) and including the time it takes to sign in to SSO, log into the VPN, browse to the ticketing system, etc. Essentially, I assume that it's the start of a work day and the only thing I've done is boot up my machine. Excluding the 32-minute workplace, I've got an average of ~9.5 minutes (only one was < 60 seconds).

While many workplaces have good systems, don't assume that every workplace does. There are many out there who accept/mandate potato-quality tools.

[tharkun__]

Hehe fair enough for your case. Yes, those absolutely exist. If you're not working for a military contractor or something there I hope you ran a long time ago. This seems to indicate that a lot of other things would be wrong with that place too.

I asked my parent if he timed it, because he mentioned "a minute". Lots of things feel longer to us than they actually are. If you're waiting for something to open or react to a click or other input even half a second can feel long and we're bound to say things like "whoa that took like 30 seconds, WTF!". But when you time it, it actually takes way less.

E.g. opening an issue directly from a new tab in Jira takes about 5 seconds for me in my quick test for example. Yes, that's absolutely a "long" time for what it ultimately needs to display and do. But it's also nowhere near a minute and if all you gotta do is to open a ticket someone sent you because you're supposed to "work on ASAP", these 5 seconds don't matter. You'll wait about the same time to run your unit tests after making the required change. You'll wait way longer to run the entire test suite etc.

[flaviut]

We use cloud Jira, without any sort of crazy customization. This morning, I wanted to unsubscribe from a ticket.

It took about 15 seconds to load the ticket page, and another 5 seconds to process the unsubscribe. I just tried again now, and it took "just" 3 or so seconds to load the ticket page.

Their p50 time is already unacceptable, and their p90 time is completely absurd.

We've known what acceptable delays are since 1968[1]! Why is it so hard to build software that meets these requirements? Our computers are only 20 million times faster than back then...

[1]: https://dl.acm.org/doi/10.1145/1476589.1476628

[cutemonster]

> Why is it so hard to build software that meets these requirements?

At the same time, why would they? Your employer bought it anyway. And I guess the execs won't notice these HN discussions ...

[enra]

Try Linear[1] and let me know if you have ideas how to sell speed to program management or execs. Startups get it, it’s more rare that large companies see the value.

[1]: https://linear.app/

[greatgib]

The worse is maybe not the total time in itself but the lag effect.

It is annoying to click on something and wait 4-10s for the page/board to load or the login redirect dance to be completed.

So, what happens is that you click, and you go to do something else like reading another page in the meantime.

And then you completely forgot what you were about to do and when you remember you are already logged out or you have to refresh the board again, and it is slow again, so you go do something else in the meantime, etc...

And so on you lose a lot of time with frustration.