JIRA is a 22MB download any time I go to look at my tickets and the whole experience is grindy slow.
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.
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.
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.
[0] https://docs.google.com/document/d/1g4oh2GGZOsucZfT1YJ5wjDUS...
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!
And the Award for Metaphor of the week goes to ...
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.
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.
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."
I wonder if people like this stuff? I mean are there people who mindlessly scroll through this crap and like it?
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...
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.
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.
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.
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.
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.
Way faster, way better design and the searchbar was amazing.
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.
That’s scary in a few ways I have a hard time imagining.
as long handle being wholly dependent on a third party whose API access could be pulled anytime .
It's a shame they are killing off the server products to push everyone into the cloud.
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.
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...
Things have been improved with the recent addition of pinned ticket fields, but they still have a long way to go.
Look, Atlassian is a growth-by-acquisition operation, chaos is inevitable
I appreciate your expanation of th Atlassian dev process. I've always wondered how they managed to make JIRA so slow.
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.
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.
For my other team members, they enjoy Confluence more than Jira, because Jira feels a bit difficult.
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.
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.
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?
(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 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.
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.
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.
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!
- 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 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.
(Two super-slow things combine to make the ultimate slow thing - looks like the aquisiton makes sense after all!)
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."
Returns aren’t as good if acquisition is high, like slack will be.
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.
A lot of small(ish) firms are making reasonable money doing this sort of thing; I'd count them as enterprise sales ;)
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.
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.
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.
Man, that UI is such a slow resource-hog of a bloat-ball.
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.
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.
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.
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.
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.
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.
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."
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.
Oh my.
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.
> 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.
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.
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...
There's just too many ways to "agile" in JIRA, every project/program manager I've worked with turns it into a Frankenstein immediately.