[confluence_perf]

Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ?

(edit: looks like HN is severely limiting my reply rate so apologies for delays)

[eitland]

Not GP but I also have the same feeling across Atlassian products:

it is more like a general feeling all the time for many of us.

I'm using the latest Firefox on Windows, a developer laptop with 32GB memory that was brand new this spring as well as 500/500 fiber.

[confluence_perf]

Is this also on Cloud products?

Right now on holiday (through Tuesday), but would like learn more. I see your contact info in your profile, if you give consent I'd like send you an email on Wednesday with some followup questions (the first question is "what is the URL for your cloud instance" so I don't want to be asking for it on a public forum)

(edit: typo)

[crooked-v]

> Is this also on Cloud products?

On my company's cloud instance of Jira, it's a minimum of a 2-3 second delay to do anything. Edit, wait a few seconds, save, wait a few seconds, change a field, wait a few seconds... and God help you if you need to reload the page because something got stuck.

[hchz]

"My boss told me to generate a bunch of JIRAs in reaction to the recent accurate discussions on HN of how poor our performance is, so I need specific dit-dot issues to buff our team metrics rather than address the cause of the issues, which is a political non-starter"

[samb1729]

There's nothing quite like having to spend a load of time justifying everything your team wants to do to the team above because they need to justify the things their teams need to do to the team above them.

Sometimes things are just obviously crap to the people tasked with working on them and having to jump through these kind of hoops eventually leaves an organisation with only the kind of people who are happy to keep doing it.

Nothing makes me stop ignoring recruiter messages quite like being asked to flesh out a JIRA ticket with technical details by a person who has literally no use for the details they ask me to write.

[saagarjha]

A more charitable interpretation might be “my boss won’t let me fix things unless I have specific comments about problems from people who use the software”.

[jiggawatts]

Translation: His boss is an idiot and their lunch is going to be eaten by a company where management gives a shit about product quality.

[samb1729]

If their boss doesn't let them just get to work without thoroughly documenting everything that's a larger problem. As good a time as any to start looking for jobs with bosses that don't suck.

[tw25613937]

Not trying to be snarky, but... do you use your product?

[grzm]

These are questions I have as well. That said, creating a throwaway and prefacing a comment with "Not trying to be snarky" shouldn't be an excuse for not taking the time to couch questions in a way you're more confident aren't going to be interpreted in a negative way. This isn't directed just at you: I see this behavior all too often: people using throwaways as an excuse to not take the time to express things in a manner that doesn't need to apologize for itself.

Atlassian employees use their products, and tips and tricks they may have to use them effectively, or make the experience of using JIRA or Confluence, or their other tools more enjoyable and useable would be great to know!

[dylan604]

If you need tips or TRICKS to make a product useable, you have a BAD product.

[grzm]

I agree, and I also know that you have to deal with the world as it is right now even while you work to make it better.

If you have to use Jira or Confluence at work, you probably want to know how to make that as useful as possible. If you're working at Atlassian, you probably want to make your customer's experience as enjoyable as possible as soon as possible. Ideally you have a great product and great documentation and all happy customers. If that's not the case, you have an opportunity to work on a number of fronts, including improving documentation and the product, and help current customers with the product as it is. You can and should be doing all of these things.

Piling on doesn't help anything.

[hchz]

Some people don't want to use it at all, and don't care for the situation that C-suite everywhere buys Atlassian's trash.

They don't want minor improvements to help it limp along, they want to vent and complain about it.

I think it's impossible that Atlassian evolves into a good product company, but it's entirely possible that my next CTO googled for opinions on the product, found a few discussions on HN with a combined 3,000 complaints about what a garbage fire it is, and went with Clubhouse.

[grzm]

And the thread from yesterday (https://news.ycombinator.com/item?id=25590846 for a site named https://whyjirasucks.com) or any of the other many rants on Altassian around the web don't suffice? I hardly think that this thread is going to be the tipping point. It's not like this is news.

Given your opinions regarding Atlassian, what would you think of your next CTO if they were even considering Atlassian? Is that someone you'd want to work for?

[dylan604]

I know this is like well after the conversation, but if you as a developer have to provide Tips/Tricks to your users to be able to use your product, then fix the software to make the Tips/Tricks un-necessary. You don' need to have employees creating accounts on forums asking for "feedback" or "describe for me the steps needed to re-create the issue". You already know the issues with a list of work arounds. FIX THEM!!! This "hey look at us asking the users" is just a sham as they are not even fixing the most basic of things. Why would I believe they are going to fix some thing that needs help re-creating before being noticed by their devs?

[grzm]

If, in your opinion, the situation is so bad that it's a sham, why comment on this at all? What will that do to make the situation better, for Atlassian, for you, or for anyone else reading the thread?

My original point was that people should engage with each other in a way that's likely to create the most positive outcome. Creating throwaway accounts so one doesn't need to take the effort to be polite or take the time to be explicit about what they mean in a low-bandwidth context like HN is, in my opinion, highly unproductive and lowers the discourse on HN. If we're not trying to make things better, both the particulars of the situation (say, figuring out how to make Atlassian products easier to use) and put us in a better place for solving situations in the future (maintaining HN as a community people want to participate in), I don't think we should comment at all.

The throwaway I responded to hasn't participated further, and everyone else seems to have focused on the "tips and tricks" phrasing I employed, so one last attempt to elaborate:

Hypothetical scenarios:

1. You have to use Atlassian products at work for reasons that are out of your control. Your options:

- figure out how to make using the products as easy as possible.

- refuse to use the Atlassian products

- figure out how get your organization to change to another product.

- find a new job.

I'd argue only the first one is in your control as something you can do today on your own.

Some options for "figuring out how to make using the products as easy as possible":

- Complain on a forum that Atlassian products suck. The venting may make you feel better, but won't really improve the situation.

- Engage with an Atlassian employee

If you don't believe Atlassian is going to actually do anything, you might as well not make the effort of engaging at all. If you think there's a possibility you might find some relief by doing so, set yourself up for success. Snark and aimless, general complaints are unlikely to lead to a successful outcome, and I think it's likely to actively increase your likelihood of failure.

2. You're an Atlassian employee.

Note: If you don't believe Atlassian employees are operating in good faith, you can skip this section--and, for that matter, everything here. Get your company to switch tools, or quit.

Atlassian developers--just like any other developer--want clear, reproducible bug reports so you can fix the bugs (including slow performance). You want to know (a) what they wanted to accomplish; (b) exactly what they did; (c) what they expected to happen; and (d) exactly what did happen. If you want support, supply this information even if they don't ask for it 'cause that's what they need.

Fixing bugs takes time. Adding features takes time. Improving documentation takes time. All of those things should definitely be done. If the fixes are trivial, of course prefer the fix over the tips and tricks. If "tips and tricks" can work as a stop-gap to while these other things are worked on, by all means Atlassian employees should offer them and those using Atlassian products should use them if they want some relief now.

Time is a finite resource, and you need to figure out ways to move forward the best you know how. Your customers are likely diverse and have while they likely share some priorities, others are going to be different. Choosing to fix bugs A, B, and C while moving forward with features M, N, and O means that bugs D, E, F, G, H, and I and features P, Q, R, S, and T aren't going to be worked on, at least right now. And your customers that really want A, B, and C fixed and your customers who want features M, N, and O are going to be so grateful, and your customers who really a bitten by bugs D and F are going to be out in the cold, as are customers who want features P and Q. But if you can give customers affected by D a workaround in the meantime, I think that's better. That's just how things are, at any shop. And not just in software development.

If your priorities as a customer don't line up with those of the company whose product your using, your options are to wait, find a workaround, convince to the company to reprioritize, or find another product.

Focus on what you can do rather than what others should do. If you rely on the actions of others, it's still the same: what you can do to help others do what you want them to do--in a way that maximizes the likelihood of success.

The short version of all of this is engage with each other in good faith. If you don't believe the people you're working with are doing that and you don't think you can change it, it's really not worth continuing to engage with them, positively or negatively.

[smarx007]

Well, you certainly need "tips and tricks" to make Arch Linux fully usable. Every powerful tool needs to be adjusted to its use (Github is full of dotfiles and macOS bootstrap repos). Doing so is a sign of professionalism (craftsmanship).

[acdha]

I think that’s saying more about Arch than anything else. While it’s not wrong that people add dot files to track preferences, those aren’t necessary for basic usage. Someone using macOS without customizing anything still has a good experience.

A key distinction is between domain complexity and what the product adds to that intrinsic complexity. If you use GitHub or GitLab issues with no customization you’ll have a better experience than a Jira user because they work well out of the box without requiring customization or adjusting your workflow just to accomplish core tasks.

[smarx007]

You are right, Arch has a poor product experience.

On the other hand, I do not view those systems as products when it comes to professional use. A non-techie might see a Mac as a fancy laptop but for me it's a tool. Just like an HSS cutting tool in a lathe, you'd carefully maintain it (you don't want to use a dull cutting tool) and tune it. Just like you want to regrind a cutting tool depending on the part you are machining, I disable Intel Turbo Boost using http://tbswitcher.rugarciap.com when I run long perf evaluations of my programs for academic projects. If M1 based Macs will not allow me to disable their boost clock functionality, they will be unsuitable for my work as a tool. When that happens, you simply pick the most fitting tool. Not necessarily switching dev platforms, in this case a separate machine running Linux for the eval may be OK.

Regarding issue trackers, there are still some things I miss about Bugzilla after moving to Github issues such as sorting issues by two fields in order (eg first by prio and then milestone). I similarly like complex queries that can be saved in YouTrack. I will admit that 5 years ago I thought that Bugzilla was ugly (it still is) and not user-friendly (one of the worst) but now I simply see it as a professional tool that does not get in my way once I learn how to use it. On the other hand, most of the tools with proper UX (not all, most notably airplane cockpits have proper UX but still do not get in the way of a pilot doing their job including manual overrides for all kinds of malfunctions) have some "user journey" which gets in the way of almost every pro user.

[snypher]

As a product manager, are you allowed to discuss performance and benchmarks without violation of your contract? Or, is it just customers that are prohibited from this?

[burnthrow]

Come on, everything is slow and you know it.

[confluence_perf]

We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems.

We would love to fix "everything", and we have some longer term projects focused on this -> However, "everything" fixes seem to be a more incremental boost and also take longer time to complete.

If you have any feedback about "specific" items that are the most frustrating, we'd love to hear about those -> targeted fixes for specific can be much faster, much greater gains, and usually offer better user experience gain/engineering time returns.

If not, I can only say that we are definitely working on making 'everything faster'

(edit: trying to reply but looks like HN is limiting my reply rate)

(edit: maybe I can post my replies here and hopefully they'll get read)

------ @rusticpenn - This is definitely possible that 'some users are just used to it'. But we also see a very wide variance in individual customers' performance numbers (ie. some instances have consistently faster performance than other instances), and even within individual instances variance amongst users (some users have consistently faster experience than other users on the same instance) -> we're trying what we can to narrow down the causes in this variance.

Hearing from "users with slow experiences" is simply one of the ways we're trying to track this down, but it helps if users are willing to provide more info.

--------

@ratww - thank you for the suggestion! We have some amount of data that helps us see what might be different between instances, but haven't gone out of our way to 'interview a fast customer', I'll bring this up with the team to see.

The two biggest factors I think we've seen: slow machines can contribute (but not a necessity), and large pages (especially with large tables, or large number of tables) can contribute.

[acdha]

> We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems.

What do your metrics show? I instrument my web sites so I know how long every operation – server responses, front-end JS changes, etc. – takes and can guide my development accordingly. You have a much larger budget and could be answering this question with hard data.

I’ll second the “everything” responses. Request Tracker on 1990s hardware was considerably faster than Jira is today - and better for serious use, too.

[confluence_perf]

Hi acdha,

We have metrics, but of course as with many such things you always want more insights than the amount of data you're collecting (so we're always trying to grow this as appropriate).

This data is what led to the above (added edit trying to reply to @rusticpenn) saying we can see that "some instances are slower than others", and "some users are slower than others". I can't share those numbers of course though.

However, privacy reasons does prevent us from collecting too much data, so differentiating why individual users might have different experiences (even when other known factors are similar/identical) is difficult.

Also I'd be happy to take any suggestions you have about what to look at back to my engineering team, if you're willing to share other ideas. I know we're tracking several of the ones you mention but more options is always better.

[acdha]

I mean, it really is everything. If it were my project I’d make sure I have telemetry on all UI actions and would then set a threshold (say 200ms), triage everything which has a percentile consistently over that threshold to look for easy fixes, and then set a policy that each release only improves on those numbers. I can’t think of any user-visible changes to Jira or Confluence in the last 5 years which I wouldn’t trade in a heartbeat for good performance.

[confluence_perf]

Hi acdha,

Thank you for the advice - how about on the page load side? Our biggest problem is probably the variance issue (mentioned in other subthreads) -> we can't easily tell what is the difference between a slow and a fast load in many cases.

Even if we compare things that are available from the metrics like CPU, Mem, and Network speed, those are not very granular metrics (for example, to understand someone with 16 threads was actually at 95% Mem used during that page load), and have little correlation at a wide level with page load speed.

[rusticpenn]

> but we've also heard from other customers saying they have no problems

I am sorry, there are probably customers who are used to the tools. Maybe they don't pass the Mom test. That point comes out as unnecessary defense here.

[ratww]

> but we've also heard from other customers saying they have no problems

Can I suggest following up with those customers to see if and how they're using the product, what's their computer configuration, if there's anything special about them?

[mgkimsal]

There's a bit of verbal sleight-of-hand going on - probably not intentionally.

"This is very slow"

"We have no problems"

These aren't addressing the same things, really (unless the OP was translating "we're happy with the speed of the entire system" as "we have no problems").

Are the people reporting "no problems" actual end users. People I know who've become acclimated to Jira that I know would happily respond "we have no problems" while the people below them who have to use Jira 10x more often (multiple times per hour, vs a daily look at progress, for example) would happily say "this is slow as molasses (and that's a problem)".

[andrewflnr]

Jira obviously has systemic performance problems that a few users have fast enough computers or networks to push through. There will be no shortcut to "targeted fixes" for "greater gains".

Persistently asking for particular workflows, as you've been doing throughout this thread, shows a failure to understand the scope of the problem. In fact it makes me wonder if your paycheck depends on not understanding it. It sure seems like someone's does.