My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some internal specialist Jira admin(s) to make your changes.
Also, in the last couple of years it's got a lot better. It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
In detraction: configuring it can be a huge PITA. So many screens, concepts, and so much clicking. But when it's done it works, and I think most of the hassle is just inherent complexity from such a configurable tool (if you haven't Admined Jira: you can change almost anything).
Jira is organization poison, not just a reflection of what an organization is.
JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration. Now, there are plenty of products out there that suck no matter how you configure it (looking at you, ServiceNow).
Especially the comments about "I would rather use trello" seem extremely uninformed as you pretty much *are* trello when you just stick to one kanban board and one project.
My guess is it's because Jira actively targets SMB, while ServiceNow is almost strictly enterprise, and folks in enterprise have already resigned to their fate.
Having a Service Desk that actually provides usable and composable tooling is a benefit for all. Having a random contractor "implement" ServiceNow because Gartner said so is a pain for all. This is of course a bit of opposing extremes, but the same applies to JIRA and AD and pretty much anything else. Hard-pushed bad implementation will ruin your workday.
Teams that are capable and allowed to self-steer and deviate from company policy if they come up with a good enough reason seems to be the sweet spot of attainable & realistic.
We dropped SN a couple years back over this. They were charging us about 6-7x what we pay for Jira, and we still use the on-site enterprise version of Jira.
Usually, if it isn't better from a staff-perspective or better for the customer, self-hosting or self-building is less likely to be the answer these days.
Eventually somebody with the organization obsession is going to get hired and put somewhere important and their goal is going to be making something complicated and unified and dissent will be "discouraged".
On the other hand, like almost copy-pasted here, if a top-down 'unification make it worse for everyone' effort is started, no vendor or tool is going to stop that and your work will get worse.
That's kind of the point, JIRA has been made into monstrosity at many organizations because the "create anything" mindset.
> it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common
with pretty much everything, including a spreadsheet or a plain text file.
Conflating bad business practises with tool configuration or products in general doesn't help anyone. If a business is very stiff and scared of its employees, they will try out all sorts of useless control methods hoping it will somehow make some metric 'better'. You can do that with Trello too. Doesn't make Trello a bad product, and it doesn't make JIRA a bad product.
At the same time, pretending a larger organisation with many teams can function without any form of state tracking is a nice dream but not a reality either, so it's not like you can do without anything at all. But like reposted a bunch of times, how you do it and who is responsible for it is pretty important.
Tools can't prevent bad management because bad managers don't care about tools. They care about getting what they want, and if the tool doesn't enable it, that's their underlings' problem, not theirs. Jira doesn't stand in their way because nothing stands in their way.
Given the amount of effort you devoted to replying to multiple posts, it feels disingenuous when you make an obvious and inaccurate statement as fact.
There is very little dependency graph organization (eg subtasks), which isn't reflected in most of the UI anyway as JIRA does push toward treating all tickets as a flat set. Work is a practical hierarchy of concerns and JIRA never made much progress away from a checklist (same as ASANA, Rike, etc).
"Implementors". Anything that needs to be "implemented" is either a) not finished, b) too big and complex, or c) both.
Dunno for sure how much less code Jira has compared to, say, MS Excel or Adobe Acrobat, but I could imagine it might be up to an order of magnitude. But you don't have to "implement" those; you just install them.
But no, that's missing the point: That's what makes it an equally stupid "Enterprise product". Excel, OTOH, is arguably more essential to more corporations, and yet you don't see big international consultancies snap up contracts for six-year-long "Excel Implementation" projects with Fortune 500 corporations. You do see that for SAP, Oracle Business Suite (or whatever it's called nowadays), etc. They're products that you don't just install and use; they need to be "implemented". JIRA is more like that.
Or, IOW: I wasn't comparing, but contrasting. (Which, OK, is also a kind of comparison. But for this kind, it's Excel that is the better example than Teams.)
That's the problem with any tool, framework, language, etc where the defenders main argument is, "It's great as long as you don't abuse it." or to put the former bluntly "It's not the tool, it's your organization." Over and over and over again, if an organization is allowed to abuse and misuse something, it eventually will.
Good tooling has opinions and will give you guardrails to not hang yourself.
As organizations and projects grow you or someone else will at some point hire incompetent people that mess up this delicate balance.
Better to have guardrails.
Customizable, absolutely to a fault. It is the infinite customizability of a tool targeted towards middle management which is why Jira can go to hell.
It is indeed possible to not be in Jira hell, but inflation of complexity is inevitable and almost entirely irreversible. It encourages and accelerates the path towards bureaucratic hell. Any avoidance of this is a temporary aberration.
I though so too, but now I no longer believe that's the case. This is because of two reasons: one questions the statement itself - and the other one questions whether the statement correctly identifies the organizational issue.
Firstly, almost every tool I ever used for project organization has grown to similar degree of complexity. All _software_ employed was strongly incentivized to implement new mechanisms of automation and regulation - thus right now I would struggle to name a non-defunct and non-single-user tool that doesn't have the issue. And certainly no tool that that I would call "established" - an arbitrary designation, to be sure, but that largely reflects that the complexity almost _defines_ establishment for a project management tool.
Secondly, because I think the issue isn't, truly, the _bureaucracy_. Right now I believe it's the _technocracy_. It's the belief that every process has to be codified into software, and enforced in a manner that would make exceptions impossible without a pull request. This leads to - increase in complexity (because corner cases that would be easily solved with a quick email exchange now require weird workarounds - and if they are too common, actual change to the software) - reduction in real organizational flexibility (any special case is now discouraged on a technical level).
Worst part is, it's very hard to sell a shift away from this. Technocratic adherence to software-enforced processes became nearly synonymous to "accountability." In itself that's frustrating to me - I believe this serves to paint organizational failures as forces of nature, effectively reducing accountability. But, so far, I have failed to effectively communicate it to most people - with exception of the very few who, themselves, have a considerable interest in social dynamics, one that goes beyond the professional interest expected of a manager. And to those, those are generally truisms - I'm under no impression I'm particularly original here.
---
Aaaanyway, I went back to liking Jira - because, under all the cruft, there's still (or at least there still was) the basic bug tracker software that's almost like Bugzilla, but slightly less painful. And I like bug trackers, as long as they're used to track bugs - not manage projects. Projects are managed by people, and these days I believe that the reason all this software, as complex as it is, keeps failing to accurately communicate the project state, is because you would need the software to be a person.
> by default regular users can't change the available transitions
I can't imagine allowing this. This would be a recipe for chaos. The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
If that's okay on a team then that team probably shouldn't use Jira. I also would not want to be the team-lead, or anyone else trying to figure out what's going on or keep track of work!
Everywhere I've worked the states have been the steps, the transitions have just been there for Jira's own bookkeeping. And in the real world it's always possible to move a piece of work to any other step in your workflow - things like "the designer's realised he messed up the wireframes, put it back to design even though it was currently in code review" happen all the time. I don't think that's the same as not having any process.
In the Jira way of doing things you can't do that if that transition doesn't exist, and you probably don't have the required permissions to add that transition (if you can even figure out what they are). Couple that with Jira's terrible performance and I've been in more than one company where you could accidentally drag and drop a ticket to the wrong column (because Jira decides to finish loading at the wrong time) at which point it's permanently fucked up and your only option is to copy and paste the data (one field at a time, natuarlly) into a new ticket.
> Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.
You can make it be pretty much anything you want - except, you know, fast.
While the Golden perfect abstraction handed down for the heavens by the gods is what you seek, it ultimately passes down complexity to end users through its generic approach. You need to create opinions within the generic world and then your team needs to understand Jira's abstraction combined with the opinion your company builds around it that's probably not documented.
The end result is unless you're running a large project that really requires the functionality possible in Jira where creating the overhead or overloading something simpler isn't practical, then you're probably better off using something simpler and more opinionated--a nice simple solid framework to keep everyone on track.
I only fill points and name for my issues. My company never customized anything.
I'm in the Jira is actually pretty good camp. I've administered Jira instances from the ground up, including installation, integrating it with directory services, customizing workflows or just as a user in large and small organizations.
The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable. Some transitions make more sense than others. It was also quite tedious to create transitions from "all other states" to some state. So admins were incentivized to only allow transitions that immediately made sense to them and not bother with the others. From the end user perspective this obviously looks like draconian overlordship. While in reality in many cases its just too tedious. Atlassian has heard user complaints though and an "all states can transition here" option is available since some time ago and the default workflow for some types of projects are basically just a few workflow states that all have this transition as the only possible one. Basically transition from any state to any other state. No transition screens. That's pretty open.
If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira. Locked down workflows and transitions, restructured editability etc do have their place in many valid use cases. A simple one being as a customer facing tool where you need to enforce certain things directly because your customer is not first going to learn your conventions and then self apply these.
The same goes for mandatory fields. The only mandatory field you have to choose yourself really is the issue summary. Everything else if mandatory by default has default values. I have used many a Jira instance where Priority (a default mandatory field that also has a default value though) was all but ignored by everyone even if it was still on screen.
Can you elaborate on the reports that only micromanagers would ever use? I agree that some of them can be used by micromanagers as can a lot of Jira functionality. There are many that can also be very useful directly in the hands of teams.
Team managed projects are awesome because sharing Jira admin rights in a large org was hard. Because things are so configurable a good set of naming rules were essential. It was usually easier to set up individual instances for projects instead of having a shared instance for large orgs. And if you centralize administration too much then changes grind to a halt. I have shared admin right with many others successfully though where these standards were adhered to by everyone and changes to work flows, issue and custom field definitions and such were easy to get through. Just required discipline.
That's probably where the wide-spread (and arguably correct) impression that it has become worse comes from: To begin with, people just installed and used it as-is, but by now corporate bureaucracies have had time to "implement" it -- i.e. set it up -- to mirror their organisation's bureaucratic structure and processes.
And yes, that impression is correct; it is Jira's fault: If it didn't have that customisability, they couldn't (ab)use it that way.
> If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira.
Of course you can: If it didn't offer the possibility to set up those bureaucratic locks, they wouldn't be set up.
You and other people are obviously entitled to the opinion that Jira made it worse.
In my book, that's like saying it's the Swiss Army knife's fault that someone was killed with it.
Came here to say EXACTLY this. I've used Jira across 3 companies, and in the first 2, I always felt like folks complaining about Jira were just being picky developers wanting the sun, moon and the stars, because Jira worked perfectly fine for me and my team (in fact, it was the backbone of our process).
Then in the third org, I felt like I was hit with a brick wall of every single issue folks complaining about jira point out. Needless workflows, Middle Managers wanting to "control" how stories/epics get closed, multiple levels of convoluted manual configurations, automated processes creating Jiras that for trivial non-issues which clogged notifications and team backlogs and brought jira to a crawl etc. Heck, at one point, the mess got so bad, that the company considered hiring a third party to "fix" our Jira workflows. And note that this was a <100 person startup!
On introspecting, I completely felt that in the first 2 companies, the organization was structured around "getting stuff done" and "keeping stuff as simple as possible, but no simpler" and that naturally flowed into how Jira was set up as well, while in the latter, the focus was entirely on top-down "process", and that showed in the Jira setup as well.
Honestly, I now think I can say a lot about a company's engineering/product culture just by spending 15 minutes on their Jira ;-)
once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.
Overall, we are very happy with Jira and it's worth the cost for the value it brings to the organization (still hurts the wallet, but it's at least justified).
...and then Atlassian comes along and rug-pulls on-prem Jira.
We only have ~80 users, so 1000-user-minimum data center isn't going to cut it for us. And there is an on-prem requirement, so no cloud option either (wouldn't want to anyway). And for that, I bitch. Fuck Atlassian and everything they do to appease their shareholders before the customers.
Honestly I reckon half of Jira's reputation for slowness could have come from bad on-prem installs. The cloud version is not slow, and Atlassian does do work on performance
https://community.atlassian.com/t5/Confluence-articles/Confl...
Also no shortage of folks elsewhere in this discussion talking about cloud slowness.
We've had plenty of irritations with our on-prem, but slowness, not so much. And yeah, for us it's mostly about keeping the data internal.
There’s a ton more indirection for userids. Screens that used to be part of my standard workflow have Ajax handlers. Even name completion is slow.
The #1 question answer on the old ui survey workaround asking why are you using the old ui: slowness.
Confluence also got clobbered. I can count page load times.
I think it's more of a software problem tbh.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
My understanding is that the Cloud offering is the slower one, assuming you can dedicate a beefy server (but probably under $200/mo on hetzner or ovh for most businesses) to running your Atlassian stuff.
Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works.
I don't buy that it's a matter of competitors not being better. It is more about inertia.
The argument you have here could equally be applied to C++ or Cobol "Why is new code being written in these languages? Why is C++ so popular even when there are many other competitors? Certainly tons of languages have tried."
I currently work in a field that is disrupting existing products that were, no joke, written in the 90s in VB6. It can be super hard to sell our product to a lot of people, not because our product isn't better, but because they've been using our VB6 competitor since the 90s.
But I've seen tons of other examples in my career of companies making larger, more difficult transitions because they clearly felt the risk/benefit was worth it: moving from CVS/Subversion to git, moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres, yada yada yada.
I'm certainly not saying it's easy, but I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira", that many companies would make the switch. This hasn't happened, and honestly if you hear people complain about Fogbugz or Asana or whatever that it's probably an equal "per-capita" bitch rate.
Was that really painful? We did that transition and it amounted to having teams one by one run the "git-svn" script on their repos to port over to git. Even with over a million commits on our central SVN server, the whole process generally took around 5 minutes per project. Even in the worst cases, it was something like 1 hour.
The most painful part we had was putting a rate limiter in place to keep our SVN server from toppling over.
> moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres
These are certainly all more difficult but also things that aren't central to the way the company operates AND can be done a piece at a time. Moving from Jira->something else can't really be done in a piecemeal fashion.
The other big problem here is Jira has a wider audience than just the dev department. Dev saying "Let's go from svn to git" is something that doesn't hardly need involvement from the C levels. They never (usually) touch or look at the VCS interface. In fact, the only thing you listed that I think would be a hard sell to C levels is switching from windows to mac. Though, I suspect a lot of them are using macs anyways. Try getting your C levels to agree to switch from mac or windows to linux and I bet that'd never fly in any organization.
> I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira"
I just disagree. The best counter example is Internet Explorer. Both Firefox and Chromium have been better than IE for a long time (10->15 years). So why didn't every corporation switch to Firefox? Why did Chrome end up winning for desktop web browser even though it came so much later (2008)?
The answer is simple, chrome advertised on media that stakeholders watched.
Chrome eventually won, but it got there through deep pockets and advertising. If there's anything that will topple atlassian, it will have to be through the same route. That product/product set has to be better AND they have to spend a lot of capital advertising so that other shareholders find out they exist. Without doing both those things, toppling atlassian will be a long nearly impossible slog.
As far as Macs go, the company I worked for was 50/50 Mac/Windows, with the majority (if not outright all) of the developers using Macs. We got bought out, and our new corporate overlords were purely Windows, and didn't know what to do about our Macs. Personally, I ended up with a fully manged Windows laptop that I never used [2] for three years before I could send it back and send me a "semi-managed" Mac laptop.
As for Jira, eh. I didn't mind it that much, except when management mandated that every team use the same queue for everything. That queue didn't match our preferred method of working, so we kept our old queue purely for internal stuff. Our time tracking system is way worse than Jira by far.
[1] Not to say I love SVN---I hate it actually, and would prefer to use git. But having used SVN for over a decade on these two repos, and given their structure, it's going to be interesting.
[2] Except to turn it on to have it autoupdate when I got "the email". What a colossal waste of resources. My team kept on using the Macs.
So once the company got large enough, management wanted to switch. Many of us essentially said, "ok, that's fine, but please please please not Jira". And yet, they went and hired some consultants who were like "oh, Jira is the industry standard for your line of work, you'd be taking on a huge risk not using it, blah blah blah". Management bought it, and they've been on Jira ever since.
At that level, there isn't much competition. It costs a lot to develop a product that does everything and throws in the kitchen sink. It doesn't make sense for a startup, Open Source project could fit the bill (bugzilla ?) but they'd still need a service providing company, probably some corporate backing for the contracts etc.
Basically, JIRA is the Microsoft (or Oracle?) of the field, and any other company wanting to fight that turf would need incredibly deep pockets with an upfront investment that would only be recouped way way down the line, if they ever make it that far, and fighting JIRA would mean lower margins than if they dominated the market alone. Overall that doesn't look like a sane bet in any shape or form.
Can't agree more. A few years ago, I joined a large healthcare organization to take a break from the startup grind. During my tenure, I witnessed the selection process of an issue tracking system and a chat platform.
They picked Teams for chat even though Slack ruled, and Teams was way behind in features. Why? Because it was the easy choice. They had the typical Microsoft stack just like every other large company, so go with Teams even though it sucked.
They picked Jira for issue tracking. Why? Because it was the easy choice. No one knew how to fully leverage it, and there was no way workflows would get buy in across the whole organization.
In large companies, especially non-tech ones, tooling decisions are driven more by laziness and CYA than what's the superior product.
Crowns don't come from inherent value. They come from monarchy.
Jira holds the crown because so many are convinced the "industry" in which it leads is worthy or valuable.
What value does a monarch provide? Order. Structure. Authority. Corporate environments value these because - art its core - that is what "Corporation" is: a new system of governance.
Most of the complaints about Jira can be turned to Corporatism itself.
eh. I've experienced a number of painful tool and platform shifts in my career that basically came down to "it's cheaper" so I don't buy that companies are unwilling. If someone provides the feature set that is some combination of cheaper and better, then the only thing you really need is a migration path (Jira import tool in this case), and you'll be able to make some sales. Make enough sales and you start looking popular and that can provide its own inertia. The fact that this has not happened is, to me, evidence that nobody has done it better so far.
This is the problem. Jira is so highly configurable that without recreating a good chuck of the Jira feature set, an "import" tool will be pretty hard to make.
Any competitor in this marketspace will have to invest a considerable amount of their time creating and maintaining such a tool, which I imagine if they ever became a serious contender, Atlassian would put up some anti-competitive road blocks. (For example, forcing everyone into their cloud offering so they can more easily control endpoint access....)
The Jira complex state table tends to be something that isn't replicated as its part of the "we're not Jira" value proposition.
Your case might be in a "Closed" state on the UX, but internally that can be "custom state 48083232" because some wingus decided to first start by naming it "to be closed" and then changed it to just "Closed". That can be different for every project.
This is why an import tool is a complex thing to figure out. You have to translate all the potential custom states into the "we're not Jira"'s states that make sense.
The only "oops" part of the Great Import was that the users that were in Redmine but not in Jira (people who left the org and thus were never imported into Jira) had entries created as the sysadmin who ran the import.
There are people who build their careers on this. Their are consultants who do this, and only this. And the unfortunate reality is, Jira is so complicated, there actually is a reason for these people to exist.
So, easy benchmark for when something has become too complicated to be worthwhile: An industry of consultants is making a living off it.
SAP consultants, Oracle consultants, JIRA consultants... You don't see very many Excel consultants, do you? (Whaddoino, maybe there are.)
Unless one is really willing to throw institutional knowledge out, changing tracking systems is extremely costly.
There's not a concept impedance mismatch going from CVS->SVN->GIT. The concepts are so similar that git-svn exists to convert a SVN repo into a git repo (and a similar conversion tool exists for CVS->SVN)
Jira is so flexible and configurable that no such tool could exist. Migrating to a new tracking system requires that you either lose all currently tracked issues and their history OR you spend the money and effort handcrafting for your org a Jira->Foo translator to preserve some semblance of history. The larger and more diverse the org, the harder such a tool will be to craft.
> How do you think every single company in the world started to develop for iOS between 2008 and 2010?
Because ignoring a company that commands 30% of the market is a bad idea? How do you explain the flop of WebOS which was, IMO, a far better UX and OS compared to either IOS or Android?
What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. Yarn got adopted within a year above npm, the "default node package manager". Everything is always up for grabs, if you can show the benefits, however small they are. And the history aspect of Jira isn't an unsolvable problem, pretty much every single issue tracker in the world offers a Jira import, and losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. If a company can show that their alternative to Jira solves a percentage of common complaints against Jira, while offering the same capabilities of scaling that Jira does, people will follow. Nobody wants to deal with crappy products. Especially since the ones suffering the most from Jira are usually the ones in charge of setting up the very processes that Jira is supposed to help with, and to procure the tooling.
God I wish that were the case. My company is still rocking Angular unfortunately :(
> Or when everyone moved to k8s within 2 years around 2017-2019
That did not happen. k8s got a good share of the market, but it's far from "everyone moved".
> What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools.
The tools you are listing are all dev tools picked, used, and curated by development. Jira isn't a dev tool, it's a product management tool. There's a major difference between tools that devs can pick and choose and tools that an organization gets to pick and choose.
Even with your "yarn" example, while it took over it didn't replace "npmjs" as the centralized repository server. Just like gradle still gets it's artifacts primarily from maven central.
I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written? Why does it remain one of the most popular programming languages even though most people are VERY quick to point out it's major flaws. Even though other better alternatives exist (Rust, Nim, D, etc).
> losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days.
Assuming you like everyone else went from svn->git I don't see how you'd have lost commit history. I personally converted a BUNCH of repos to git and didn't see any cases of lost history.
Because C++ is very very much a living and, most importantly, evolving language. It gives modern conveniences, while benefiting from existing user base and maturity. Alternatives may be better for specific emerging use cases but can’t just yet challenge the incumbent for the reasons above. One day C++ may have to yield, but at the moment it’s been actively renewed and the effort to migrate codebases to a new standard is smaller than porting onto entirely new language.
But the speed pretty much drowns out any other signal.
I'm not surprised it won tbh.
Game companies are still using Perforce though.
Maybe the ratio of text to non-text assets?
At this point git is the incumbent, which is self-sustaining: developers already know git, so you'd need a really compelling reason to use anything else and take on the burden of training your developers to use it.
It helps that git is freely available and is by far the top choice for Free and Open Source projects.
Of course, SVN used to be in the same position, but git is such a great improvement that it was able to win out. I imagine git's origins in Linux kernel development may also have been a factor in its early success.
Doubtful. Unless you are working for a shitty company in the first place, bad tools essentially just get skipped and disused by autonomous teams and none of this matters. If the company 'embeds' a product in place of a workflow, that's not something a product is ever going to fix, that's an organisational problem.
I think the core problem with Jira is organizations trying to use it to solve complex organization-wide problems. It is an enormous time sink, and using Jira to rule the workdays of employees is the problem.
Anything much more complicated than a checklist is wrong. Jira is an attractor for middle management growth that gives people who don't need to be doing anything something to do, and adding complexity gives more opportunities for more people to not do very much and generally get in the way of execution. It is also a way to give people who aren't very necessary or very good at understanding the big picture something that they can do to do.
Take away Jira and tools that you can order other people to use and you end up with middle management that literally doesn't know what to do because they couldn't organize or ease productivity to save their lives. Jira becomes the thing being managed instead of whatever is actually to be done.
If it's configured properly, JIRA can be a fairly effective tool that mostly stays out of the way of developers but can help team leads and managers communicate things about the team.
Normally those issues would be handled with a simple 5 minute meeting (DSU or some variant thereof) where everyone shares their current state, and then a few times per month some form of "where are we and where are we going" type of planning. (Be it a sprint planning or something like it) Combining that with a state tracker seems like a fairly obvious thing to do, and having the tools to then report on that over time (graphs can be a helpful visualisation that simple tools usually lack) gives everyone some context as to how healthy the team is.
But even that last bit, the concept of periodically having a bit of a check up to see how things are going is often lacking in "we can do it better and simpler" types of setups. In then end, it gets reduced back to the manager walking around with a whip shouting "work harder!" instead of teams having some autonomy and figuring their own state out themselves.
This is why tools that don't allow this kind of doing-it-wrong are significantly superior to Jira.
Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. Complaining about a tool that has no influence over your work process really doesn't change anything.
That's naive; tools influence the way they're used. When a tool defaults to having manager accounts that can change how things get done and developer accounts that can't, it nudges the organisation in that direction.
I think the problem is that Jira is optimized for productivity theater and top-down management.
When an organization deploys Jira it is usually because upper management thinks that it needs a deluge of task tracking so that everyone can stay perfectly "aligned" all the time.
This creates an annoying amount of make-work on the part of Engineers and their immediate managers, slows down velocity and the vast majority of the time spent on inputting data into Jira never results in anything actionable.
Jira is just a symptom of the disease though.
Hit the nail on the head.
I don't hate Jira.
I hate working for companies and with "micromanagers" that prioritize bs metrics over improving customer satisfaction, and busywork over impactful projects. And these kinds of people / companies always use Jira.
I would say building a good one is an impossible problem, because of conflicting needs both across and within companies. The primary job of Jira isn't to help work get done. It's to give managers and executives feelings of knowledge and control even when that makes everything worse.
You don't need fancy planning systems to get good work done. Indeed, I think it's the opposite. I've done many years of work with only index cards. E.g.: https://williampietri.com/writing/2015/the-big-board/
As Poppendieck has talked about, we live in a "Tyrrany of the Plan" age, but that's not necessary and it often makes things worse: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
I think this has happened because of the rise of managerialism, where management becomes a self-justifying caste. : https://en.wikipedia.org/wiki/Managerialism
I mean, as a single individual, in some circumstances, sure.
If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that?
Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.
>Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing
You're conflating "needing to align thousands of people" with "needing a fancy system which pulls everyone in its web to deal with multiple times a day". If anything, construction shows just how little ICs need to know to function. You don't boggle your construction workers with bureaucracy, you take it away and let architects, managers and foremen deal with it.
There are an incredible amount of project managers running from place to place on a construction project keeping teams in line. Construction work, design blueprints, government regulator, there are SO many teams and SO many project managers running between them.
JIRA is absolutely a net positive in that environment. A centralized system like JIRA alleviates that.
Again, give some actual proof. It's about time we stop clashing rationalities and face the music. If it's this easy to come to a "rational conclusion", it shouldn't be much harder to pull evidence.
In the lean analysis, the problem isn't changing requirements, which is a natural consequence of changing circumstances and people learning over time. The problem is building up a large inventory of poorly-tested, underinformed plans and then doing a lot of work based on them without taking advantage of the opportunities to learn.
Especially here on HN, we know that startups don't succeed because they come up with a fixed initial plan and then spend years marching to it. Instead we have all set of techniques for releasing early and often so we can see what really works for users. A key competitive advantage for startups is how their fast OODA loops allow them to run rings around larger companies that slowly drift into being very plan-based.
However, you should watch the Poppendieck talk I linked. The Empire State Building had construction start before they finished designing it. The waterfall hallucination, where people imagine perfect results come from perfect plans perfectly executed, has been hugely enabled by software. But if we look at the actual results of heavily planned activities, like buildings, roads, and weapons development, the track record is terrible.
So if modern planning techniques don't work well even in areas, like construction, that they are most suited for, then it should be no surprise that people are skeptical when they are applied to domains that are very different, like software.
Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it.
It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.
There are plenty of minimal planning tools out there. Github issues, for example. Or I use KanbanFlow quite a bit. But having driven adoption of simple tools, I think you at least need an environment of benign neglect, as with a skunkworks project, or a tech project at a non-tech company. From what I've seen, in a lot of companies systems like Jira are too entrenched and too visible to management to allow for guerilla-style adoption of something that's more developer/worker friendly.
This is a lot of hearsay which tends to devolve into a debate of "we absolute need this!" vs "no you don't, see X".
>Obviously some of the complaints (speed, stability) are very valid
I don't think people defending it fully grasp just how important speed and stability are, or at least live in a corporation where Jira was optimized better than the average corporation does. Given not everything is the fault of Jira, but when Jira is expected to be the place you go to all the time and it is that slow, it becomes very impactful to morale.
>"Jira is the worst project management tool, except for all the others".
This doesn't work until big corps actually try something different, but pretty much all of them push back on the mere idea of trying alternatives. If you can't invest a few months trying a different system, you can't judge it. And since those few months are seen as a "great risk", no manager is going to push the issue any further, even if Jira's costs per developer could easily run into the hundreds (or thousands, for 6-figures) a year on morale loss and time loss alone.
And this is the crux of the matter. Management likes concrete numbers. Management likes mimicking what other successful companies do. Management does not like fairly abstract things with great risks. Management does not like big risks with abstract rewards.
It worked flawlessly — in fact I haven't been at a place that was as well organized since. And it all came down to one thing: everybody understood that there is only email and that if it isn't an email it will be forgotten and fall in some crack, so you better make it an email, that has a propper subject, is searchable, etc. That meant everybody was writing emails with nearly military rigour, while the asynchronous nature of the electronic letter always reminded you, that you just needed your emails done and then you were fine. Depending on your position you had multiple (shared) inboxes that corresponded to the tasks. Of course there were some old emails, that were more of a "if anybody finds the time and will" type and sometimes emails from the guy from the day before had to be done etc. But all in all it was surprisingly pleasant to work just with email.
The point of the story is: You can turn any tool to shit if people use it in a bad way. And you can make anything work if people use it in the right way. Most problems with communications are people-problems, not tool-problems. Sure certain tools may lend themselves to certain behavior more than to others but ultimately a team can decide how they wanna communicate effectively and which behavior produces chaos and problems.
Generally speaking any organisation, given enough time, can establish processes that are better than JIRA with a certain amount of luck.
However, that's the best case scenario.
It's a standard distribution. Sometimes a 100 person project gets by fine with email. Sometimes it all goes to shit.
A tool like JIRA is, on average, a lot better than doing it via email only.
Granted, such a thing would not scale up to infinity, but for that size it was perfect and extremely hackable (just email + SMTP after all).
Jira is the way it is because Jira ISN'T built for developers.
Devs may have to use Jira, but they're not the ones who have to pay for it.
I wrote about this a while back:
"Who is Jira’s target customer? It’s certainly not the poor developer who struggles to add a link to his bug report. (I’m still mad at them)
Take a look at Jira’s site and see what they emphasize:
Those pages glamorize having an overview of what work your employees are doing. It’s a tool made for managers. Especially higher level ones. The VP won’t be filing work items, but they’ll be very interested in the insights those dashboards offer.
Jira spends all their software cycles building new features for that VP, ignoring what you and I might consider critical user bugs."
Source: https://www.zainrizvi.io/blog/never-focus-on-the-user#jira-s...
JIRA is so slow and the UI so clunky the project managers where I work use some type of spreadsheet upload mechanism with XML spreadsheets to automate the cruft creation. It's fun to watch.
Unfortunately, from the project manager's perspective the emphasis is on the words making sure
And Jira lets them think they're doing that
Software developers' mistake is not realizing that "linking the tickets" into Epics that managers can search is hugely important.
If the project director has no clue about what tickets people are working on things go south fast.
All developers should agree on that.
The only reason stuff gets done as it should it because me and my peers are responsible, and because we have a good understanding of what needs to be done, not because of how things are mapped in JIRA.
This is key. The problem with Jira is less about Jira as a tool and more about how we approach project management.
I've seen some teams thrive with Jira. I wouldn't say they "loved" Jira but they had a light weight project management structure that let them get work done and enough control over Jira to set it up to stay out of their way. They didn't give Jira credit for their ease of working because it was their processes that were good. Jira just gave them a way to not have to write everything down on paper.
I've seen other organizations create a horrible project management structure and then use Jira to "enforce" those structures in ways that magnify all the worst aspects of what they are doing. In those situations it is usually more politically palatable to blame Jira rather than the management processes. Those type of organizations usually blame the tool while hoping that a different tool will force the organizational changes that are needed to make life better.
Afterwards, all the 'team JIRAs' got merged into a normal JIRA again, but this time everyone had full control over their own projects and boards, problem, solved.
Before I got to use Jira for the first time around 2006, everything I used before was crap, either in-house solutions out of CGI scripts or crap like ClearQuest.
Stuff like Trello just seems too basic for typical enterprise workflows that overlap sprint planning, with project roadmap, milestones and change requests, mapping of tickets to source code, pull requests, documentation,...
If I have decision power, I will always pick the Atlassian product suit versus the competition.
Any single click you do on it reminds you of the time when people were waiting literally minutes to be able to do anything when booting windows on a laptop with 5400rpm hard disk.
Whatever help it is for your company, it makes you pay for it with billions of swears.
That's funny, because I've always thought of Jira's most ardent defenders as a cargo cult. As this comment section indicates, Jira can do no wrong. It can only be done wrong. Cult.
Not in my experience. I'd much rather use GitHub issues or a range of similar products. Finding and searching works well. Performance is good. Organization is feasible. Labels work fine for customization.
> Jira is like democracy, it isn't perfect and is full of flaws, ...
Using a pithy cross-disciplinary metaphor to try to bolster support for an argument doesn't do much for me.
I would appreciate, on the other hand, if you elaborated on the details of other alternatives you've tried and what problems you've seen.
Developing software for 30+ years.
Before Jira came to be, in-house stuff based in Perl CGIs, Lotus, DOORS. ClearQuest, Bugzilla, among others.
After Jira came to be, Trello, GitHub, Azure DevOps, TFS.
None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
Cool. Similar over here, though admittedly not with source control or bug trackers for that long. :)
> None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.
I think I see where you are coming from. But Jira's cost (efficiency, complexity, confusion about how to use them, etc) for all these integrations is tremendous. It is easily to make a tremendously better user experience over Jira, even with a pile of integrations.
And yes, I understand that building software for enterprises can be demoralizingly painful and frustrating. To paraphrase another quote, I like everything about enterprise software except the enterprise part. I find the general claimed philosophy of "we are risk averse" often is insincere, a rationalization for inefficiency, and a confusion about what risk means over different time scales. Sure, constant churn is risky. But falling into a pattern of not trying new things inevitably leads to stagnation. Better to have some failures than never to try.
Indeed. Often less is more. Your comment may inadvertently be making my point for me. :)
For example, a hyperlink (implied is fine, added in a view is fine) between a commit message and a ticket in my view, is possibly the perfect level of integration.
Integration does not have to (nor should it) mean poor performance or usability.
Good for casual users, while at the enterprise level everyone wants a different set of 90% Jira features.
It is no accident that Microsoft is turning GitHub into an ecosystem that combines Azure DevOps with GitHub.
This is essentially it.
The developer facing UI of Jira's competitors is MILES ahead of Jira.
Jira's "director level" UI is miles ahead of its competitors.
Because the people who get to decide whether or not to use JIRA aren't the people who it causes the most suffering for.
But the flaw is in assuming it's a problem that should be solved in a one size fits all way. In my experience the pain points come from top down process that's at odds with the reality of the work.
I feel totally the opposite. If you've ever had to administer Jira at a large company than team-managed projects are the bane of your existence. If you think, there's even a small chance that your company will grow to 300+ engineers any time in the next several years then do yourself a favor and turn off team managed projects entirely or else you'll face a painful migration away from them.
Though I will generally defend Jira as a product for many of the reasons you said.
For all the people bitching about how Jira makes it hard to work like they want to work, their are folks like you who will complain that Jira makes it to easy to get around a company-wide standard.
To emphasize, I'm not saying either side is right or wrong, I'm just saying it's impossible to build a project management tool where large subsets of people won't complain about the exact same set of features that another subset of stakeholders likes.
I am interested on why people think that.
It doesn't look like a necessity to me. Ok, in a medium company, with dozens or maybe a hundred or two people, centralizing all the workflow is probably cheaper and more productive than siloing teams. But in a large company the inverse can very easily be true.
We can’t easily replicate that workflow anywhere else. This isn’t the end of the world, but I should be able to create a new team-managed project based on another team-managed project and then modify its workflow separately. So far, I can’t figure out how to do that.
I’d love to take the team-managed workflow and promote it to a company-managed workflow now that we’ve experimented with it. So far, I can’t figure out how to do that.
Don’t get me wrong, I really hate JIRA. I’ve written my own bug tracking system. I’ve tried lots of other tracking systems. JIRA is wrong on so many levels, but eventually you hit something in one of the other tools that you cannot address with those tools, but is possible (but painful to configure, and it might cost you extra money) in JIRA.
The only other tracking system I really like is GitHub issues, but it also has problems and limitations. And then you have things on GitHub that actively make things much worse (the autoclose bots; forms like the ones that Vue puts up, etc.).
I’ve never seen any organization need the level of complexity that they end up using in JIRA (especially the access permissions, which consistently get borked sideways), but most organizations eventually need something better than Bugzilla, Trac, or Github Issues.
The other difficulty is that switching bug tracking systems is tough. I want to really try Tara, or ClickUp, or Monday or a few different ones, but adding another tool is literally adding another tool. This is the same reason we’re using Confluence, even though it’s objectively the worst wiki in existence.
I hate Atlassian products with a passion. There’s nothing better, and the cost of switching is too high.
No, I have a really good understanding of that. My problem is that Jira, in actual implementation, tends to be how some parts of the organization (often Product) tries to exert fine grained control over other parts of the organization (design, qa, development, operations, etc.) by micromanaging the process.
Also, sometimes your organization is just not that complicated. I've been in startups using Jira with dozens of states, with complicated transitions and approval steps, that would have been over kill in medical companies I've worked at.
This is pretty much the core of it. I use Jira daily, but my exposure to it is the tip of the iceberg in terms of what it can do.
I think what most people forget is that this Jira is basically an ERM but for development-focused organizations. (Where the resources are time and people instead of processes and inventory.) If you've ever seen the complexity (or price tag!) of a real ERM, Jira actually looks very reasonable.
That said, smaller companies and teams should definitely use simpler tools that are more appropriate for their scale. Hire a Jira consultant and make the switch only when you're big enough to justify it.
I came here to say precisely this. In addition to Jira, I've used Clubhouse, Trello, monday.com, and GitHub Issues. Jira sucks slightly less than the alternatives I've used.
I really wish Jetbrains Spaces was around when the organization I work for was doing the "everyone under one umbrella" migration.
Prior to Jira, we had one team using GitLab issues, one team using Redmine, one team using Borland Star (with a tight limit on licenses), and one team using Excel.
I personally would have gone with Redmine over Jira... however that also would have tied me to doing a lot more setup work, upgrades, and care and feeding of the system compared to the relatively turn key setup of Jira.
I believe the best workers (at both the management and IC level) are not going to want to waste a significant chunk of their professional lives in Jira world and the worst workers just want to keep their paycheck coming every month so they will just submit to it and keep cashing their checks. The organization will thus rot and converge on the lowest common denominator employee, which is indeed what the tool kind of promised: fungible, low skill workers with predictable (low) output.
Jira, the software, is far from perfect, but when one talks about hating Jira, they are really talking about the people who use Jira. The same people moving over to a competing product that offers the same feature set perfectly implemented would still leave people hating it. The software itself doesn't matter that much here. It's a people problem.
So, why do people cling to a project management style that everyone hates? There is a lot of friction. Nobody wants to be the guy who pushed for an alternative that turns out to be just as bad. "Nobody ever got fired for buying IBM", as they say. You know that IBM will deliver a failure, so everyone is ready when it does fail. If you hired Mom and Pop, you are doing so expecting them to be better than IBM, so when they fail equally there is a buildup of blame to go around. That's not a comfortable position to be in.
I would suggest that winds of change are in the air, but it is indeed a slow process to find a critical mass willing to take new risks.
Trello was a much better solution to the problem, that's why Atlassian made sure to buy it and is now hard at work ruining it.
Why haven't cowboys found a different way besides horses to get around? They're not interested in what those under their asses think or feel.
Jira sucks big time, and there are better tools now. The reason no one "toppled the Jira crown" is just inertia, specially management inertia who are the ones deciding what tool to use. For the same reason we're still mostly using petrol for cars, not because there aren't better options, it is because it is not easy to change.
Yeah that problem is that in many places management sucks and can't trust their developers to get shit done, so you have to put metrics on it to bring down anxiety brought about by incompetence.
There are large open source projects that don't use jira; the extreme complexity of managing a distributed team with all sorts of interests -geneally even more complex than what a company has to deal with- is empirically doable without jira.
When an organization pivots to using jira it is a sign that their managers are no longer capable of respecting the programmers that work for them. If an organization starts out using jira, that means they never were.
To be charitable I'm sure there are a few corner cases where a manager came up through the ranks and "only knew jira" but that really means they don't understand open source IC, especially in the era of GitHub and gitlab issues.
(Btw GitHub issues is absolutely the thing that is slowly replacing jira)
Your insight is the same reason why people hate boarding selection for planes, or McDonalds breakfast ending at 10:30am or fill in the blank.
The problem being: "how to create BS data and metrics to satisfy a bureucracy"?
I suppose its a necessary evil for an organization of a certain scale, but for whatever reason, I've chosen to work in teams that are small enough that we can dispense with JIRA all together.
Jira is often the domain of PMs, management, and other leadership; if you have bad people / product leaders, you're used to Jira being a source of great stress.
It's not because I hate Agile, Scrum, or even Waterfall (although I do hate SAFe). I just know these tools all suffer from similar drawbacks, and somebody will ultimately codify all our organizational problems into the tool. Then, rather than spend an hour a week of their own time, they'll create a new mandatory field and ask thousands of people to spend an hour a week each populating that field.
I claim something more specific. A totally powerless workman who's afraid of his bosses blames his tools.
An individual in the face of indomitable authority blames anything else.
Jira is a wonderful proxy for all the bureaucracy and *managers you hate. So hate Jira, because you're powerless to change anything that matters.
For customers, their own specific use cases are the only ones they should care about.
I don't know why there isn't a good solution to the problems Jira attempts to tackle, but that's no reason to get philosophical. It's OK to hate every existing option.
But the simplest things are baffling in Jira. Any issue-tracking system that requires the users to learn some obscure syntax (or even to use SQL to refer to its internal data structures is a failure.
Because of this, it is basically jello. It is everything, and it is nothing.
It makes nothing simple, and encourages people to overachieve with the tool. If you overachieve with the tool, you will underachieve on what it is you're really trying to do.
This is why much simpler tools are better. They are usually free, or at least a lot less expensive, and they come with constraints that you have to live within. Usually those constraints prevent you from going tool crazy, and guide you to actually focus on getting work done instead of doing performance art with Jira.
If you can get away with less structure than JIRA affords then congratulations for not having a budget or timeline but the rest of us need some deniability. Every other problem in the world of software projects is human and can't be solved with tickets.
There’s an argument that you should use an issue tracking system for tracking issues and not planning. Features and stories don’t necessarily neatly subdivide into tasks and issues. Issues don’t always neatly fit into a story or feature.
However, up to this point in our company, it's been great. It's very deliverable-centered. Stories are the deliverables and are the centerpiece of the flow. Tasks just make up a to-do checklist for a story - there's no endless wrangling about that is a task, there's no credit for doing a task (shitty devs can't game the system). Shortcut feels like it hits a nice spot between the monster that is Jira and too-basic tools like Trello. Shortcut is made for developers.
JQL and bulk edit are just warming up at 1,000 tickets.
But...
If the UX wasn't garbage I'd defend it, too. It has a lot of nice features and integrations. But the UX changes they have made in the recent past (few years-ish), made it worse, for me.
And, in my opinion, the reason some other company hasn't come along and toppled it: critical mass. It's the same reason Epic is king in the hospital IT world. The UI/UX can be garbage (and it's so much worse with Epic than with JIRA), but organizations will still stick with it, because it's what they know.
Do open source projects of any size use Jira? If not, do they use a basic knock off? The few not-so-big ones I've contributed to seem to get by without it, but maybe I just don't have enough exposure with these. If the open source world can be semi-productive without Jira, I think that's telling. The interested student can decide the details of what it's telling.
https://www.broadcom.com/products/software/value-stream-mana...
What is that problem exactly?
Jira's "director level" UI is miles ahead of its competitors.
Jira cloud in our organisation is also reasonably fast, the front end can be a bit janky sometimes, but overall considering the complexity of the application, it's not too bad.
JIRA is a lot like agile though where everyone is using a different version ranging from this works fine, to this is a dumpster fire.
Just like you won't get fired for using React in your project, you won't get fired for using Jira. It will support whatever your workflow is (and I don't mean only software development, but things like hiring or office management). If the built-in features are not enough, you will find a plugin that meets your needs.
I think long-term it's important to use a tool that give you this flexibility.
But yea, I agree, they are trying to solve a huge problem. And good on them for it. I still dislike the results though, and that's ok. We still use it.
I'm at an early startup and we use Jira; it's great because I'm an admin and I can make Jira reflect whatever I need it to reflect.
It's also highly compatible with compliance nonsense -- if you can say, "Every change to code is tracked in Jira" (the decision process not the literal diff) the auditor's eyes glaze over and they just move on.
Also Linux doesn't use pull requests. GIT doesn't even know the concept of a PR. You are supposed to generate a patch with 'git format-patch' and submit it to a mailinglist.
Bugzilla is for bugs and that's the point, right? A project is not a set of bugs...
My takeaway is that the planning and the issue/bug-tracking and the patch submissions are three seperate somewhat independent processes. There are no managers trying to group all the tickets into patches and patches into projects in some sort of neat (but illusionary) hierarchy.
I'm going to stick up for Jira. I certainly don't "love" Jira, though I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now).
The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for the extreme difficulty of the organization-wide problem Jira is trying to solve. It's always taken on from the position of "well, it didn't make my specific use case easy", but never with an appreciation with some of the complexity that Jira needs to solve for other users at your company, never mind other companies.
Obviously some of the complaints (speed, stability) are very valid, but here's a question I think is just as valid: why don't you think some other company has come along and toppled the Jira crown? Certainly tons of them have tried, and while many have their supporters, they are almost equally likely to have their detractors.
The fact is, building a generic project management and tracking tool is a really difficult, hard problem. In my old age as a programmer I feel like Jira is kind of like our form of government: "Jira is the worst project management tool, except for all the others".