It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process.
tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it gets taken for the central thing. This is an illusion. Fixing a bug without filing a JIRA ticket is in itself progress. Moving a JIRA card without any other change is not. Yet the second is what's visible and therefor what's rewarded.
Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host.
In case the cancer metaphor didn't make it very clear, I don't like JIRA much. Yet if JIRA were to die today, the middle management who live by JIRA would replace it with something else equally bad, if not worse.
Filling in missing features won't and can't fix that.
And I've also never worked anywhere that had a better option than JIRA.
Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with technical details, I probably spam the whole team with lots of "Ticket was edited" notifications because there is no logic to Atlassian's markup systems.
I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true.
</rant>
And as someone who enjoys documenting their own work for fellow developers and other roles, I don't even think Jira helps. Most discussions will still happen offline and without documentation, especially from non-technical roles who hate typing.
If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, everybody here knows that's not true.
I think the true way to optimal resource usage is not through ever-increasing process and managerial layering. Instead, it's through tight feedback loops where small cross-functional teams iterate closely with the people they're serving. Which is exactly how most good startups work. If you were really right about pursuing a financial optimum, the first thing (very resource-constrained) startups would do is get a copy of JIRA and hire some middle managers to carefully parcel out the work against precisely designed specs and timelines. That they don't should tell you something.
[1] https://en.wikipedia.org/wiki/Managerialism, and also see https://www.amazon.com/dp/B00A76WZ96/
A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort.
More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables.
Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.
I know most of the people in these positions aren't _actually_ stupid, and would agree if you were able to explain to them why some specific thing is completely irrelevant, or even detrimental, to your team. At the end of the day, though, at big orgs no one cares. They'll waste as much time and effort as necessary in order to look good on metrics. Even if the metrics are worthless.
Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eyeball the ticket.
The other approach is to have developers build up a real sense of why they are building what they’re building, who they are building it for, and give them the agency to change the how and what to better meet that why. This requires trust, so it is more easily done in organizations that are on a first name basis. It may involve jira, but really almost any work tracking solution will work.
Anything is better than Jira including post it notes on a wall.
It's for developers too.
As a developer I want to know what the history of work on a certain issue was, who requested it and who worked on it in the past (not just at the code level, the information for which should be in version control logs, but also at non-code levels like approval, review, etc), what the communication was with other stakeholders, etc.
Much of this information is useful to me to figure out who to talk to if I have some questions which the documentation or sourcecode does not answer, and also how to communicate how/what was done on this issue.
This is the strength of a ticket tracking system, and that strength helps everyone.
How does JIRA help with that?
I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA.
My $100 bet: They don't.
While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.
Agree with most of what you say aside from this bit. I find most similar systems are in the same ballpark in terms of being able to track what I care about.
Mainly:
- Is the ticket ready for me to work on? (Do I have the designs I need to work it?)
- Who is working on a given ticket right now?
- Am I done with a ticket?
- Is the ticket ready for QA?
- Did QA reject the ticket and I need to fix something on the ticket?
Pivotal does these things fairly well. There is also the obligatory pointing system, but the above is the bulk of what I care about. Pivotal also lets me create queries so I can zero in on the work which I'm doing as opposed to the entire project.
Hard disagree. Unless you're writing software for clients a crapton of ceremony goes into JIRA tickets when 99.9% of them will never be looked at again once marked closed.
>>> If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money.
JIRA is used when companies have no trust in their devs. We all use Git. There's a perfect, permanent record of anything I ever touch. Yet management is always worried we're going to "get distracted". As if that wouldn't be incredibly obvious.
It's like hiring a plumber to fix something then following them around the house to make sure they don't straighten your artwork or do the dishes while they're at at.
There's a pervasive theme that "PM knows best" among companies obsessed with JIRA. The best companies I worked at had no project managers at all and things ran great.
He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done.
It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard.
After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes.
It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams.
This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on.
This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.
So much for Agile!
This is patently false, as evidenced by every business in existence that doesn't use issue trackers, including most non-tech divisions of current businesses and most tech businesses until the rise of agile. And I question the value add of these things; my current company was built without them, and it's only as we've matured (well after the product was built and mostly refined) that issue tracking was used.
As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based around short-term thinking.
First, it provides multiple negotiations for every work stream: "What tickets are part of this project?" and inevitably "what tickets do we need to cut to get this project out the door faster?" The developer quality of life tickets are the easiest for non-engineers to jettison. What's worse, sometimes they're right to want to get rid of those tickets. Quite honestly, developers often don't do the math on "Will we ever get the time back we spend fixing this?"
Second, JIRA-based systems are designed to try to make everything take the minimum possible time. This is a good thing, but developers can bear the burden of it. Quick iteration is good, but it turns into a situation where the most you can undershoot a task is by hours or a few days, but if something is much harder than you expect, it could overrun by weeks. I think this is a necessarily reality of business, and that "evidence-based scheduling" a-la Joel Spolsky is an innovation that could have eased this pain by introducing "how bad are long-tail effects?" into project planning. But as-is, you're in a situation where you're either meeting expectations (since the ticket took more-or-less what people thought), or you're visibly holding a project back (because it was tightly scheduled to within an inch of its life). So the development experience becomes this weird commodity that sometimes has really visible failure modes.
And finally, since JIRA projects/epics/whatever are often prioritized by expected value, it's difficult to raise large engineering concerns. Again, this is a good thing, because time spent engineering is time not spent helping the customer. But because the focus of JIRA is so granular, it's difficult to break out of that. Imagine a company in the 80s that wrote desktop software in assembly, and some engineer is like, "This is crazy, we should invest the time to write modules in C". How do you climb out of that? In the language of agile development, you actually need a lot of foresight to break out of this local maxima, because your prototype will be demonstrably worse - "so we need to set up this compiler toolchain everywhere, and interface with our existing assembly code, which the compiler toolchain doesn't make easy, and it introduces ABI concerns, and your prototype looks worse than just going with this. I think we can safely call this a failed experiment." When the only project language you have is trees, it's difficult to talk about forest. I think this is why healthy engineering organizations that I've worked for tend to spend about 30% of their time working on more ambitious stuff. But it's something that needs to come from the top-down, because the tools won't provide it.
So to developers, the structure imposes a system where successes are minor, failures are visible, it's hard to get negotiation leverage, you lose the forest for the trees, and they need to fight tooth-and-nail for quality of life improvements (or they get a week thrown down from above, as a treat, to address any technical debt).
Yeah. The problem is they now have to report at least 50% less progress because half of s dev’s mental power is dedicated to ignoring or updating Jira.
Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.
You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward.
Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING.
These core mechanics work.
Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown structure fit into a project management iron triangle, per your middle management point.
Of course, middle management is just trying to lie to senior management that writing software isn’t invention because invention isn’t predictable — but senior management wants perfect predictability so they know they’re hitting their bonus, by pleasing C-level execs, whose packages depend on pleasing shareholders. Everyone’s building a Jenga tower of predictably hitting the numbers.
So if you don’t like JIRA, blame shareholders. :-)
Jira / Kanban works for some projects while Waterfall works for others. Some projects need high levels of governance while others move faster with low levels of governance. Some projects can get away without time-commitments, but others have dependencies and must hit deadlines, and this must be tracked.
And just because GTD is great for managing my personal workload, doesn't mean that it's great at coordinating the work of 100 people.
(I say this as a person that generally believes in Agile, is a huge proponent of GTD, and have also been on a dev team where Agile and Kanban was applied where traditional Prince2 would have been a better fit).
> Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an addiction. “On more than a few days, I wondered what, precisely, I was trying to accomplish,” he wrote. [...] It seemed to him that it was possible to implement many G.T.D.-inflected life hacks without feeling “more competent, stable, and alive.”
[1] https://www.newyorker.com/tech/annals-of-technology/the-rise... (or https://beta.trimread.com/articles/59839)
Stuff you might or might not complete is basically, everything. That's not a meaningful category list.
> These core mechanics work.
They work like a water-filled car coasting downhill. It looks like it's water-powered (or JIRA-powered) but it's just the gravity well of "looking busy" for the most part.
Maybe the in-car water fountain could be considered water-powered in practice, but that's a derail. Management gets approximations from JIRA because that's what they want, but JIRA doesn't provide it. A tool with a dependency graph could do much better.
When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it.
Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason)
When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.
With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket.
I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself!
8 person teams are usually the recommended max team size anyway under Agile (two pizza team).
One of the core Agile principles is "individuals and interactions over processes and tools". JIRA is more-or-less value neutral, but the management caste, possibly fearful of the sort of healthy conflict that comes with negotiating the priority of features and fixes, tends to resort to inputing all their information into JIRA believing that it's a substitute for actual communication.
Every Agile resource I've read has emphasized the point that nothing is equal to actual conversation between stakeholders. Whether it's JIRA or one of its competitors, when you have a tool that discourages conversations or pretends to act as a proxy for collaboration between stakeholders, you're going to court failure. Easy to blame JIRA, but it's this whole tool-based mindset.
Adding more features and more process in general is going to be a net negative for developer productivity. But how well Jira (or similar tools) works for you is completely up to how you use it. Most teams I've seen that hate Jira et al usually have an overly complicated process, with far too many "states" for a ticket, a million mandatory fields, multiple assignees, etc. This naturally results in people spending far more time in the tool, which is time they could be spending actually doing productive work. Conversely, teams that like Jira tend to have very few ticket statuses/fields. Standups are quick, sprint planning is quick, everyone wins. Unless your job was moving things around in Jira for 20+ hours / week... in which case you'll need to find something else to do.
Our folk wisdom metaphors for QA/Test and change management are wrong. Sure, given enough thrust, even pigs can fly. But polish a turd and it's still a turd. [1]
JIRAs turrible implementation isn't even as bad as the CRM, ERP, enterprise products of yore. Turrible, sure. But I've seen worse. Much worse.
[1] I was a QA Manager for a while. Someday I may publish (explain) the play books my teams used for shrink wrapped releases. (Spoiler: I replaced a lot of heavy weight CRUD based mgmt with lightest weight artifacts. Like just printing all the bugs, taped to the wall, and using approval voting to prioritorize.) Until then, Bryzek's new "testing in production" strategy is the only QA/Test workflow that seems directionally correct in our new agile SaaS world.
https://www.infoq.com/podcasts/Michael-Bryzek-testing-in-pro...
Jira is middle-management-ware, a term I made up (I think) for software that serves the needs of middle management, or, at least, the needs middle management thinks it has, which comes to the same thing as long as you're selling to them.
What are those needs? Metrics. Being able to see who's doing what, and how quickly, and what still needs to get done. Being able to make charts and graphs and summarized reports for the next-higher level of management, so they can say that their team is productive and their team isn't falling behind.
It also serves the needs of the companies, like Adaptavist, which have attached themselves to Jira to sell add-ons and generally bring the state of the software up to where middle managers (in my experience) think it ought to be out of the box.
I could imply that this is deliberate, that Atlassian is Not Adding some features to scratch the backs of those other companies, but That Would Be Wrong, I'm sure.
As a developer, I've felt the Fogbugz way of doing this most closely mapped to my natural workflow. It is also built around the concept of a single person "owning" a ticket, providing a natural flow from person to person through the lifecycle of a ticket. This can be done in Jira, of course, but it is a mental drain as it requires more bookkeeping.
edit: I guess what I'm saying is that Fogbugz in particular is a bit more opinionated and lines up with what I think is good. Jira naturally guides management to all sorts of extra crap.
I think it mainly caters to micromanagers and allows them to justify additional head count "look at how large our back log is". It doesn't matter that 99% of the backlog isn't very relevant work and hasn't been touched in 2 years for a reason.
Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?
This is the major problem I see. Just like misleading code comments pollute a code base, bad tickets and fantasy tasks pollute any useful information you might get from a ticket older than a couple weeks.
If we're really being agile "moving something to the backlog" would just delete the ticket. If its important enough, you'll write it up again.
For compliance it must be possible to find who made a change, why they made that change, and how they validated and tested that change. In a heavily regulated industry like medical, it is very useful to have a tool like Jira when the audit comes up.
I still accept your point tough, if you need to go fast and break things (you know, innovate and prototype things), jira is a real blocker and the "jira mentality" slows things down, for better or worse.
That's a very different kind of problem. Unless you spend your career work on projects where you're the sole engineer and the PM/PO doesn't know what they're doing, I think that you're probably going to have a difficult time if you can't reconcile yourself to the utility of this sort of process.
I've seen many examples of both extremes:
Sometimes I see people working totally unsupervised, essentially just playing and tinkering with whatever random technology seems interesting to them that day. This can be a huge waste of the company's money. Surprisingly often these people are counter-intuitively very productive despite the apparent time wasting. If you take away the 20% management overheads, someone being unproductive 20% or even 40% of the time is either the same or only slightly less productive overall!
On the other hand, the bureaucratic hells of 80%-90% overheads are all too common. These are the organisations where managers would say with a straight face that the floggings will continue until morale improves. These places can be so soul crushing that all of the talented staff leave for better jobs, which is not only a brain drain but also leaves the worst employees behind. Eventually management redoubles their oversight to try and squeeze some productivity out of the remaining dregs, but this just results in even the mediocre staff jumping ship, leaving only the most unskilled, unmotivated, and unproductive staff remaining. Jira often becomes one of the whips used in places like this to flog the remaining unfortunates.
TL;DR: Some management is required but the extremes are bad, and the extreme of too much management is much worse.
I think it's a case of there being multiple truths, and depending where you sit on the food chain you'll sing one and not the others:
1. If you're a highly competent dev it gets in the way and wastes valuable time
2. If you're a project manager with thousands of moving parts and a diverse array of talent from almost useless to God-tier it can help keep things on track
3. If you're a rookie you can at least quantify and digest which tasks require your attention and not feel overwhelmed
4. By virtue of some common personality flaws you over-estimate how good you are, underestimate what you need to do, and work on the wrong task and still say it's a pile of shit despite it being exactly what you need
It's maybe not so good at the front end of the process.
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_s...
Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone, but from my point of view I have a simple process for evaluating tools:
1) Can I use it at all? 2) How many of the features I want does it have?
I'm pretty sure Jira would score great on the second question, but since it hard fails the first, I'll never know. And it's been slow for so many years now, I assume they have no interest or ability to fix it. And their slow drift towards cloud installs over letting people self host isn't helping them either since, embarrassingly, their cloud instances seem to be even slower.
(Incidentally, there's a lot of competition in that space, but I've been pretty happy with Clubhouse. I wouldn't mind a few more features, but it's good enough. More importantly, the UI is clean and snappy, and that hides a multitude of sins.)
> Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products
https://www.atlassian.com/legal/cloud-terms-of-service
JIRA sucks
My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think.
You don't like that the ticket form has 50 fields you don't need? No problem! All you need to do is to convince your manager to contact support and tell them to track less data about your progress. I bet your manager will love that.
And once they got the foot on the door, who is going to convince the company to migrate away from them?
That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.
Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself.
Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".
When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning off the permission checks, you replace all of this communication with the equivalent of 'return true'.
Unless you're running a multi-department enterprise-wide Jira ($deity have mercy on your soul), you're better off eliminating permissions entirely and controlling access to the instance at the network. In other words, if only your developers need access to it, do not add your developer user group to the various site permissions, set the permission to everyone instead, and ensure only your developer's subnets can touch it in the first place.
Access control lists can be easily cached, and then most access checks can be performed entirely in-memory.
Instead of evaluating the full ACL every time, an additional trick is to take the cryptographic hash of the ACL and use that as a cache key. This both deduplicates the ACLs (which tend to be repetitive), and also allows (ACL,UserId) tuples to be efficiently cached.
This way, a page with even a hundred controls becomes effectively a hundred hashtable lookups the second time it is viewed, and even the first time it is opened the overhead is no more than a millisecond.
If turning off security makes a noticeable difference like you said, Atlassian has done none of these basic things. It indicates to me an incredible level of negligence.
What’s the opposite of “delightful”?
deleterious fits in an alliterative way
Unpleasant?
See also my comment from 2018: https://news.ycombinator.com/item?id=18511497
Cloud Jira is unusably slow in comparison, too, and when the Atlassian server licenses are not available any more (soon!) and we're forced with having to migrate, I'm not sure what to do. Bite the bullet and just accept the abysmal performance for an easy migration, pay through the nose for the Data Center license, or get people running on a new tool?
I joined another team which used Asana, and it's much better, although certain things can still be slow.
This is spot on.
Its the same reason I hate Sharepoint - every implementation I've used was always incredibly slow, so I would only ever use it when my arm was forced.
I miss old school "legacy" style apps that cached stuff so moving around the app is quick.
Even simple apps like slack suck these days as it always takes a few seconds to move around windows, why the hell can't it cache things? IRC clients in the 90s did about the same amount of stuff and they never lagged swapping servers or channels.
My remaining issues with jira are not with jira at all. Jira can fix its slow ass software, it's feature backlog and I can use mkdocs over confluence. Jira can't fix poor project requirements and management.
How fucking dumb are you if you can't even write a bug report? It's what happened, what I expected, and a how to reproduce bullet list.
Some plugins like big picture even have their own databases that need to be updated separately from the plugin, and can cause performance issues.
Start jira in safe mode and check the performance. Then check your plugins one at a time until you find the culprit.
They also have some nice built in tools that often help you find the source of these problems.
It's a product, but it's also a platform, and sometimes the stuff that is built on the platform causes the platform to buckle.
You don’t know how good you have it with JIRA.
Atlassian has been losing money in every quarter for quite a few quarters. But its market capitalization has been generally increasing so shareholders who sold their stock probably made money.
The only bullet point I do agree with, is that Jira is missing an easy (or IMHO a minimalist / simple) interface. The tool is a mess, and the people using it are probably also using it in the wrong way, making the whole situation way worse.
Don't get me wrong, I like Jira to some extent, but its performance and messy UI are really making my life harder rather than simpler.
I recently succeeded in an 18-month-long effort to coordinate moving off of JIRA at work. We moved to clubhouse.io and it's been great. We were also looking closely at GitHub Issues + something like ZenHub for the missing project-management features — and that would have been great, too.
As soon as we moved off of JIRA, the amount of communication that started happening in the most relevant place — the bug tracker thread — increased by like... I don't know, something like 20x or 50x.
In our years on JIRA (the hosted plan) virtually nobody every discussed the details of the bugs on JIRA. We filed tickets there, and checked them off when done, and used it to review what had gotten done after each iteration — but nobody used it day-to-day. If discussion was to happen about a bug, it happened on Slack (which is horrible for ever finding it again, but it is fast).
The reason, I believe, is simply that JIRA is waaaayyy tooooo slow. Nobody wanted to use it day-to-day. You made a list of stories at the beginning of the iteration, and you checked it again at at the end of the iteration, to mark the ones you did done. I did this too.
Now, all the discussions directly about the bugs/features in the tracker happen directly on the tracker. Which, I recalled, was how it used to be several years ago before we moved to JIRA (from GitHub issues).
There is a lot of other stuff that is clunky about JIRA but I think we could have probably dealt with it, if it wasn't so slow that every interaction — even simple things like "find and open the bug I was working on most recently" or "see what is assigned to me this iteration" — felt like rm -rf node_modules && npm install and you somehow find yourself checking twitter before it even opens...
Speed matters!
I think there are multiple clones of JIRA that literally just focus on the performance part. I think at this point it's unrealistic to expect major performance improvements in a timely fashion with JIRA.
There's no way to cater every possible workflow without feature bloat. However, the space is ripe for simpler, more accessible solutions that supports work across multiple projects.
Atlassian products are all like this, and each one is a horrible trash fire.
Confluence is the worst wiki product I've ever used. Gross syntax, slow, clunky plugin system, awkward permissions. Install MediaWiki and be done with it.
Bitbucket is slow and feels like it's from the 90s. It doesn't seem to do multithreading well - sometimes force pushed branch rebases pick up a new, unrelated author. A bug that hasn't been fixed in years, and only one of many. How many times will merging not actually work?
Jira is a special kind of hell. It's like every team needs their own embedded Atlassian solutions engineer to get it into a usable state. Not an EM or PM, but a specially dedicated role just to deal with Jira nonsense. Why even bother?
Atlassian is like Salesforce for business process, but if it were written by all-remote temp contractors churning through Jira tickets themselves.
They also hid bugs from being counted in reports by marking them as stories but that's another conversation
These tools market themselves as creating transparency but they are in practice often used to hide or excuse things.
I suppose that is why they all take the tragic path from being heralded as new and fresh in the beginning to absolutely being hated in the end.
Goes for methodologies as well (I remember the agile manifesto ... look at where we are now).
The complexity comes from the demand of Jira's paying professional customers.
Eventually Jira will grow too complex and bane the way for simpler tools probably of a different paradigm. Much like how Jira replaced things like HP Quality Center or the tools of Rational Unified Process.
It says "missing" but it mostly talks about those existing features lacking any polish.
> and that it's super slow!
It is and it really sucks or to quote Firefox "A web page is slowing down your browser, what do you want to do, wait or stop it".
I actually like JIRA and Confluence and have generally had good experiences using them in multiple companies. One of the main things I like is the integration between the two, and Confluence's concept of spaces so you can have some things publicly facing and other things private, which allows you to use Confluence documentation as user-facing docs, which references JIRA issues directly for known issues, and can write requirements/specs/PRDs in Confluence and reference them easily within a JIRA issue.
The only real problem JIRA/Confluence have is being very very slow. They've gotten marginally better over the years, but they're still terribly slow compared to competing offerings.
The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary. Most developers do not need this info, and do not have the power to easily change things. All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket. I would believe this is not impossible to avoid, but I do feel a simpler structure using labels, milestones and issue tracker is far, far easier and less prone to being misused. GitLab and Github can both do this as far as I know.
And sure, JIRA integrates nicely with other products (Bitbucket, Bamboo, Confluence). Other products have these integrations on a more modular level and still load faster and have small QoL differences over JIRA. Maybe big corps need a bit more, but JIRA seems to be too focused on managers and suffers from feature creep to the detriment of user experience.
In the Atlassian ecosystem, the markup languages are constrained by the following equation:
JIRA Markup != Confluence Markup != Bitbucket MarkupAs many others have mentioned thought, it is abysmally slow. At least their Cloud offering is, which is the core product we use at my job. I've used older on-prem deployments though and they were lightning fast. Seems that they're deprecating this solution by 2024 though.
I recently completed a JIRA survey, and slowness was my number one complaint. Hopefully the Product teams read through those surveys or peruse HN. Everything else about JIRA works great for our Software Development needs.
Any suggestions for that similar synergy? Doc/Issue Tracker/Code base integration?
Let me walk that back a bit - I have no experience of the cloudy version which unanimously seems to be derided as slow. Atlassian - you might wanna fix that. Like yesterday.
But server (& datacentre) editions - best in class for my money.
In terms of features, the Rally / Agile Central (did that just re-brand again?) rollup roadmap view is the only missing feature i crave. Atlassian should just merge the portfolio product into jira.
As for everything else - speed is absolutely fine if hosted well.
I tend to council people to try to use less features not more - often jira features are used to attempt to work around challenges that are best addressed by talking to people instead.
It integrates with everything, no matter what source control, build pipeline or IDE tooling is in use, there’s integration with jira.
The REST API is absolutely usable (mostly for workflow automation and analysis purposes).
Datacenter is still supported but I think they’re jacking up the price of that too.
Well, performance wise they're as bad as the cloud version. Even when you give the instance a lot of CPU / Memory. The problem is not only the Spring application itself, the DB seems to be missing some indexes or the queries are super badly optimized. God only knows what's really happening under the hood, but my self hosted Jira instance isn't any better (I've tried them both, cloud and on-prem).
I agree there are/were the best in class for the money--but with Atlassian throwing all their resources into cloud now, raising the prices on on-premise, I worry for its future. I suspect we're only going to get timid features--nothing bold that might improve the UX/UI, or anything that will break the migration path to Cloud, which is their end-goal.
If I was starting out again, I'd probably examine YouTrack where there's at least some assurance they are investing in its future.
That said I would rather to "issue tracking and planning" in a checked in text file and maybe have some bug tracking tool rather then working with Jira.
If Jira takes a performane hit by lowering the bar for the non-techs, fine.
Just use the tool.
https://joearms.github.io/published/2014-06-25-minimal-viabl...
In use from 1985 to 2014 and maybe longer.
- Whatever GitHub/GitLab provides if I need the most basic level of tracking.
- Trello for a more polished experience, a few additional ticket/board related features and easier involvement of non-developers.
- Linear if there's a bigger team that needs more than a bunch of boards (backlogs, roadmaps, projects, teams etc.).
2. It is dog slow.
3. It is dog slow.
...
When my team had an important as-quickly-as-possible sprint, we dropped Jira and switched to Google Docs as it was much easier and faster than Jira.
My conclusion was that Jira doesn't do much for developers that can't be done in some Google Docs/Sheets.
Then somebody would have to copy it to JIRA so the work would get tracked.
But very little of the planning, work breakdown, day to day updates, or discussion actually happened on JIRA because it was literally like a hundred times slower (with the convoluted UI compounded by incessant "wait... is it even loading?... oh, OK, it finally loaded" at each step of the way).
We had a product manager who used to write tickets in OneNote and then copy and paste into JIRA when things were quieter in the evening.
We build it so that almost everything you do in the app instant (<100ms)
I imagine this is because JIRA (2002) predates Markdown (2004), or at least its mainstream popularity when GitHub adopted it.
Jira sucks because it is unopinionated and infinitely customizable. As a result, everybody who believes they've discovered the perfect project management setup (spoiler: they haven't) is empowered to cook up their vision via an inscrutable set of customizations. This leads to a bunch of inconsistencies between projects and endless bikeshedding. I imagine all this dynamic configuration is also the reason their cloud hosted version is so painfully slow.
Every project I’ve ever worked on, features are finished, apps and websites are shipped, clients are happy and pay the bills, yet the burn down just goes straight to the right and never down. Sometimes right and up if people added more tickets during the sprint.
We look at it at the end of the sprint and say ah well and continue on our way.
Then sometimes a PM type decides it’s a problem but nothing ever changes it.
Draw your burndown chart on paper and you’ll have exactly the same problem.
I have used a whole bunch of ticket/project managing tools in a number of different orgs. By far the most useful is JIRA.
taiga.io comes close, but lacks the admin interface and multi project overview that jira has.
Trello is ok, but terrible for large teams, or large projects. Subtasking is a pain and there is no real concept of a sprint. its ok for replacing notes on a board, but terrible for recording state.
Some of these criticisms are valid, but compared the competition[1], I'd choose JIRA 7 times out of 10.
[1] dont get me started on the "clever" people that decided to make their own in house solution, kneecapping the entire planning ability of a 70k person org.
[1] https://spartez-software.com/products/whiteboards-for-jira
Here's another product I found recently that allows users to draw out their project plan, and have it turned into management-friendly reports automatically:
No comment on whether or not this is actually good, since I have never tried it, but it presents a refreshing concept.
The community/FOSS version mainly lacks the kind of reporting that jira has (the paid/Enterprise version has some basic reports, such as burndown charts). It's not perfect, but it's fast, simple and has an easy API and webhooks.
In the field I work in (CRM/webdev/consulting), JIRA used to be everywhere. Now all those shops have moved to Gitlab.
I found it interesting that the first bullet point (at least when I loaded the site) was:
< 100ms
Built for speed
Synchronized in real-time ...
...No spinners or waiting.
That's not what I'm getting from this list.
Worse, almost all of the points (all maybe? Haven't checked) declare that something is "missing".
Please god no.
Jira isn't missing more features. When you make a list like this, some product manager at Atlassian is going to turn it into a bunch of scrum epics and jira will be even worse in 12 months.
What should, IMO, have almost no interaction with the ticketing system, ends up being a chore for development which adds 0 value to the final product.
Apart from that, I think the only item on this list that really puts its finger on a key problem is #1, inability to manage dependencies between projects. You try to work around Jira’s problems by splitting the work into separate projects, but then they’re almost completely siloed, and Jira doesn’t help you connect them up.
The other problem I have with it is that it’s too fussy about the hierarchy of issue types. You have sub-tasks, stories, epics, and initiatives. Each one has special semantics and certain supported operations. If you started defining some work at the wrong level of granularity, too bad, because switching everything to a different tier is complicated and massively slow (literally a multi-page wizard, a progress bar and a confirmation screen when making a “mass edit”, i.e. a trivial edit to two or more issues).
Hierarchical issues is a good idea, because that’s a very natural way to break down and refine work estimates, but it should just be an arbitrary tree, not a strict and limited set of tiers.
Too much complexity, not enough generality. (And not enough speed.)
Competitors too will likely drift into the same quagmire unless they're unashamedly opinionated.
https://twitter.com/HackerNewsOnion/status/98160924222131814...
The cloud versions are also far more expensive and while I’ve always liked the software in general (apart from it being dog slow), a big draw was how cost effective the server products were. So I’m about to start evaluating GitLab, YouTrack, etc. to start moving these companies off Jira, Bitbucket and Confluence in the next year or so.
> When the users need the features from Jira and request them to configure the plugins for many application scenarios, which contribute to the overall complexity of UIs.
Becomes
> When users need features from Jira they request plugins, which contributes to UI complexity.
Not a criticism - just thought this might help!
If it's so targeted at developers, why not use a monospace editor in markdown with easy code highlighting instead of the abomination they have?
Confluence and JIRA use a different markup language for posts and none of them uses Markdown (in any flavour), which I would also use to write in-code documentation, like in a README file
The markup you write gets turned into in-editor "objects" (for lack of a better term) as you type it out. This makes editing an incredibly painful experience. I am occasionally asked to document something on Confluence for a client and every time I feel like I am fighting a battle just to make a basic document.
For example, I strongly dislike their implementation of ordered list editing. They have tried to make the ordered list editing mode "smart", but it mostly just gets in the way, and is harder than writing it out manually. Additionally, you cannot embed other "objects" in an ordered list. If you attempt to insert a file object, or something similar, it splits your ordered list into two, with the second list starting its ordering at the beginning. This would seem to defeat the purpose of having a rich editor with embeddable objects, since I cannot use them if I am making an ordered list, such as set of "how to" steps.
I usually give up an hour in and switch to writing in my text editor instead, but even then Confluence will mangle my input in surprising ways when I paste it in. Rule #1 of making an editor in my book is that it has to be, at a minimum, as easy and useful as a basic text editor. Microsoft Word and LibreOffice, in spite of their faults, are quite good at this. I would guess most software shops could not implement a WYSIWYG editor at that level of polish, and they would be better off just providing editable markup.
My company uses it and tolerates it, but at this point it now takes 8-10s to load a single issue from the board view, and ~5s to toggle the edit state. There is basically not a single action I can perform that takes less than 5s to execute, and some take more (backlog, etc. view take upwards of 30s to load a few hundred issues).
This is just not OK. And we're using hosted, Next-Gen. No fancy customizations.
Every. Single. Click. takes 5s+ to register a reaction. I'm on a gigabit internet connection and have a 16" MacBook Pro with all the dials turned up (eg it is NOT me).
Anyway, from personal experience of working with large, distributed teams and (later) leading team that included developers, designers (who had no idea what software development workflow is), and electrical engineers, I have to say that still there is no replacement for Jira. And I'm saying that after trying dozens of alternatives.
Now, maybe things got changed in the last five years, but something where Jira still shines IMHO:
* Self-hosted, free for small teams, you get access to *every* release they made. All these cloud-hosted solutions sound nice until they close the shop.
* Almost infinitely configurable. Going from Jira to enter-your-favorite-simple-tool feels like going from Emacs to the chalkboard. Your CEO likes workflow X, sure. Your designer wants workflow Y, no problem. Your plumber used to Z, done. Irreplaceable when you work with the teams from different fields.
* Bazillion plugins, integrations, name it. You are still missing something, go and write a plugin in any JVM language you like. It probably will work for all Jira versions with small modifications.
* Management, CEOs, even front-end desks like it. Easy to sell, no matter the price. I had a harder time selling Zimbra (which is free) to CEO than Jira, because every CEO knows about Jira :D
It used to be really annoying that the plugins were split between Server and Cloud. You'd find the prefect plugin for your task and then find it was only available for Cloud or Server.
There are so many systems out there. Right now we're also evaluating YouTrack from JetBrains and OpenProject.org (which is a fork of a fork of RedMine).
We don't want to have to move again any time soon, so while we're evaluating features we're also trying to predict stability and viability. To that end, when available, I'm including in our evaluation notes 1) when the company making the system started; 2) when the system was launched; 3) how many staff the company has.
JetBrains started in 2000, YouTrack launched in 2009, and they have over 900 employees. OpenProject launched in 2012. Both seem to be stable and under active development.
ClickUp has a lot of features and looks nice (we haven't dug into it yet). But they launched in 2017, and raised Series A funding in June 2020. So they're young. That doesn't mean they're bad. It just means they're less known, and have not proved long-term viability. On the plus side, it also means they don't have the 18 years of cruft in the system that Jira (launched in 2002) seems to have.
In my experience the right project management system can really help developers, so I always want to hear everybody's experiences, good and bad.
The main issue is lag and clonkyness and forcing ppl into the cloud according to me. Not missing more custom workflow ...
1. It is slow
Same goes for Asana and Slack.
Some utils to add to `bashrc`:
alias jo="jira open"
alias js="jira show"
jos() {
ticket="$1"
if [ $# -eq 0 ]
then
jira open
else
jira open PROJECT_NAME_HERE-"$ticket"
fi
}
jss() {
ticket="$1"
if [ $# -eq 0 ]
then
jira show
else
jira show PROJECT_NAME_HERE-"$ticket"
fi
}
jqlf() {
jql="$1"
chrome https://__PROJECT_NAME_DOMAIN_HERE__.atlassian.net/issues/?jql="$jql"
}
alias jm="jira mark"
alias jcs="jira create --project PROJECT_NAME_HERE --type 10001 --priority 3" # create story
alias jcb="jira create --project PROJECT_NAME_HERE --type 10004 --priority 3" # create bug
alias jce="jira create --project PROJECT_NAME_HERE --type 10000 --priority 3" # create epic
alias jjq="jira jql" # custom query
alias jql="jira jql" # custom query
# example:
# jjq 'project = PROJECT_NAME_HERE AND sprint = 158 AND "Epic Link" not in (PROJECT_NAME_HERE-4695, PROJECT_NAME_HERE-4373) AND status in ("Push to PROD") ORDER BY cf[10008] ASC'Really? I think search is one of the most compelling features.
I find most of the time when I can't find something, it's because of different terms used, such as searching for "schedule task failing" vs the ticket saying "job run error". (Usually once I eventually find it I just edit the ticket to have the other keywords I tried)
The UI for selecting advanced search is acceptable.. it's not the easiest thing - for example searching open vs closed on GitHub is an much simpler - but it also exposes a lot more of the fields.
Personally I use the text-based JQL interface most of the time. It's very powerful, and as the name implies, anyone that knows SQL will find it familiar. A quick example, an easy way to find bugs closed in the version you're releasing but that weren't correctly tagged: `(type = bug) and (fixversion is null) and (status changed to closed after 2020-12-02)`.
And search you do is updated in the url (easy to share with others), and even better, if you paste that url into Confluence, it turns into an embedded dynamic list. This is great for release notes, or making category pages of certain types of tickets (eg: all open bugs related to feature x, or all bugs older than 6 months with more than a few comments, etc). Yeah you can build reports with this, but I find these are more accessible and used when they're organized within a logical structure in the wiki vs buried in a flat list of dozens or hundreds of other reports.
I sense a lawsuit from Atlassian poised at Zepel incoming.
Atlassian is basically the centre of the so-called "Agile" industry these days. Jira is just a reflection of it.
1. When editing a comment, the textarea is tiny and placed in a pop-up, instead of in the page. Can't resize that to see the comment better.
2. After disabling shortcut overrides, the shortcuts are simply disabled, along with the default browser behaviour for them.
3. Refreshing a page resets scroll-status. Seriously, webdevs, stop hijacking normal browser scroll behaviour. You always make it worse, never better.
4. If your login session times out when you're writing a comment, you can't publish it, but the error message isn't clear about the reason why. There was some button in the error message that caused you to lose the entire contents of the comment you were writing. Happened to me several times after writing comments 8+ paragraphs long. It's infuriating.
The other problem with Jira is the Atlassian push into confluence that tends to go with it. Confluence is so infuriating. Oh what, you want to do a simple operation like copy-paste data from one section of a table to another? Fuck you. You want built in markdown? Fuck you. You want to embed github pages? Thats a plugin and an ordeal to get approved...etc
People always talk about how it's just a wysiwg and so its for the non-techs, but the thing is it's so specific and non-standard they are still having to learn how to use it anyway. Why not just get them working on github wikis or something?
Also: ffs, stop trying to do "smart searching" for me! It's literally the most useless feature ever, and has never returned anything close to what I was looking for. Yay for having to learn JQL just to do a semi-advanced search. How many query languages do we need to know these days?
I disagree. What makes JIRA a pain is that it has too much. It tries to be a solution for every possible workflow and ends up being a slow, clunky, and confusing solution for all of them.
I personally think the best thing Atlassian could do is spin of JIRA into multiple apps which all use the same core, but have different interfaces designed for different workflows. Of course, that's much easier said than done with such a ubiquitous monolith as JIRA.
I'm sure it has something to do with Angular or modern JavaScript development, somehow.
I'd rather poke my eye out than navigate around in Jira.
I regularly come across situations of the form "we finished Task XYZ a few months ago, but I want to come back to it." Maybe the ticket has an attachment we need for long-term documentation purposes or a test detail we need the next time we review the code.
Jira search rarely finds anything useful-- the S/N ratio is terrible with non-development tasks mentioning XYZ, yet ignoring actual XYZ tasks due to poor naming and heirarchy. I usually instead look at the code itself, see in the git history "This was modified in ticket 345675" and then use that to index Jira back to the info I want. From there maybe I can walk between linked blockers and sub-tasks to get what I want.
My pre-Jira experience was on Basecamp v1/v2. I appreciated the forum-style layout, because it tends to allow for a few key things: * "Search" and "browse" are both well supported use cases * Old content remains usable and structured, rather than dropping off a cliff after the last ticket closed. * Content can be grouped as it makes sense-- say you get a customer feedback item that touches on three eventual tasks. It would have to be (possibly sliced up and) attached to all three tickets in a Jira model. * It felt "discussion-first"-- the discussion of what to do and how we want to do it is central. This tends to archive some of the subtle choices and gotchas that won't appear automatically in a ticket.
I always dreamed of a system that basically added lightweight ticket/kanban model on top of Basecamp. I can see the value of tickets as a trackable unit of work, but it feels like this would be little more than a few tiny tags decorating a readable discussion flow.
I like Jira when I don't have to use it. For example, setting up GitHub automation so that changes from Git will cause tickets in Jira to transition to the next stage. Or, automating a transition from "Pending Estimate" when a Jira user assigns story points to a ticket. The automation features in Jira are far beyond anything I've ever used before (one might even consider it an "IFTTT for project management"), and on most teams I've been on, very much under-utilized. I can even automate starting the process of development when design is finished, as when the design ticket is marked "Done", the development ticket it's linked to will change to "Pending Estimate", as it's now possible for a developer to estimate how long it will take to implement the given design.
Jira could become perfect in every other way, and would still suck if they don't fix this.
I remember 10+ years ago jira had straightforward tables, it was much quicker to add, remove, close issues. I’d open a bookmark to a page with a simple table listing of all issues assigned to me.
I don’t know what the heck is going on, now the ui is this awful "modern clean" style with popups everywhere, sidebars, everytime i look at an issue it’s cramped in a tiny column, or i have to open in a new page. The whole ui is so slow and clunky, you have to expand/collapse content all 5he time. All in the name of what? Is scrolling down a page so difficult for a user? How does Amazon make money?
Engineers are an autonomous bunch, and the best coders among us despise doing anything that isn't actually writing code. Unfortunately, like doc writing, there is more to being a good engineer than writing code.
I guarantee that it would have had most of the folks here, whimpering under their standing desks.
It was the Tenth Circle of Hell.
It gave me a sort of PTSD, so that, now I'm on my own, I try not to write anything down, and, if I do, it's usually a small list on a whiteboard.
If I never see JIRA again, I will die a happy man.
That said, it is like blaming the asphalt for the eminent domain seizures for a road. It's a symptom.
https://height.app is also quite good
We all suck just accept it and try to improve yourself and others point by point in that new 2021!
I didn't really mind using JIRA to track my daily dev work, it seemed fine to me. It was annoying that each team had different custom fields etc and seemed a bit unwieldy in that respect.
https://www.jetbrains.com/youtrack/?gclid=EAIaIQobChMIx5iu7O...
There is no “easy” UI for this. The problem to solve is merge conflicts, and Atlassian (rightly in my view) clearly decided that real-time collaborative editing of the draft beats forcing users to do merge conflict resolution when saving changes. Wikipedia takes that latter strategy and it's a huge hassle.
My belief from seeing many organizations struggle with Jira is they have process issues that need to be addressed outside of Jira. Jira is simply the place where their process becomes visualized and put into place - so it gets blamed for the breakdowns.
Reading through this list, I can picture exactly why this user is having these complaints. Some of these a definitely UX frustrations, but many of these seem to be fundamental process issues or contradictions. For example, the website claims "missing easy setup" - while also listing a bunch of things that demonstrate the complexity of their Jira setup.
-----
tldr: If you're having the issues the author lists, you should probably check your process. Jira is doing you the favor of highlighting where it's broken.
Simply adding more things to Jira that are supposedly missing won't fix it.
But if you find a company where they want to create their own ticket tracker in house, run. It means they're pennywise pound foolish
None of the missing features matter in the slightest in the face of the completely unusable performance.
What alternatives are people using?
* Google Analytics
* Google Search Console
* Jira
So basically I wait and wait and wait to manage projects to make websites fast.
And it’s slow. And the UI is awful.