I worked on that new Jira UI (codename Bento) and it was a constant source of embarrassment for me. I pushed hard to get the powers that be to focus more on performance and payload, but it was a Sisyphean task. It was perhaps the most demotivating job of my career because I disagreed with virtually every decision that was ever made with regards to that UI, from technology choices (the inane choice to use RxJS despite literally no valid use cases, the 5+ Redux stores in the same page, etc) to UI layout decisions (insane whitespace, the baffling choices about which things go in the right hand gutter...).

The components were mostly handed down to us from a company-wide UI team whose main design goals were to bring commonality across all Atlassian products. This is a worthwhile goal, no one thinks that it makes sense that Atlassian has different editors and even markup languages between (and even within) products. But the result was dog-slow overweight components like the Atlassian editor which tried to be everything to everyone. So when you need to bring in a monolithic highly-customisable 12mb+ component for every text edit field then things spiral out of control quickly. One cool thing, though, is that these components are open source[0]. And it looks like some performance/payload work has been done since I left, thank god.

In my new job I use Jira Server which hasn't been infected with the updated UI, and it's a shame because other than that terrible UI there have been big meaningful updates in Jira. But I'm dreading our inevitable migration to Cloud.

[0] https://bitbucket.org/atlassian/atlaskit/src/master/

> the inane choice to use RxJS despite literally no valid use cases

We did the same at one company I worked for. It was a terrible decision.

RxJS is one of those things that is fun to play with until you look down and it's cutting off your legs before you even felt it. Instead of simple AJAX calls when needed in places that are logical, your app turns into this hydra of events flowing everywhere and never knowing why anything is happening or where it's happening. RxJS is what happens when a Jenga tower makes love with a Rube Goldberg machine.

And don't get me started on those damn marbles. We're writing goddamn CRUD webapps!!! We don't need marble diagrams for this. It's like that Mitch Hedberg joke about donut receipts. We don't need to introduce complexity into our simple life.

Their homepage is... interesting, to say the least. [0]

[0] https://rxjs-dev.firebaseapp.com/

Went to one of the conferences for rxjs.

Some young woman was on stage demanding that all males need to apologize to women in tech. There were other incidents.

Not a community I want to be involved in.

You are describing a typical atmosphere in the frontend and node community in general. You might find this account from several conferences in 2018-2019 amusing [0]. RxJS is in no way an outlier in this regard.

[0] https://docs.google.com/document/d/1g4oh2GGZOsucZfT1YJ5wjDUS...

How so?

First of all, who does center alignment?? Looks tacky and amateurish. This isn't a flyer for your yard sale, it's a professional company's website.

Secondly, it's great that they're involved and passionate on social justice issues, however I wouldn't lead with that as the landing page gives no idea what the company actually does, offers, or makes.

Thirdly, when you click over to their team, it should identify their role instead of just letting you click to their socials.

^ just my quick first impressions!

>>> is what happens when a Jenga tower makes love with a Rube Goldberg machine.

And the Award for Metaphor of the week goes to ...

Oh crude. Had one jQuery Developer be replaced with two 5 man teams so we could Use RXJS. Took a year for the first feature to be released. Not product, just a new page on the app.

Developers first introduced to RxJS hate the fact they have to think about the plumbing rather than the water... that is until they have to inner join 3 asynchronous sources of data and broadcast it out to their entire application.

Is this really a problem? Async/await makes async simple, and using a store like zustand gives you hooks and [g/s]etters out of the box.

Nothing wrong with Async/Await and zustand, the thing is that it doesn't maintain complexity as more sources are added, let me try to give you an example of the problem that Async/await solves versus what RxJS solves.

Say I'm installing a toilet, I need to go out and buy one from the hardware store, remove the old toilet, install the new one, and finally test that it works. It's a linear process that could easily be constructed via a series of async/awaits, and I wouldn't use RxJS to model the behavior.

Now, say I'm building a bathroom. You have a shower head, a sink, a toilet, light fixtures, power outlets, tiling, a door, and a window. You have a bunch of contractors. Now you're dealing with N number of sources, N number of tasks that can possibly done in parallel, and N number of possible things you could do in that bathroom depending on how much the bathroom is finished (for instance, if just the plumbing, floor and sink are complete, I can wash my hands)

This was always a hard problem, and not one that is especially appreciated, but I can tell you from experience that attempting to just use promises or async/await is not a scalable pattern.

Isn't the idea that if you edit something I'm looking at it would be nice if my view could automatically update? (FWIW, I would totally accept that I don't need that on a bug tracker and I probably am actually happier without it, but I can at least see the premise being interesting... being able to see point changes or user votes or comments as they happen; I do appreciate the extent to which GitHub's issue tracker automatically updates).

As a heavy Jira user, I absolutely want my screen to update when someone else updates a ticket. That doesn't actually happen, though.

Might be missing something, but how is this related? Is the assumption that this is what RxJS gives you? Because I mean...that's a websocket. And how you model the event, and handle it...is up to you. Don't need any library to help you unless you want one.

> insane whitespace

Good to hear that there’s at least one person involved with it that sees the problem with this. I imagine how the use of whitespace to organize the layout probably looked very simple and attractive in Sketch or Figma at some point. Then reality crept in, and that whitespace was gradually carved up into more and more incoherent pieces. And as that was the only indicator of hierarchy and relationships there was to start with, there’s now no organization left at all. Many screens are just a bunch of words, all imperceptibly different shades of dark gray, strewn out randomly over a solid white background.

To make things worse, they all seem to be implemented in slightly inconsistent ways (you can tell when an h1 is wrapped in ten (10) layers of nested divs, each just containing the next div) so things that should align are all off by a pixel and have slightly different behaviors.

The whitespace craze is directly at odds with Tufte-ite principles on good information design - for knowledge workers there is a delicate balance between establishing hierarchy via whitespace and producing visualizations which are appropriately dense with information. My guess is that the root cause as usual comes from designers not being consumers of the product - if they were, this trade off would be obvious.

Whitespace is good and functional in some contexts but it's detrimental in others. Imagine an Excel sheet with only 10 rows per screen, light gray text and no borders around cells. And yet this is the reality of many lists on many modern web sites. Less than 10 items per page when I could easily read 30 or 40 of them at once instead of scrolling, scrolling, scrolling.

Vanguard's new website is like this :-( used to be a medium dense table easy to compare records now on my 27" 4k monitor i can see only a handfull and its scroll city :-( https://www.vanguard.com.au/personal/products/en/overview

Can't help but think of Dieter Rams design principles. Do those principles apply for websites? I mean they are products in a way.

For this particular website I think the design is obstructing the functionality. "Good design is unobtrusive - Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression."

That's absolutely spot on! Thanks for bringing that argument up. There's a fine line between aesthetically pleasing but functional and artistically inclined and obscure when it comes to this, and it should really be up to the users' preferences. E.g. GMail got it right from the start: let the user choose their way of doing things. If the user wants 100 rows per screen or 10 rows per screen, who are you to deny the user? :)

And often scrolling with auto load, so you never really know how far you are from the bottom of the list.

Thank God for “download CSV.” I think it’s funny that I feel like some sites are just captchas to find the link to pull down the data into excel.

I wonder if people like this stuff? I mean are there people who mindlessly scroll through this crap and like it?

If someone could mockup a modern card-style design for excel incorporating the above, I think people will really get the inefficency of web sites today.

Something like this? https://i.imgur.com/lBIxryc.png

Awesome! This looks pretty on a slide deck and is an absolute nightmire to use.

AWS did something similar in the new EC2 console. Too much whitespace, too little information. I'm glad they iterated and improved information density.

I think plenty of whitespace in general (I don't know the mentioned tools that much), when done well, is a good default, because I reckon the majority of users only handle a small number of things in such tools and whitespace can help readability and look better. But the more information you have to manage, the more it gets in the way up to uselessness. I just wish any tool would have some toggle or slider where one could adjust spacing on the fly

I actually created a support ticket and also talked to someone in Atlassian through some user experience lab thing.

I didn't comprehend how someone thought it would be a good idea to move the button for a new ticket away from the main screen to that sidebar thing where it took an additional click to do so.

Yes lets add another click to the most used function in my workflow...

Kudos for at least trying.

For one large web app I worked on, we had a setup where browser loading time would always print out in the dev tools console. We had no hard requirement for UI changes to stay under a certain threshold, but seeing that loading time with every refresh during development was enough to keep us mindful of payload.

>whose main design goals were to bring commonality across all Atlassian products. This is a worthwhile goal

the issue here isn't the goal itself, it is that such highly visible efforts - "common platform", "common UI", etc. which are very complex technically to do right - invariably bring up to the top and into the deciding positions those "drivers of cross-organizational/functional/etc. change" style people whom you'd really want to be staying far from such important and complex technical issues...

I worked with Jira in 2012-13, it was appallingly slow. Making it even slower is an achievement.

> insane whitespace

THANK YOU (sorry for shouting). That's my biggest pet peeve with the new UI.

I feel like I'm using some mix of Mac OS X UI and a child's toy. Everything is so big and spread out, there's barely even space for longer text areas.

Don't even think about putting windows side-by-side with JIRA taking half a screen, it's unusable.

This is fascinating to hear.

Sometimes with Jira updates, I have to ask myself “What WERE they thinking?” It’s good to hear that actually some people (well, at least one!) inside the org ask this too.

For what it's worth, I think a lot of people put misplaced blame on Jira for their own broken process.

Jira is a tractor trailer. It's big, it's powerful, it's a bit slow to get moving, but (1) it can carry just about anything (2) once it gets moving, it tends to stay moving. There's a lot of value in having a "do it all" project management system.

That being said, there's also value in alternatives that are more tailored towards specific needs.

We were avoiding creating issues because of how long it would take to do with JIRA. I had to stop and wait between sentences because the JIRA edit box couldn't keep up with my typing.

Have you tried the alternatives like YouTrack?

Way faster, way better design and the searchbar was amazing.

I'm normally not on the hate bandwagon for this sort of thing but the Jira UI has deteriorated to the point where it's an actual impediment to getting work done.

In the future, when cursing the developers who are responsible for this, I'll bear in mind that sometimes no matter how good the individuals in the team… it's sometimes impossible to salvage a good product.

Wait, so you are telling me that the unuseable UI I’m currently using on server, is actually the better of the two?

That’s scary in a few ways I have a hard time imagining.

The horror

I think there is case for making and selling and alternative UI for Jira.

as long handle being wholly dependent on a third party whose API access could be pulled anytime .

They do exist! https://getbodo.com/

“Sales have been halted until further notice.” Hmmmmm

API for Jira Server is not going anywhere. Of course the product itself will cease to exist in a little while, but most places where Jira is terrible are on datacenter anyway.

These JIRA UI updates are also an accessibility nightmare.

Good to finally hear from the inside what everyone on the outside sees.

It's a shame they are killing off the server products to push everyone into the cloud.

> One cool thing, though, is that these components are open source

Except going to https://bitbucket.org/atlassian/atlaskit/src/master tells you to go to https://bitbucket.org/atlassian/atlaskit-mk-2/src/master/ which then tells you:

> Unfortunately, that code no longer resides here as it’s all been moved to a new closed source location.

in case you want to view the repo, it's linked in the https://atlaskit.atlassian.com/ (menu -> resources).

The breadcrumb to get to it is a bit crazy, but https://bitbucket.org/atlassian/design-system-mirror/src/mas... is the old mirror, which has a link in the readme to the new mirror: https://bitbucket.org/atlassian/atlassian-frontend-mirror/sr...

If it can comfort you, there are software which are a lot more worse than Jira (check out HP ALM :-) )

I do enjoy the new Jira UI a lot more than the old one, but yes it is definitely slower and is missing some key features (hotkeys for editing specific ticket fields please!).

Things have been improved with the recent addition of pinned ticket fields, but they still have a long way to go.

I gave up on JIRA-1330.

Look, Atlassian is a growth-by-acquisition operation, chaos is inevitable

If you have a say in things then try to get your company to switch to Clubhouse. It's everything JIRA should be and it's blazing fast.

I appreciate your expanation of th Atlassian dev process. I've always wondered how they managed to make JIRA so slow.

Having used clubhouse extensively, I'd say the absolute opposite. It's missing basic features, reporting is a joke and while the trelloesque usability is nice that's the only thing really going for it. It's also more expensive than Jira, which is completely bananas.

I guess it depends on your use case. We're a small company: it has all the features we need and we're on the free plan.

> I pushed hard to get the powers that be to focus more on performance and payload

If I was in Atlassian's situation this would be the last thing to focus on.

a) This is the biggest ever rewrite of their most important products. In this situation maintaining feature set compatibility is always going to be priority A, B to Z.

b) Their paying customers are mostly in the enterprise space who have very fast internet and stable environments i.e. payloads are quickly cached.

The key is jira and most atlassian products are feature mountains to be sold to upper management, but I can think of no end-user person that likes to deal with it on a daily basis. Then someone in the vein of slack or Asana comes around and eats atlassians lunch because they’ve neglected making the product good for anyone other than executives.

1) End users are not the buyer. It's the Head of Delivery, Iteration Managers, Agile Consultants etc that are. For them JIRA is great because it's heavily customisable and scales across the enterprise. It's actually quite hard to balance this with a great end user experience.

2) They are in the middle of a complete UI rewrite and I've only briefly used it but it's definitely much better than the previous versions. I imagine the Trello acquisition is also going to help them here.

I actually use Jira, Bitbucket and Confluence (all Server versiob) in a small team (maybe 5 people) and I really enjoy it. It‘s good in what it does, it does the things you want it to do and the 3 tools are good integrated.

For my other team members, they enjoy Confluence more than Jira, because Jira feels a bit difficult.

We have a gigabit connection but that doesnt make the site any faster. Not sure how much is being cached or what the bottleneck is...but there is something seriously wrong with the site's performance. It has become so slow I honestly think performance is the cause of fewer and fewer Jira tickets at work (people used to make tickets for tiny isolated updates to track them finely, but now it all gets shoved into the commit-of-the-day) and fewer updates/comments. People seem to interact with it only on sprint ends when they must do.

Well, they have succeeded in turning my entire team off JIRA. We basically don't use it anymore, mostly because their A B Z priorities didn't include making it not feel painful to use.

It's crazy to me when I can't type in JIRA... or when I drag a ticket to a new column, and it just doesn't go, and I reload and it's still in the old column. Or when I try to click a ticket and it just doesn't open.

The not being able to type fluidly has to be the worst though.

Our team has as well at least brought up the idea of potentially trying other products.

Some of it's probably me not really wanting to get involved with JIRA in the first place (who wants to manage tickets), but in the interest of being a better employee I've been trying to make sure I'm squaring out my work properly for tracking, etc.

And there's certain things, that I'm sure are there, but I just can't find sometimes. Like... how to add an epic easily. There's at least three different views for each ticket (when you create it, when you click it open into the modal, and the full screen view), and things are apparently in different places on those different views?

I'll take some of the blame, but it's a mess.

You’ve used enterprise products before right? Making it painful to use is basically priority number one.

Don't forget,

c) Pushing folks to their cloud offering, partly by

d) doubling the cost of on-prem.

The surprise price bump really pissed off people here; that, combined with doubts about their long-term commitment to on-prem put evaluating alternatives on the list for next year.

Being a tool no one loves is a bad place to start changing a bunch of stuff at once.

About that b). It‘s less about internet speed and more about your CPU not being fast enough to render everyhting in a useful time. With all that lazy loading, the browser is stuck with rendering for a couple of seconds - for each page...

This is why the browser isn't the best place for things like this. A Fat client is better. I still don't understand the push for webapps, when we have all this hp, storage is cheap, and we have modern installers that don't splat everywhere.

The browser is perfectly capable of stuff like project management workflow apps when you’re not shipping 22MB of useless abstraction layers in a runtime language.

I'm still amazed that JIRA redesigned the UI and chose to relegate the date the ticket was created to a "secondary piece of information".

Every time I look at a ticket its like the 4th or 5th thing I check, its such useful information and they've allowed themselves to be so far removed from their principal use-cases its extraordinary.

Unless maybe it was my org that foolishly decided to configure it away?

The id is a proxy, ignoring cross project transfers

I hate to be the "but it looks so easy" guy, but why are all these "behemoths" such a huge mass of things for essentially CRUD-y stuff with e-mailing bolted on?

(and yes, you could water, i dunno, facebook down to that, but still, these are... trouble ticket systems..? what am I missing? Scaling?)

This is a fair question, you shouldn't be downvoted. Lean ticket trackers and productivity tools are perennially launched and invariably become as bloated as the incumbents.

This is because the information in these tools is business critical and needs to be consumed by almost everyone in the company. Moreover, different people need access to the same information in different forms of presentation, with aggregation and emphasis of different data. In contrast it's easy to make a work tracker just for developers - GitHub and GitLab have pretty much solved that problem. Making a ticket tracker which works as a single source of truth for all members of an organization who need access to the tickets is much more difficult.

Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate. You can't just target a single group here, because then you're trying to get the company to adopt separate repositories of work (it's already an additional complexity that work is split between e.g. GitHub and Jira, for example).

So to obtain the critical mass of adoption they need for product market fit and growth, these tools organically evolve to become everything to everyone in an organization. And suddenly your tracking tool is stuffed with metrics, integrations, feeds, dashboards, reports, etc.

The other thing is that these tools become especially bloated by integrations and plugins. A brand new instance of any tracker or project manager feels clean and fast. A few years in, it feels slower and more crowded by all the custom/third party additions rolled into it.

> Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate.

I realize this would be a lot of work, but I would be really interested to see some examples of "the ticket the developers want", "the ticket the VPs want", "the ticket the designers want", etc.

Role based UI can be the answer.

Yeah, that would be the modern solution. As far as I can tell even Salesforce has tried that with role-specific views that are customizable. But somehow it just converges back to everyone having everything all over again, but this time with 8 different frontend views to be maintained.

I've worked on these sort of problems, and I can guess why.

What happens is that a new field gets added, and whoever's adding it claims it's really "important" and needs to be seen by everyone. It'll invariably set as mandatory to be filled in too.

2 years later and some integration breaks because the integration doesn't set that field and you end up looking at that really important field and every single project has it set to exactly the same value.

Repeat ad nauseum.

The other thing I've seen a few times is when assessments or a bonus depends on some field so they make it visible to everyone. Then the bonus scheme changes, but they never hide the fields that no-one cares about any more.

> when assessments or a bonus depends on some field

Ugh, this reminds me of a mess I inadvertently participated in..

A certain employee, on an unrelated team to mine, decided to to go down the route of becoming an agile/scrum master/evangical and somehow got "reduce instances of X" as their personal KPI/development goal one year. Soon after this, they're pinging myself and other team leads on slack whenever X field is filled out on JIRA and demanding justification. Eventually because of this harassment I just stop filling out the field, leaving it as the default value and just verbally communicating the fact to whomever needed to know. Later on I find out that I wasn't the only one that took this route,And guess what happened next! The scrum master is promoted to a management position, in part due to their stellar KPIs! Excellent work all around!

Someone has to pay for complexity. Let that be vendor and it’s engineering. Rather end users.

Scaling is only half of it. There is a lot more to Jira than just CRUD over a few entities. It's trying to be issue tracking and project management rolled into one. For example:

- Workflows

- Access control over fields

- Custom fields

- Release management

- 3P plugins and integrations

- API access

I am far from being a fan of Jira but they do have a rather large set of features. Every time I evaluate the hottest new issue tracking and/or project management solution, there is something lacking as compared to Jira.

I've often half-joked that the road to JIRA is paved with other project management tools and ticketing systems.

I don't think anybody really sets out with the intent of using the one reputedly cumbersome tool that can do anything - but after growth and pivots and new requirements and new teams and special workflows... you end up needing a combination of features that is literally impossible to get with any other tool, and who wants to fracture into multiple tools?

So you get JIRA. And it just does it all, and even if nobody is overjoyed, nobody feels like they lost, either. There's value in that.

https://restya.com/core-jira-slack-alternative seems to have covered all these area. (I'm on their beta program)

Got it, thanks.

JIRA offers an almost limitless amount of customization to fit any workflow. I think the custom attributes/fields/reporting part of it adds a lot of complexity.

Yeah... and once it comes down to a company's pm level, they all lock it down to what they think is the best, leaving teams using something that is guided towards PM and reporting, instead of getting job done.

Got it, thanks.

JIRA is the slowest website I use in current year. If it was a consumer site like Youtube or Twitter, I'd long stop visiting. You can feel the gears slowly turning whenever you click something. When I click the wrong button I get that pang of anxiety like you used to get when you accidentally opened Photoshop back in the day and had to wait the 20 seconds for it to load.

Creating a ticket in Jira is a pain I try to avoid. I've never seen a worse UX for something that simple. I hate it with passion, and my computer does too, always spinning up cooling fan. Then I create it, and of course the formatting us fucked up. Every single form has a different flavor. Preview shows something else to what will show after submit. You press edit and you see a completely different syntax. One couldn't make the experience so bad even if they tried.

I'm leading implementation of a software up at a remote arctic mine site (geostationary satellite internet) and have to manage our issues on the vendors Jira implementation. It takes about 5 minutes to load the site the first visit. It's dreadful.

Can you use JIRA APIs through Postman instead of UI in your case? It won't be super convenient but at least it would be faster I suppose.

Nah, Slack is way slower than Jira for me.

(Two super-slow things combine to make the ultimate slow thing - looks like the aquisiton makes sense after all!)

slack website or slack electron app?

They're of the same ilk as Oracle/SAP.

They need to absorb things so their sales team can say "oh we have X feature" regardless of its actual implementability and just leave it to the consultants to struggle and somehow implement a half baked solution that doesn't work in the end.

Oh but that's how they make money also. More products, more features, more crappy integrations = more service contracts, more consulting work, etc.

All a huge scam that enterprises are forced into because they don't want to be "left behind in the digital economy."

Also, these companies have MASSIVE sales forces (no pun intended). By acquiring a decent enterprise product and throwing teams of sales guys on it they can make a lot of money.

Returns aren’t as good if acquisition is high, like slack will be.

Note that Atlassian doesn't have an enterprise sales team.

They are a pretty notable company in startup history since they were the first to be hugely successful at using the self-service model for enterprise sales.

They do have a partner system however which is widely used, you need a number of staff who are atlassian certified on your staff then you become a <some level> partner, and get a cut of the sales you make.

A lot of small(ish) firms are making reasonable money doing this sort of thing; I'd count them as enterprise sales ;)

Its also just much more efficient.

One central high quality HR Team can scale easily in a big org while the same amount in small companies need spend more on HR.

And its not just HR of course.

I wouldn't even trust small companies to build a modern and secure cloud product. While big companies have their own Security Teams and are able to afford a normal security audit, for a small company that means 1. much higher cost in relation and also binding of personal they might not have.

I have worked in a very small company which basically couldn't spell security. And i'm now working in a very big company. There are plenty of people who also can't do that but there are teams only for security.

I don't have to justify now that i'm doing things securely. Thats how it is. My manager will not sign the risk away; He actually can't and people are not keen of asking upper upper management for that.

> Its also just much more efficient.

That's the sales pitch, sure.

Size scales in reverse order with security. The larger you are, the more difficult it is to make sure all the gaps are sealed - that's why the greatest of empires fall eventually - they get spread across so large a portfolio there are bound to be gaps, which are endlessly exploited, even on users of the large ERP companies.

If products were actually integrated well and deployed well all of what you say would be true. But that's just not the reality - trust me, I've been there. It's bad.

Thats not just the sales pitch. I experienced it practically and i brought it up as an example.

I don't know where the sweat spot is, but i don't think it is at a 10 person company. I believe its more in the range of 500 or 1000 person company.

Work anecdote: Before I discovered “openssl speed”, I used JIRA to find race bugs in JS tests - loading up a JIRA ticket while running the test in a loop would spike the CPU for long enough to trigger the race. :)

Man, that UI is such a slow resource-hog of a bloat-ball.

Man, what happened to Atlassian? At some point in the not-so-distant past they were the gold standard, or at least I thought they were. Now they seem to be a cautionary tale.

Revenue was $1.6 billion in 2020, up 33% from $1.2 billion for 2019.

Growing at that rate at this point in your company's lifecycle is pretty extraordinary. So not sure why you would consider them to be a cautionary tale.

As for what has happened to them. They have been on an acquisition binge the last few years e.g. Trello, StatusPage, OpsGenie, Mindville etc. And as mentioned above they have been rewriting their UI in a new React framework called Atlaskit.

I also used to think Atlassian was a pretty poorly run company but then you look into it and actually the opposite is true. Although they did let Github, Gitlab, Slack dominate them.

Next few years will be interesting as Gitlab is moving very fast into their space.

Sales and Revenue do not always equate to quality and user experience. All these companies when they get to this size start to lean on M&A vs build it yourself. Look at the history of Oracle, Microsoft, IBM and you'll see the same pattern.

Slack is the new Sharepoint, everyone uses it but no one really wants to and it doesn't really fit the bill but everyone else is doing it so companies adopt it.

Slack's value is in selling the idea of async chat to managers and making it mainstream. I don't feel as nauseous using it as Sharepoint, but it does seem to be buggy and crashy in places.

For me slack is a very simple deal:

Microsoft Teams Chat UI is garbage. It uses a lot of space, i can't just have a list of channels, no i need groups etc.

It even doesn't matter to me if its slack or hipchat or matrix or whatever. I don't know why we migrated to slack.

I don't get why Teams doesn't provide a lightweight chat typical UI. I would just switch to Teams. After all video calls are much better on Teams and more stable.

But then Slack integrated Teams and Zoom. They clearly don't want to compete in this area and i also don't get why.

Gitlab is not in any way a Jira competitor.

And yes, Atlassian did drop the ball. We'll see the fallout in five years, I don't see how they can save the company now.

My observation as a user is that it's still good if you are starting a new account from scratch. But if you have been using it for a decade and made lots of customizations and added plugins over the years, they get more clunky as they continue to update their product.

This is it.

I don't even think Jira is specifically bad. If someone was only using it for basic project managment and ticketing, it'd be acceptable.

However, occupies the same niche as SAP or Oracle businessware.

First, Take a service that must be ergonomic because people rely on it all day to do their job. Next, make the primary requirement the ability for managment and finance to run reports. Then, outsource it to a company that wants to add custom web frameworks on top of a decades old project. Finally, graft on decades of customizations done by different generations of contractors.

Agreed. Jira makes it easy to add a new field, plugin, or workflow step for a particular use case, but it is much more difficult to determine if an existing field/plugin/workflow step can be safely removed. As a result, everyone is afraid to touch it, projects accumulate cruft over the years, and it degrades the entire workflow. The problem is especially bad if there is shared ownership of JIRA, and therefore everyone feels empowered to add, but nobody feels responsible for the dirty work to clean up the mess from time to time.

My company had resisted the urge to bolt on additions more than most. We recently migrated from Cloud to on-prem Server as a result of being acquired, and it is amazing how much zippier our project is compared to some of the peer projects that have accumulated cruft.

Yep, agreed.

If you can admin your own Jira instance and keep the fields and plugins to exactly what you need, it's pretty nice. I keep going back to it for the customizable workflows and fine-grained access control.

Unfortunately, every corporate Jira instance I've ever worked with has been overrun with every possible field possible, an unnecessary and constantly shifting mishmash of plugins and horribly slow access. You're paying the price for all of that cruft that you don't need and which can't be removed because "maybe someone wants it."

> every corporate Jira instance I've ever worked with has been overrun with every possible field possible

I've seen multiple different fields for the same value, each of them created for their specific team. The instance is slow AF most of the time due to the bloat and often I can't even assign a sprint to a JIRA because the field doesn't load anymore.

Cruising along. One issue though is that the integrated knowledge workflow is complex.

I didn't believe the 22 MiB download but it's true. 156 requests and 26 MiB with an empty cache.

Oh my.

And that's a site without any etxernal tracking or ads. No images either.

But their horribly inconsistent UI and UX a big tell why it is this way. They simply serve you multiple versions of their website, each for different component. And together it's a giant mess.

Yeah, just checked a random ticket and got 223 requests and 37.6 MB of resources, DOM loaded in 19.48 seconds (granted I'm on a slow connection)...

> But their horribly inconsistent UI and UX a big tell why it is this way.

It's insane how the editor changes between creating a task description, to editing a task description, to writing a comment. Like three separate teams with loose guidelines created them. In reality it's probably more like 7 teams.

I hate Atlassian with a passion and the only reason I touch it is because I'm a corporate slave.

I've witnessed internal confluence pages with Facebook likes.

What they have in common is that the people ordering it are not the people using it. These companies focus on the former, who want different things to the latter. Which sucks for the users but it makes sense for the vendors.

Indeed. This reminds me of the tweets about why enterprise software is like baby clothes: https://twitter.com/random_walker/status/1182635589604171776...

And yet at my last two startups, when we could literally pick any product on the market - there was tremendous pressure from product, project management, devs, and the business to use JIRA "because it worked just fine at the last place I worked and even if it didn't, at least I'm familiar with it". I'd love to see a killer Jira replacement that people don't say "in spite of how ugly and slow and barely useable it was, I still love Jira".

We finally migrated to Youtrack and everybody is happy.

Spot on. This also feels like a strategy that won’t age well. It’s tough if not impossible to deliver great UX from a bunch of acquired pieces. Slack’s relatively short path to wide adoption is evidence that the world is less and less tolerant of poor UX, even in the context of business software.

We got fed up with Salesforce's absusive behavior to smaller companies, or at least the behavior of the finance team we were assigned to, and left. We did an emergency Salesforcectomy in 30 days, switched to a new product, and honestly everyone who uses it is a lot happier. SF buying Slack worries me for the future of Slack.

22MB ain't so bad ... oh you mean to view the page!

At least they haven’t messed with Heroku.

I'm not sure that's actually the case at this point. Given it is not 10 years into the acquisition that is a pretty long time for it to still not have been engulfed in the mothership, but that time seems to mostly be up now.

Good thing we have competitive (and cheaper) options now including Digitalocean app platform and Render.com. I'm actually surprised it took this long to match Heroku (and beat them on costs).

True, but neither are really optimal for serious production use. I've looked at them both extensively as I would love to move off Heroku due to pricing. DO App Platform is still really immature and lacking in a ton of areas. Render is much more polished from a usability standpoint, but AFAIK they don't have any sort of High Availability offerings and have had significant downtime recently.

Heroku, on the other hand has been a hassle-free solution for my company over the past 7 years, and short of a few outages (which were actually the fault of AWS from what I remember), it has been absolutely reliable.

Just came across this comment (I work at Render). We did have 2 hours of downtime on 9/11 but it was the only big uptime incident in 2020, and we haven't had any major incidents since (even when AWS was down for 5+ hours).

We've worked hard to incorporate reliability lessons learned from building the platform at scale especially as we've grown [1], and I hope you'll give us another chance. If I can do anything else to help, my email is my HN handle at render.com.

[1] https://www.tfir.io/more-than-100000-services-created-on-zer...

Maybe this is the wrong place to ask, but are y'all planning on adding an s3 comparable file storage service? That would be the missing piece for us.

Yeah, Heroku is awesome. I'd stay with them (despite the price) if I could run distributed Elixir.

They immediately destroyed the free tier

How so ? I'm still using free tier dynos for small tools and workers just because I don't need anything more.

True, but the Hobby tier is compelling at least.

Dunno about that, the Heroku UI seems a bit stalled in development.

I hate JIRA for this reason, and just the insane level of complexity it almost instantly breeds.

There's just too many ways to "agile" in JIRA, every project/program manager I've worked with turns it into a Frankenstein immediately.

Here's a fun exercise in technical debt. Navigate to the Salesforce Idea Exchange and upvote any idea. You will be redirected no less than 13 times and after which you will no longer be on the page you started on.

Jira has some of the most staggeringly stupid design decisions I have ever seen. I get so frustrated trying to do anything in their interface and it lags so badly on my outdated office hardware.

You're right, slack will fit just right!

Working on something faster: https://linear.app

Strange how no bug system is remotely as good as Bugzilla c. 1997 was.

Heroku which was acquired by Salesforce seems to be doing ok ?