In my opinion tech internet loves to dunk on Jira as it's seen as the manifestation of all the problems of Scrum and Agile. It's a "thing" people can point to so it becomes Jira's fault.
People will nit pick over, sometimes justifiable, UI/UX issues with the product but the level of hatred you see can't be explained by that alone.
Nope. Scrum and Agile are great. Jira is in many ways the antithesis of them: it favours processes and tools over individuals and interactions, it elevates comprehensive documentation over working software, and it encourages following a plan over responding to change.
Sorry I should have been more clear and said "manifestations of all the problems of Scrum and Agile have become".
Jira has implemented all those features because that's what the industry (managers and people that like control) wanted Agile to become, so, to make money they did so. I don't blame them for that, they aren't the defenders of Agile. Again, the problem isn't Jira.
If you strip away all the reporting, burn down charts etc what you are left with is an exceptionally powerful Kanban board with, in my opinion, a solid user experience.
> If you strip away all the reporting, burn down charts etc what you are left with is an exceptionally powerful Kanban board with, in my opinion, a solid user experience.
Except the reporting is what the paying users want i.e. the managers.
- Trello feels like a toy (it's not, we use it extensively for core business activities but I don't like it for software)
- GitHub issues feels too focussed on devs
- Todoist is clearly designed for solo use
- Monday.com is for more generic project management
- Notion is a mess when you have a lot of tickets
- I don't want to use ClickUp
After going though all of those I realised that Jira is pretty good for me.
I don't know exactly what your problem with Trello is - IMO it's the right tool for that space, or was until Atlassian bought it and started making it bloated and slow. Linear is also fine.
It's possible to use Jira well (ish) but it requires constant effort. If you ever take your eye off the ball you'll have irreversible transitions and workflows that only certain people can do and you'll start using ticket numbers instead of issue descriptions and end up fighting the tool more than working.
Clubhouse (now Shortcut - https://www.shortcut.com/) seemed nice when I was using it at one company.
But I guess the mystery to me is, without all the "extra" - how complex is this topic space, really? It feels like it's just a shim over something like Github issues so you can render the board, rather then anything else.
Can you elaborate on why you don't like ClickUp? I've been long in search of a Jira replacement (haven't we all) and the only one that I'm seriously considering is ClickUp. Are there any show stoppers you've seen in practice?
To be fair to them I've not actually looked at the product, I just remember something about their marketing rubbed me the wrong way and put me off the brand. Give it a go though, you might like it.
Scrum and agile work great for small and independent teams, but in practice a lot of companies (that claim to have moved to those) still work in corporate structures, that is, teams that are not independent, work needs to be coordinated across teams (which led to Scaled Agile Framework (https://scaledagileframework.com/ ... yeah), and there is a chain of reporting that requires tooling to do, especially with remote and / or distributed teams.
Atlassian, through their flagrant and wanton behaviour of enabling and encouraging such activities, are the main drug dealers to and for Scrum and Agile junkies.
Jira's UX is a nightmare. Prior to "next generation projects" everything was shared across all projects. Every single issue type, custom field, screen, etc was shared across every project and board in an entire instance. For even medium sized teams that would quickly become an untenable mess of toe stomping.
On top of that, good luck making changes to anything. The structural configuration for board, screens, and fields is buried in a maze. Something as simple as changing the options on a single select custom field (say, to add a new team) consistently took me upwards of 30 mins of clicking fruitlessly through the UX every time I had to do it, because it was so unintuitively buried and hidden.
> In my opinion tech internet loves to dunk on Jira as it's seen as the manifestation of all the problems of Scrum and Agile
Not from my perspective, I will happily 'dunk' on it because the UI/UX is so ridiculously slow and non responsive sometimes. It's a nightmare when we need to close a particularly large sprint out. Everything doesn't need to be 'drag & drop' . Trying to navigate the right fields to update is a numbers game, even if its a simple waterfall flow.
They tried to do everything and that's great. But the UI suffers for it, its slow, incredible memory heavy to run on-premise, crashes in the browser frequently. It's not the best tool for the job.
it feels like every time I go into Jira with the intention to do something, I'm shown a needy modal about some new feature that I really don't care about. and then I can't remember why I went in there in the first place. it's horrible to use.
It performs terribly and gets in the way of doing productive work. The part it does well is enabling obstructive micromanagers and giving them pretty-looking charts to help create a false impression that development is predictable.
You usually have to fill in a bunch of unnecessary mandatory fields before you can do anything, and by default you have to follow the workflows that have been set up by someone with more permissions than you. In particular that means that if you ever accidentally drag a card to the wrong column or something (very easy to do with the incredibly slow UI) you can't undo it and probably have to remake the ticket from scratch. Also it nudges you towards using the ticket ID rather than any actual descriptive name everywhere, so everything you do accumulates this extra layer of indirection.
> so everything you do accumulates this extra layer of indirection
All the issues you mention aren't a problem with JIRA but your workplace (if it's an issue). There are hierarchies and processes and you don't like it. Whether JIRA or manual it'd have been the same.
> You usually have to fill in a bunch of unnecessary mandatory fields before you can do anything
It's configurable. It's not for you but for management. So it's not "unnecessary".
> and by default you have to follow the workflows that have been set up by someone with more permissions than you
and by default you have to do work set up by someone with more authority than you.
> All the issues you mention aren't a problem with JIRA but your workplace (if it's an issue). There are hierarchies and processes and you don't like it. Whether JIRA or manual it'd have been the same.
And yet, as if by magic, they consistently happen at workplaces that use JIRA, and not at workplaces that don't.
If it were manual, no-one would stop me submitting the form with the field not filled in where it doesn't make any sense. In the unlikely event that someone chose to make an issue of it, I'd be able to at least ask them wtf I was supposed to put in that field.
> It's configurable. It's not for you but for management. So it's not "unnecessary".
They are unnecessary. Management doesn't actually use them and they don't even make sense for a lot of issues, but the tool seems to nudge them towards having a bunch of mandatory fields (maybe added fields are mandatory by default or something?)
> and by default you have to do work set up by someone with more authority than you.
Sure, but most workplaces don't have a magic trapdoor where if you accidentally pushed the wrong elevator button then you can't come back without a manager letting you out. And they certainly don't have a 20 second lag on the elevator buttons.
> And yet, as if by magic, they consistently happen at workplaces that use JIRA, and not at workplaces that don't.
Considering that there are so many variables at play, it's a very flawed conclusion. You don't have enough data. It's not magic. You're just choosing to see it as you please.
> If it were manual, no-one would stop me submitting the form with the field not filled in where it doesn't make any sense.
It just works both ways. You can't have everything. Yes no 1 stops you submitting the form but you also potentially miss a lot of things. When it's discovered the context is lost or the friction is too high or they don't even know it's missing to begin with.
You might as well just not submit it then.
> They are unnecessary. Management doesn't actually use them and they don't even make sense for a lot of issues
Well then take it out? Giving you a gun doesn't mean you need to kill someone. Responsible adults? If you buy the tool at least there should be some effort in making it work?
> Sure, but most workplaces don't have a magic trapdoor where if you accidentally pushed the wrong elevator button then you can't come back without a manager letting you out.
Again, you speak as though someone died because you had a gun - not because you killed them. Maybe consider that the company should be implementing a process or system and buying a tool to facilitate. They need to then set that tool up. If all they do is buy the tool and sleep that's on them. A lot of larger companies do hire dedicated specialist to configure and maintain workflows and the like.
So I'm not saying JIRA is the best or anything. It's just never designed as something that works out of the box for everyone. A lot of the "enterprise" alternatives are way worse and that's what it won over. I'm sure it can do a lot better but again I don't see it as the problem in most cases. It's like if you buy a Mac and tried to use it as a PC and complained about not being able to swap the GPU then I'm not really sure it's the Mac's fault.
> Considering that there are so many variables at play, it's a very flawed conclusion. You don't have enough data. It's not magic. You're just choosing to see it as you please.
I've been working in software for about 15 years across a wide range of companies and industries. JIRA or not is the best single indicator I've found for whether a workplace will suck (in particular, switching to JIRA is the most reliable indicator of when it's time to leave).
> Well then take it out? Giving you a gun doesn't mean you need to kill someone. Responsible adults? If you buy the tool at least there should be some effort in making it work?
> Again, you speak as though someone died because you had a gun - not because you killed them. Maybe consider that the company should be implementing a process or system and buying a tool to facilitate. They need to then set that tool up. If all they do is buy the tool and sleep that's on them.
I can't take it out, because JIRA only lets managers/admins/what-have-you do that, and they aren't the people who have to fill in the pointless fields and don't care.
A properly designed gun will have safety features (there's simply no excuse for not being able to undo the transition you just did, that's the equivalent of having a hair trigger and no safety), and a responsible gun store will offer safety training to buyers.
Good defaults are important, and other tools in this space manage to get them right.
The workflow thing is why the usual advice with JIRA is to keep to Atlassian-supplied workflows instead of developing your own.
The custom workflows are often mandated by clueless managers, and often even if you have clueful JIRA admin they will silently try to fix manager's dumb idea instead of having the manager eat the turd sandwich.
Once, a coworker of mine decided that enough is enough, and decided to implement a workflow exactly as specified by management.
After week or two of totally lost productivity and reporting, system-supplied workflow was returned to and the manager never again tried to play with workflows.
Absolutely this. Useless product managers adding custom fields and values that make zero sense.
Developer issues (eg. github issues) aren't the same as helpdesk requests, and aren't the same as customer enquiries. Yet Jira happily smashes them all together.
The UI problems are a symptom that Jira is complex, and they push that complexity onto the user rather than offering a simple product that forces everyone to operate how they recommend you should.
The freedom Jira offers managers is not for the benefit of any workplace I’ve ever been. I much prefer every single tool I’ve used that isn’t Jira for this reason.
fwiw Jira recently updated its UI and seems to be way faster compared to years ago. i'm still not necessarily a fan but i think it's pretty competent nowadays.
> What's wrong with JIRA? It looks good and does its job well.
I don't really like Jira:
* it is on the slower side of things, unless you throw a decent amount of hardware at it in a self-hosted deployment (then again, something like OpenProject is similarly slow, the only truly fast piece of software in the class I've experienced was Kanboard, but it's very specialized and really light on features, so not a 1:1 competitor)
* the API isn't all that pleasant to use, even though you can sort of understand that due to the level of complexity/customization (I recall struggling with a Java client library, when I had to find issues based on the values of custom fields and some other constraints I think, but it was a while ago)
* their text formatting was pretty horrendous and unreliable on the version that I used, which is perhaps my biggest actual gripe: if you had snippets of code under and issue, as well as lists, images and a bunch of other formatting, it *reliably* broke for me whenever I tried making any changes, when I tried pasting stuff in, or using the UI buttons for formatting
That said, it looks okay and I have no problem with the actual design system. In addition, if Jira lets you do what you need to, then there's nothing wrong with that either - keep using whatever works!
Take my "complaints" with a grain of salt: I last used it a while ago and therefore don't remember super specific details, aside from the text formatting being an absolute pain every single time.
The API and the search are probably the only positive things I can say about Jira. JQL is probably peak issue-tracker searching, I don't see how it can be improved. Maybe in 5 years from now LLMs can accept arbitrary input and find what I'm looking for, but until then, JQL is great.
Also I thought API is great, or at least the community python package is[0]. It's probably the best experience I had integrating with an issue tracker.
FWIW, I used it in a semiconductor company that used it to manage work on their ASICs, so things were fairly heavily customized and there were over 100k tickets.
Clearly you've never tried to format code in either an issue description or comment.
And I can only guess you've never had a product manager justifying their jobs by adding in a bajillion custom fields and field values into an issue. And then filters that use those. This case is a user problem, but the Jira does little to prevent or help.
Came here to say this. Glad I'm not alone. This seems like such an odd investment to make given the development community's near-universal hatred for Jira/Confluence.
Slightly off topic, I'm surprised why more tool or SaaS vendors don't run as Atlassian apps. It solves so many enterprise gatekeeping issues for most tools:
1. Usually integrated with the Enterprise IDP
2. apps/modules usually are part of the security boundary of Atlassian, meaning little compliance headaches if any.
3. Out of the box scaling of per user licenses since individual apps can't have their own independent user limits, they use the whole Atlassian user count. So, if your customer needs just 10 licenses but their Atlassian suite has 500 users, they must purchase at 500 user cal.
4. Atlassian Jira/Confluence are very sticky at the enterprise level. Yes, teams may move to Gitlab, but most customers prefer to stick to Jira/Confluence.
Easy answer: because you are then beholden to them, same with Salesforce apps or any other "app marketplace". If they decide to change their rules or go out of business, there goes your business with theirs. Not saying SaaS apps shouldn't go in that direction, but it should not be their first play IMHO.
For niche products, I think it makes sense. For example, we had a need for a tool to generate AWS/Azure diagrams automatically. There are a ton of SaaS options in this space, some of which just leverage opensource projects to generate the diagrams. In the gov space, I can't touch it if they aren't FedRAMP'ed. I've gone through that process as a CSP, and it's near a million dollar investment. Or the vendor can just release their product as an Atlassian App and avoid that headache. Yes, you'll never be the next billion dollar SaaS vendor but could you make a 7 figures? I'm confident you could.
Rephrased, I think an agency or company that follows the AWS model of "borrowing" open source projects and converting them to a paid service would work would do well. Wrap a open source solution around an Atlassian or similar PaaS app/module.
Atlassian design has been the ideal model for enterprise™ design for me. It's like promo videos with smiling people from stock. Look nice and clean but you just feel the rat race behind.
I don't understand why CSS developers go through all the difficult work (taking a design system, turn into a solid selection of components, implement it using SASS mixins with rules that can abstract browser quirks, variable definitions to make it easy for theme-ing) but then insist on putting all of that available through classes that require me to change all of my HTML and ignore separation of presentation and content. Just give me the SASS mixins!
Last I checked, Bourbon was a bit too low-level for what I wanted. It didn't have implement any type of design system but just gave some basic utilities for those that wanted to build one.
What I want is more-or-less what I started doing on https://gitlab.com/mushroomlabs/zenstyles. I took some of the code from materialize.css and stripped it from anything that depended on javascript and anything that required a specific layout definition. Basically, I wanted something that could work as a "classless CSS" that used the basic building blocks from materialize.css, so that I could use with code that was based on headless-ui components.
This approach let me, e.g, use my hub20 checkout component (vue.js) without any styling on its own and let people integrate whatever "theme" they wanted. I only got to implement 2 "zen styles" following this approach (the other is on https://github.com/mushroomlabs/hub20.frontend.app/tree/mast..., and one day I will get to extract it out and move it to the "zen styles" repo) but it was enough to prove to me that this approach was not only possible but made my work a lot easier.
My god.. This is an interesting project and well done. But I can't help but feel that Altassian design might not have been the best source of inspiration! But maybe someone can "fix" the cesspool of Altassian with this!
I don’t think it is the UI design of atlassian that is bad, but rather the UX and the often slow and janky pages. Nothing wrong with the styling though IMO.
I think they made the right decision. Bootstrap has been around for years and the level of experience they built up has great value.
In my view the question is "why shouldn't they build on top of an existing stable base?".
If I made that decision for a business, we would have started the discussion there. An argument for creating our own framework would need to convince me of its value to the business. Just because the company has resources to do it, doesn't mean it is the best use of those resources l.
Bootstrap has many limitations, even when customizing it with SCSS. I went down that road last year and ended up ditching it because there's not enough customization.
I can't imagine any company wanting a distinctive design for their components using it.
I have been always using Foundation CSS over Bootstrap. But this looks good. Although I am now using Quasar which has its own style already. Though quite similar.
These components look pretty good and very neutral design-wise, no screaming style, which is important for someone who's looking for a components library.
