I definitely hate Jira, not my manager. I hate the way it insists on rewriting any links I paste (or anything it thinks is a link). I hate that I can’t hyperlink something that includes monospace formatting. I hate that when I double-click a word in the ticket to highlight it, so I can copy it, it switches to “edit ticket body” mode instead. I hate how some URLs can be command-clicked to open in a background tab, but not all. I hate how if I copy an ID from the middle of a bulleted list line, and paste that into my comment, it starts a new bulleted list with just that number. I hate how it makes over a hundred Ajax requests to load a ticket – and I hate that I know this, because I have been reduced to grovelling around in the dev tools in a futile attempt to get a plaintext version of the ticket body. I hate that this isn’t even an exhaustive list.
Jira consistently gets in my way and slows me down, and provides no escape hatches. It’s definitely the software I swear at the most.
About the edit mode - I particularly hate when I’ve left something in the edit state and forgot to submit it. Getting in the editing mode is automatic but actually submitting the edited text is manual. It’s like the worst of all worlds when it comes to AJAX text manipulation.
I thought of it it as a drafting mode. I sometimes leave tickets semi-edited and come back to them later with more information, and I’m glad they are still in an editing state and no-one watching the ticket has been notified of my half-baked changes. But that does make it more likely that I’ll make changes and forget to finalize the edit.
I don’t think rewriting links is a standard behavior, perhaps your instance has some plugins? Also, field types can be set to be text so they won’t be parsed.
Hyperlinking can be done on pretty much anything if you go into advanced edit mode, which is tedious. But why are you hyperlinking stylized text in a ticketing system? Sounds like you’re using it more like a wiki / documentation repository which is not what it’s for.
Double clicking is an interesting one, and is not a problem unique to JIRA. In general, web applications that allow editing don’t deal with this behavior well. This could also be fixed by not using the “quick edit” node and requiring the edit screen to be used to make changes. Again, a configuration thing that you’re not happy with.
Copying an ID from a bulleted list, again you can use the advanced markup mode if you’re trying to do such detailed editing. But I do agree the WYSIWYG editor leaves a lot to be desired.
As for AJAX requests and load speed, absolutely! This gets into the reasons I hate JIRA too. It’s just patch on top of patch for the last 15 years to add on new features with little value, and a big performance hit.
I don’t think rewriting links is a standard behavior, perhaps your instance has some plugins?
I’m pretty sure this is a built-in behaviour – where I type “heroku.com” and Jira replaces it with a button that says “Cloud Application Platform | Heroku”. With top level domains this just makes for awkward sentences, but rewriting links often hides relevant information.
A couple of months ago I received a ticket that included EIGHTY FOUR URLs. Some poor soul - maybe the customer, maybe our support staffer – had taken the time and trouble to pull together a comprehensive bug report. But the relevant info is in the URL query parameters. Which I can’t see, because Jira has rewritten them to 84 identical <title> tags. Copying the comment body gives me the visible text, not the underlying links. Clicking through is hard, because every item in the list looks the same and I worry I’ll lose my place.
At no point do I feel like Jira’s helped me investigate, or made my life easier.
why are you hyperlinking stylized text in a ticketing system?
I’m hyperlinking stylised text because I am trying to be helpful to my colleagues. I’m trying to communicate clearly, and let them follow a linear route which I had to pull together. For instance: “I’ve tracked the error from this POST request to the HatsController#create_request action, but I haven’t figured out the underlying cause yet.”
All I want is the same expressive capacity that Markdown provides, and not have to contort my writing to fit Jira’s arbitrary formatting restrictions.
Sounds like you’re using it more like a wiki / documentation repository which is not what it’s for.
The last time I checked, Atlassian’s wiki doesn’t support hyperlinking monospaced text either.
Copying an ID from a bulleted list, again you can use the advanced markup mode if you’re trying to do such detailed editing.
This really isn’t detailed editing. The ticket body will say “Customer reports they can’t see detailed information on these three dinguses:” followed by a bulleted list. Using copy-paste to prepare my reply – “Dingus IDs 582023875 and 582032442 are working as designed, as they have the ‘hide detailed information’ flag set, but I can replicate the problem with 58214432” – gets me into a fight with a text box.
Thank you for the detailed response. I spent some time checking the items you’ve pointed out and it looks like these are cloud “improvements”. On my server version, URLs are not automatically converted into buttons with site descriptions. Something like “heroku.com” doesn’t even get highlighted as a link, whereas “https://www.heroku.com” gets the browsers default styling for a link.
And for monospaced text, it works fine with the WYSIWYG editor (on server), so probably another cloud “improvement”.
It sounds like that one feature is causing you a lot of pain, and these kind of cloud “improvements” are definitely one of the reasons I hate JIRA. Someone decided we all want links auto-scraped for site descriptions into fancy buttons - in an issue tracking system, and every cloud customer gets that whether they like it or not.
I hadn’t really paid attention, but yeah, my Jira is doing this. I found this out:
If I type heroku.com it gets turned into a regular text link without any changes.
If I highlight heroku and paste heroku.com from my clipboard it does get turned into a button-link that says “Cloud Application Platform | Heroku”. If I think hit Cmd+Z (undo) on Mac the button is removed and it’s just a regular text link again.
So if this is annoying you and there’s no way to turn it off in your Jira settings (I have no idea) you can perhaps at least use undo to get rid of the link “enhancement”.
… and buggy. Last time I had to use Jira there were half a dozen bugs that really got in the way. Like the formatting language being completely different depending on the screen at which you started editing a ticket, and the automatic conversion from one formatting language to the other being broken so that occasionally, even if you did everything right, sometimes your ticket would end up with piles of doubly escaped garbage instead of formatting. This wasn’t an extension, this was core Jira. Though I suspect that particular issue is fixed now.
Are you on a cloud instance or self-hosted server? I’ve seen both be slow, but self-hosted is usually the worst IMO (under-specced or poorly-configured hardware, I would guess).
Yeah, I’ve experienced slowness with both. Even with self-hosted and throwing oversized hardware at it, it still tends to be quite slow (albeit a little faster than cloud hosted).
If the feature set of the processor was driven by the sales team trying to make every last sale and meet every requirement no matter how weird, and the engineering team didn’t have a say in how it was designed, yeah I probably would!
I mean, if you put it like that, yeah I do kinda hate modern x86_64 CPUs for those same reasons.
They’ve been trying, for sales reasons, to meet the increasingly ridiculous requirement “more single-thread performance for the same old instructions”. And this has driven them to make increasingly dangerous engineering decisions, resulting in the slew of CPU vulnerabilities we’ve seen, along with mitigations for them that undo most of the performance wins.
I’d say that ties into my reasons for disliking it too. I think many of the “features” added were just to get more sales, no matter how it crippled other things that were working just fine. Meanwhile, highly requested features go unimplemented for years because Atlassian doesn’t think it’ll make them more money.
thanks for the tip on jjira-cli - i’m tired of Jira causing firefox to leak so much memory with their laggy UI that I have to restart my browser twice a week. i’ll have to give this a spin
Yeah, I also found it really hard to use it without a mouse, which I don’t have for disability reasons, and somehow I could never internalise the navigation tructure.
So the aforementioned “pain” was literal physical pain, due to having to use keyboard mouse keys in many places on Jira, while trying to find my way. Much easier with cli and some aliases.
And my $0.02: Plain Jira with mostly default configuration (no “fancy” over-engineered workflows, no “fancy” issue types with multiple custom fields etc) is a pain, too. Multiple times I’ve found myself writing some Python script utilizing their API to get something done in a more efficient and (power)user-friendly way, than through their bloated web interface.
But the main problem I have with Jira is how easy is to hide information by for example, only reviewing a dashboard where tasks with a label or belonging to current sprint are shown. A few days back I wrote a little (8-10 lines) Python/Flask script for locally-run backend calling Atlassian’s API, with HTML+JS parsing JSON response. Boom - we missed a kinda crucial task because someone forgot to slap a label or mark it for current sprint. And as people’s “Your work” lists are growing, they forget backlog items in the constant flow of new feature requests and overall startup dynamics. One fairly simple change to Jira defaults and things not shown on a dashboard are being forgot.
I hate Jira even though my manager haven’t toyed with it much. It’s way too easy to break if one doesn’t have Ph.D in Jira.
And as people’s “Your work” lists are growing, they forget backlog items in the constant flow of new feature requests and overall startup dynamics.
I have personally found the “Assigned To Me Gadget”, available for Jira’s dashboards, quite useful. It allows me to always have an overview of the tickets I am set to work on. I do push to have a small list of issues assigned to me at any point, which might also help with maintaining an overview of the scheduled work.
I wonder if your point also falls under “management issues”, alluded by @djx: is the Backlog section properly used? What are backlog tickets supposed to be exactly? My interpretation is that such tickets are expected to be scheduled, but not resolved in the immediate future; from what I have noted, my interpretation does not appear to be shared, and Backlog tends to end up being the “storage room” for ticket; while I can appreciate the value in not deleting tickets, since they were added for a reason, product priorities, and available resources do appear to facilitate an overlarge backlog. My stance is that such tickets belong in an “Idea Pool”, or similar, before being consciously moved elsewhere.
Decent writeup. A couple additional/complimentary points:
Jira workflow being absurd is totally your admin’s fault. First thing I did taking over a team was torching and pruning down to a reasonable number of steps and killing all the bullshit fields (components, system, priority, deadline, etc.) that had accreted. After a year, perhaps one has made its way back in as being useful.
Devs often totally suck at updating their damn tickets. I prefer a simple work log/mini-blog of what you’ve done on a ticket–if you can’t do this because it’s too much work, you kinda suck, sorry…engineers communicate, not just hack code.
The cloud thing is annoying.
Doing your own API work is kinda clunky.
Jira is slow and clunky, and their markdown support is just not quite right. Very frustrating.
Jira “exposes all the join tables” in their admin interface. It’s very clunky to setup some things, but as a product I understand they probably have legacy customers wed to that level of fine-tuning.
Jira has a great system for expressing links between issues, but sucks at doing something as basic as a dependency sort for epics.
I look forward to the day I get to use a different tool, but Jira has enough of the stuff I care about and I know that if I leave a team with it they won’t have trouble maintaining it or keeping it around.
I love the idea of the mini-log/work log on the ticket, I am assuming that it is left as a ticket comment ? Can you add a bit of detail? Does the team appreciate it?
It is something that I do for myself but I’ve never thought about asking others to do.
“I started work on this. Work is happening over on branch 123.”
“Okay, ran into problem with the package.json; seems to be some deps issue. Will look at tomorrow.”
“Outage today kept me from working on this; will try again first thing tomorrow.”
“Deps issue turned out to be SSL related. Details here: https//npmiswhack.example.com”
“Okay, basic AC met. Gonna ship this behind a feature flag. For future work, we need to include the retroentabulator.”
“Decided to poke at retroentabulator a little bit more…yeah, that approach will not work, dear god. see xyz.”
“Handing off for QA”
“Merged and deployed”
“Deleted branch; there’s some neat things I moved over to branch 234 for further work.”
Anybody who inherits the ticket should get a good timeline of how the work progressed, what surprises showed up if any, and basically be able to retrace the steps efficiently if they get assigned the ticket. The actual comments (the examples I gave above are deliberately terser than I’d expect, mostly) should always be read when inheriting the ticket or doing code review.
For tickets about bugs, I also want to see the reproduction of the problem, a creation of a working theory for how the bug happens, and then the confirmation of that theory, and then the fix.
Also, tickets without AC should be kicked back before people work on them, but that’s a different set of gripes.
Jira has a great system for expressing links between issues, but sucks at doing something as basic as a dependency sort for epics.
I’m glad to hear it confirmed this isn’t just me missing something. Last time I used Jira, I was baffled by how much expressivity it had for these links (arguably too much, at least in the workflows we were using) and yet how nobody in the whole organization ever seemed to get even the tiniest bit of value from it.
I mostly agree with this article in that most of the time when I see people griping about Jira, they’re actually griping about their organization’s workflow. It is totally possible to use Jira to keep track of a lightweight workflow; my team uses it that way and I find it a net positive for both my personal productivity and my team’s productivity.
But it’s not as big a positive as I’d like. The software is obnoxious and full of blatant usability problems that remain unaddressed for years on end. It’s not the worst offender I have to deal with in my day job (that’d be AWS QuickSight, whose UI is so abominable and user-hostile it’s almost impressive) but Jira never rises above the level of “tolerable” for me, which is a shame considering how often I need to use it.
For a little while my team was using ClickUp. It had its share of annoyances and limitations too but I found it more pleasant to work with. Jira was imposed on us from above, and it didn’t seem like a hill worth dying on, but I wouldn’t say no to switching back.
FreeBSD evaluated JIRA when we moved our bug tracker away from GNATS. We rejected it for a few reasons but primarily because doing anything in JIRA required clicking through twice as many things as the second worst option, for the same workflow. Any time I’ve had to use JIRA, it’s been the same experience: I need to interact with the tool far more than I should and moving to the same workflow in any other tool has been an improvement. It’s pretty safe to say I hate JIRA.
For our use case, we rely heavily on the custom workflows. Think manufacturing, with thousands of tasks per week for hundreds of people.
I really liked ClickUp, but the workflows just aren’t robust enough. Many of the issue trackers that claim to have “custom workflows” are nothing more than a decision table based on status.
If we didn’t need to ensure a specific flow was followed, we would have picked something else a long time ago.
I completely agree with most of what is said here. Except, Clickup. Having had the move from JIRA to click imposed on us. Wow. I am in awe of clickup. It’s pure genius. Give users enough rope to hang themselves, then charge organisations consultancy time to fix the issues. Except. The consultants don’t fix the issues they just give everyone “homework” which is coming up with ideas on how to fix issues.
It’s easy to be glib and say “no it’s definitely jira that I hate”. I’ve used many systems, and I think jira is unpleasant and I think that it’s jira that is at fault, but this article basically goes out of its way to blame shift.
There are numerical us examples of things that people dislike about jira in the article, and every one is given a different scapegoat, to the extent it almost feels like a no-true-Scotsman defense of jira.
The reality is that even if jira does have a “good” setup, it’s clear that the defaults aren’t good, and it’s trivial to make it worse.
The article is definitely intended to polarize people, and hopefully make them think critically about their problems. It’s stated as an absolute, and absolutes are always wrong ;)
At the end of the day, there’s always the reasoning that you actually hate your manager because they’re the one who decided to use JIRA…
Google Docs, Office365, Zoom, Slack – all of them react instantly to my input. They feel like well-designed tools.
In JIRA I could go have a cup of coffee sometimes while waiting for a text form to save. I don’t even understand how that’s possible, with 2023-level computing power and relatively simple data fields. It’s like trying to chop down a tree with a saw made of cardboard.
I consider Slack pretty slow and tedious to use (measure the time it takes between your click on a channel and its content showing up,) but Jira is undeniably on another level of pain.
To be honest, the “right way” to use Slack for me is to use Ctrl-K and Ctrl-F almost only and the Unread and Threads (I wish those could be merged) and Basta. 90% of the time, I don’t click on anything and just jump from channels to unreads and pm and etc.
Yeah, I’ve never been able to get accustomed to the keyboard-only workflow. Maybe if my setup forced me to not use the mouse, but it’s just too damn convenient of an input device for me to even consider dropping it.
But I do still feel a significant delay between clicking the search box and the input box appearing, so I assume it’s the same with Ctrl+K. Opening any window in Slack just likes to take ~300ms for some reason.
Oh I do use my mouse for scrolling/emoji reaction etc. But I just don’t want to use that sidebar of doom with hundreds of channels (triaged by section) ever 😅 So Ctrl-K provide me a kind of command pallette to move around via keyboard.
Some people want to be given work, plenty of time to do it, and make sure no one else knows how to do their work - lest they be replaced. Before the remote-work-revolution, it was harder to get replaced. Now, quick access to global talent makes it much easier to get replaced. I guess it’s why some people have become more protective of their work.
What I’ve seen more often is devs who want more autonomy, and (project/product/people) managers who want their devs to work on what they (or the team as a whole) have decided is the right thing to work on right now, and to focus on that and get it done.
I think that (generally!) the right thing to do as a dev is not to hide their activity (working on what they see as actually important) but make the case for the business value of their work and switch teams or companies if they just can’t agree.
Jira is designed to assist with micromanagement. It empowers a level of analytics and process that has nothing to do with assisting me, the person doing the work. It always becomes, at every job I’ve used it at, a tool for talking about the flowchart of work vs talking about the work.
Trello, for the years I used it, was designed for me, the person doing the work. The idea was I could get in there quickly, write down an update or move a status and then leave again. It didn’t have tags and assignee and group and status and tshirt size and all the other work management fads in a giant toolbar to the right of my screen. I had the work, a checklist of the work, a due date for the work and a place for people to discuss the work.
But because it doesn’t empower that layer of bureaucracy above me to generate charts and tags and kick off automation to move the tickets through this 1950s style factory, it can’t really compete.
At my previous job, I didn’t fine Jira to be that bad. Slow, yes, but otherwise, once I got things set up for our team, it was okay. At that time, each team had its own queue, and you could link tickets across team queues. Then new management came in, and insisted on everything being done in just one queue. So there went our work flow (ten years, on time, on budget, best vendor for our customer [1], only two roll backs during deployment to production) and the new flow forced on us make Jira painful to use (took less than a year for us to be chronically late, repeated deployments because we couldn’t do them right, lose our preferred vendor status and I’m surprised we still have our customer [1]). So I think it really comes down to how Jira is used.
I agree - at my previous job we used Jira and it wasn’t horrible. In the end we switched away from it (in favor of Phabricator, which I eventually learned to.. not hate) because indeed it was too slow, and the pricing curve way too steep. There’s a step from 10 to 100 users where the price increase is so dramatic that it’s basically a nonstarter for smallish companies of just over 10 people.
It is vastly overcomplicated for the relatively simple sort of task it has to do. If an organisation’s workflows are so complicated that they need such a complicated tool to manage them, then the real problem is the workflows and they ought to resolve and simplify those, not adopt such a horrible tool to attempt to track them.
Conway’s law applies in spades here: complex organisational structures produce complex software.
Be more grug. Be grug brained. Make software grug understand.
I think you’ve summarized a lot of the points in the article, but your first statement is that you disagree :). If the wrong tool has been selected for your organization’s use case, then you should probably hate on the person who selected that tool rather than the tool itself.
If you have simple tasks, then you should be using a simple tool and not the complex configuration JIRA can do. But even with JIRA out of the box you get tasks that have 3 statuses and can be dragged between columns on a kanban board. It doesn’t get much simpler than that.
The key thing with GitHub issues is that they allow but don’t enforce process. JIRA is set up with a particular workflow but a single workflow is rarely appropriate for more than 90% of tickets. You then end up fighting the system for the other 10% or you keep adding more complex flows to account for the long tail until no one understands the full process at all.
With GitHub issues, you either follow the process or you don’t. It’s up to you, and you’re an adult who is trusted to make decisions. Perhaps there’s a bit of truth in the article: if your manager chooses JIRA then they’re saying that they don’t trust their team to make judgement calls, so you probably do hate them.
From a pure user perspective, I enjoy using Trac for CHICKEN. It fits our small project quite well. I’ve also used it at my first job, and found it quite neat and easy to use. Our customer also never complained.
I don’t think it would suffice for larger companies, as it misses a lot of features that managers would probably want. But for simple project tracking, it’s perfect.
From an admin standpoint, I’m less happy with it. Recently we had some technical trouble where it would slow down and eventually report an error because the sqlite database would get locked (but only when logged in). This turned out to be caused by some obscure bug crashing during after-request cleanup in the session expiry code, causing us to accrete loads of dead sessions, leading to the db locked issue. Also, the project seems to be pretty much dead. For example, their ticket for releasing the next release has been open for 3 years (it’s an embarrassing read with multiple pledges like “I’ll get it done this weekend”). This release is essential, because it’s the first release to properly support Python 3. AFAICT, not supporting Python 3 is the reason the package has disappeared from Debian (it’s only available in oldoldstable right now).
Apart from Jira, I’ve only really used Github issues or sourcehut’s pleasantly-minimal knockoff of it. I like both quite well.
Oh, I’ve also used Trello and other kanban-y systems but I find for small projects or many small tasks they’re not worth the shuffling for me. Their value is really when you have a pipeline with multiple people doing multiple things that may take a long time or have high latencies. Physical engineers working on a pipeline of design -> fabricate -> finish -> test, for example. When the same person is doing all those steps, then having them separated doesn’t add a lot of value imo.
The issue-tracking built into Github and Gitlab has worked perfectly fine from my perspective as a developer working on projects hosted on both git forges. Apart from the fundamentally-ideological concern that Gitlab is in principle self-hostable and Github is not, I don’t even have a strong preference for one system over the other, they both seem perfectly fine for what I’ve had to use them for.
I specifically hate Jira for being an unbearably slow piece of crap. When my work is regularly interrupted by a 30 second long wait for a shitty web page to load. I hate how all the different widgets jump around while the site loads. I hate how slow it feels to navigate around to find what I need. That sort of stuff, every day, causes feelings of resentment.
Luckily, we only used Jira briefly many years ago. We’re now using Linear, which is much more pleasant to use IMO. I can just get in and do what I want to do and get on with my day, no more waiting for 10 different UI components to separately show spinners as they wait for data from the back-end, where each completes at a different time and jumps around as they do.
If it’s taking 30 seconds to load, it’s not JIRA. It’s your web server, customizations, network speed, or something else. This has to do with how it’s configured.
That probably has a lot to do with it then - and there isn’t much you can do about how Atlassian has set up their data centers, where they choose to host your site, and what they consider acceptable performance. Did I mention that I hate “the cloud”?”
For us, we’ve always ran it on-premise so we can connect it to internal systems we don’t want to expose over the internet. Apparently, the speed improvement was an unexpected benefit.
For a team that doesn’t care as much about their IP, has simple workflows, and doesn’t use the issue tracker enough to dedicate some admin time to - there are definitely better options.
My manager isn’t the one that takes 30 seconds to become responsive when i load the page, sorry. He also isn’t the one whose dogshit editor insists on doing the Wrong Thing™ with formatting any time I am trying to do something “fancy” like “have italics” or “add some code to a comment”.
My workflow and manager are fine – it’s the UI and UX of this specific tool that sucks complete ass. Every other issue tracker I have ever used has managed to be less slow, and fuck up less, than JIRA does. It just plain fucking stinks to use.
On one hand, Jira is a Taylorist dream. On the other hand, I can’t even see velocity values for individual people in vanilla Jira. So it really doesn’t even some of the most basic features.
I’ve found JIRA to be a excellent Vulnerability and Bug Tracker until we lost full admin rights due to the size of the business and that is when JIRA became unusable. JIRA’s IAM makes it near impossible to both have a secure instance and one that can be modified to suit the needs of each team. We couldn’t change workflows or add new tags or properties without reaching out to a JIRA admin and we ended up having to reuse workflows that weren’t created for us but that sort of looked like what we needed. We also found that other teams were using our special properties which would break our dashboards. It was a mess. I believe the only way to make it work in big enterprises is to have several instances (At least one per team) but then that breaks things like tracking issues across teams.
The fact is, JIRA is still simply the best tool for tracking customized tasks with customized workflows and being able to perform powerful searches and reports against them.
I found it hard not to stop reading at this point — it’s a perfect distilation of what I dislike about Jira. Those aren’t features I need or want as a developer trying to get work done as part of a small team, and Jira’s excessive flexibility and customisation makes it a much worse product for the “simple” use cases.
Workflows in specific are something I don’t want my task tracking tools to handle as they’re incapable of handling the nuance, flexibility, or vaugeness real-world processes actually have. I’m sure there are processes Jira is very well suited for, but it’s not the general purpose tool it’s presented as.
I’m sorry this was such a show stopper for you. It’s understandable that you don’t feel you need workflows, but it doesn’t make it less of a good tool.
I assure you it can handle very complex and custom workflows, if you put the time in to configure it properly.
Lots of teams at my work are ditching Atlassian before the new pricing changes: next February, they will no longer support “server products” and you will have to buy a “data center” license instead. That’s a minimum fee of $50,000/year for JIRA and Confluence.
It basically does everything the most basic UX designer teacher will tell you to avoid.
That was basically my reaction when we evaluated it for FreeBSD. We had advocates of each system configure a demo system for us to test. They were all implementing the same workflow. Everything in JIRA required between two and five clicks to do things that Bugzilla let us do in one. Bugzilla’s UI is pretty horrible, if you manage to build something worse then you must have been trying really hard.
I like my manager. We both hate Jira, along with all the people that report to us. But it’s the tool our ‘agile’ people chose, we’re gonna continue on this deathmarch until the next fad replaces agile. We’ve (as in, virtually everyone in my LoB who doesn’t have ‘agile’ in their job title) found the best way to use Jira is to figure out the absolute minimum you have to use Jira so that it looks like you’re using Jira.
I hate JIRA, and I was the manager :) We replaced it with Linear.app, which is fantastic. There are several great alternatives with customizable workflows.
Yes, there are many issue trackers that let you assign tasks to people and change a status - but they don’t allow a customized workflow that can be enforced.
We’re using ye olde Redmine at work. It has exactly this (which is why sometimes I’m frustrated with it - simple tasks require cycling through the statuses to close them, and you can’t reopen them etc, but that’s just how it’s been set up).
Redmine can be a bit challenging and is a bit more “raw” than Jira. It has no pretty kanban boards, burndown charts etc. And it’s starting to feel a bit crusty because it started off as a “better Trac” and essentially maintained the same sort of UI, which worked great for Trac, but with Redmine’s much larger feature set has become… shall we say, suboptimal…. OTOH, it could just be that we’re just collectively holding it wrong.
Redmine, nice, taking me back. One cool thing about Redmine is that it’s open source. That’s not really useful from a project management standpoint, but it is interesting that you can browse the code of a relatively large real world application.
At my current job we have some custom code extending it to make it more usable and also to add some features. I don’t know if that’d be possible/easy if it wasn’t open source. That’s useful from a project management standpoint!
I don’t know, really (I’m not the one working on Redmine). Probably it’s too specific to be useful in general. We’re quite open source-friendly, so if it were generally useful, I’m sure it’d have been contributed!
I deeply feel this post, as an unapologetic Jira-liker. I’ve seen rough issues with performance in their dc product years ago (ones that forced my company to incorrectly use features for years while Atlassian fixed some of the major show-stopping issues for us (when I say show-stopping, I mean 7-8 hour Jira reindexes)), but after those issues were taken care of, it worked great. I love the dependency expression between tickets, which no other ticketing system I’ve used really seems to get right. I think the author is dead-on in that the “problem” with Jira is that it’s too configurable, and that leads to some truly pathological workflows and rules. In this vein, it’s like any power tool, there are plenty of footguns. They’re just different footguns than we’re used to avoiding as engineers.
The most frustrating Jira limitations that I’ve encountered on my jobs haven’t been limitations in Jira itself, but limitations in custom bullshit that consumes or manipulates information from Jira that doesn’t support basic features. At my current job, we can’t use both subtasks and epics, because the tracking they do (via querying Jira) only supports one or the other.
The only frustrating Jira limitation that was truly Jira’s fault was that for awhile, one of the issues that made Jira so slow was the large number of projects we had. The result is that we culled a ton of projects, and instead had mega projects and split them up via components. Again, Atlassian ended up fixing this for us, and once that was done, we could stop using components like projects.
I don’t have any deep love of Atlassian, their business practices, whatever, but ticketing systems outside of Jira just don’t really hold a candle to it.
It’s fair to say I “like” it enough for what it does, but there are many things I hate about it. I could fill a blog post twice as long with what I hate, and there are plenty of websites, blog posts, and now comments here, that do that already.
My point was people need to hate it for the right reasons. There’s a good amount of comments here that are the “right” reasons, and unfortunately there are many comments that miss the point of the article and prove that there’s a blind hatred for JIRA because of how they’ve seen it used.
I’m sure I could manage 25 software engineers at a similar level of experience doing exactly the same task. But a diverse team doing a whole bunch of different stuff is more akin to having a kindergarten kid, a primary student, a high school student, a university student and a PhD to look after all at once.
Given everyone in your team has done preschool, primary school, highschool, university and probably a couple of years experience… and some with a lot more than that.
And none of them would have gotten that far unless self driven and self managing.
…I’m betting highest productivity is achieved at pointing them in the right direction and mostly getting out of their way.
The biggest problem with programmers is they can easily get too narrowly focused on their own tasks to know when they should be looking up and helping someone else.
A bit of “managing by walking around” can be useful for identifying people who are, un-usefully stuck (hint: being stuck is actually usually useful) and suggesting to the right person that they go help.
Highlighting where the goal posts are and providing feedback on where the costs and payoffs are is also useful.
I’m always amazed at how ignorant most engineers are of what really matters to the customer and what really adds to and subtracts from revenue.
I remember a decade or so back we lost our manager, he had resigned to do a startup.
Most productive couple of months ever… only bad side was nobody was assigned to track incoming customer bugs.
Once we woke up to that… things ticked along smoother than ever before or since.
And none of them would have gotten that far unless self driven and self managing.
…I’m betting highest productivity is achieved at pointing them in the right direction and mostly getting out of their way.
That’s rather inconsistent with
I’m always amazed at how ignorant most engineers are of what really matters to the customer and what really adds to and subtracts from revenue.
The latter implies that constant management is necessary to keep developers focused on adding value.
Personally, I think the big difference here is in experience - fresh graduates and junior devs are more likely to get lost in chasing the next shiny thing, whereas seniors are probably more interested in actually adding value. But of course, things are never so black and white…
They are self driven and self managing, but disinterested in things directly out of their purview.
The ability to focus is a prime talent in technology.
So all they need is awareness, an onsite experience with the customer, a face to face chat with customer support, and click Aha! they are on to it.
Techies are always genuinely trying to do the right thing.
In a highly silo’ed company, it’s hard to know what that is.
Solution: Spread that knowledge where it’s needed.
The numbers of times I have asked a line manager “What is my loaded cost?” …and they haven’t a clue.
The number of times I have asked “What is the selling price and the BoM cost of the product?” And get a either blank looks or vague fumbly answers.
Sure B2B is complex and strategic pricing is involved… but unless you have a clue what the base prices are… I argue you aren’t being strategic… you are just being crippled by commission chasing salesman .
I also argue unless I can look up on your website and see what your “Click here buy now price” is, you’re losing business hand over fist. Sure having a salesman in the loop can up-sell etc etc.
But as soon as someone has to fill in the dread “Contact Form” to be plagued forever by spam…. they are not even going to consider your product in the list of possible solutions unless they are already committed to that category of products and are pissed off with the incumbent.
I definitely hate Jira, not my manager. I hate the way it insists on rewriting any links I paste (or anything it thinks is a link). I hate that I can’t hyperlink something that includes monospace formatting. I hate that when I double-click a word in the ticket to highlight it, so I can copy it, it switches to “edit ticket body” mode instead. I hate how some URLs can be command-clicked to open in a background tab, but not all. I hate how if I copy an ID from the middle of a bulleted list line, and paste that into my comment, it starts a new bulleted list with just that number. I hate how it makes over a hundred Ajax requests to load a ticket – and I hate that I know this, because I have been reduced to grovelling around in the dev tools in a futile attempt to get a plaintext version of the ticket body. I hate that this isn’t even an exhaustive list.
Jira consistently gets in my way and slows me down, and provides no escape hatches. It’s definitely the software I swear at the most.
About the edit mode - I particularly hate when I’ve left something in the edit state and forgot to submit it. Getting in the editing mode is automatic but actually submitting the edited text is manual. It’s like the worst of all worlds when it comes to AJAX text manipulation.
I thought of it it as a drafting mode. I sometimes leave tickets semi-edited and come back to them later with more information, and I’m glad they are still in an editing state and no-one watching the ticket has been notified of my half-baked changes. But that does make it more likely that I’ll make changes and forget to finalize the edit.
I don’t think rewriting links is a standard behavior, perhaps your instance has some plugins? Also, field types can be set to be text so they won’t be parsed.
Hyperlinking can be done on pretty much anything if you go into advanced edit mode, which is tedious. But why are you hyperlinking stylized text in a ticketing system? Sounds like you’re using it more like a wiki / documentation repository which is not what it’s for.
Double clicking is an interesting one, and is not a problem unique to JIRA. In general, web applications that allow editing don’t deal with this behavior well. This could also be fixed by not using the “quick edit” node and requiring the edit screen to be used to make changes. Again, a configuration thing that you’re not happy with.
Copying an ID from a bulleted list, again you can use the advanced markup mode if you’re trying to do such detailed editing. But I do agree the WYSIWYG editor leaves a lot to be desired.
As for AJAX requests and load speed, absolutely! This gets into the reasons I hate JIRA too. It’s just patch on top of patch for the last 15 years to add on new features with little value, and a big performance hit.
I’m pretty sure this is a built-in behaviour – where I type “heroku.com” and Jira replaces it with a button that says “Cloud Application Platform | Heroku”. With top level domains this just makes for awkward sentences, but rewriting links often hides relevant information.
A couple of months ago I received a ticket that included EIGHTY FOUR URLs. Some poor soul - maybe the customer, maybe our support staffer – had taken the time and trouble to pull together a comprehensive bug report. But the relevant info is in the URL query parameters. Which I can’t see, because Jira has rewritten them to 84 identical
<title>tags. Copying the comment body gives me the visible text, not the underlying links. Clicking through is hard, because every item in the list looks the same and I worry I’ll lose my place.At no point do I feel like Jira’s helped me investigate, or made my life easier.
I’m hyperlinking stylised text because I am trying to be helpful to my colleagues. I’m trying to communicate clearly, and let them follow a linear route which I had to pull together. For instance: “I’ve tracked the error from this
POSTrequest to theHatsController#create_requestaction, but I haven’t figured out the underlying cause yet.”All I want is the same expressive capacity that Markdown provides, and not have to contort my writing to fit Jira’s arbitrary formatting restrictions.
The last time I checked, Atlassian’s wiki doesn’t support hyperlinking monospaced text either.
This really isn’t detailed editing. The ticket body will say “Customer reports they can’t see detailed information on these three dinguses:” followed by a bulleted list. Using copy-paste to prepare my reply – “Dingus IDs 582023875 and 582032442 are working as designed, as they have the ‘hide detailed information’ flag set, but I can replicate the problem with 58214432” – gets me into a fight with a text box.
Thank you for the detailed response. I spent some time checking the items you’ve pointed out and it looks like these are cloud “improvements”. On my server version, URLs are not automatically converted into buttons with site descriptions. Something like “heroku.com” doesn’t even get highlighted as a link, whereas “https://www.heroku.com” gets the browsers default styling for a link.
And for monospaced text, it works fine with the WYSIWYG editor (on server), so probably another cloud “improvement”.
It sounds like that one feature is causing you a lot of pain, and these kind of cloud “improvements” are definitely one of the reasons I hate JIRA. Someone decided we all want links auto-scraped for site descriptions into fancy buttons - in an issue tracking system, and every cloud customer gets that whether they like it or not.
I hadn’t really paid attention, but yeah, my Jira is doing this. I found this out:
If I type
heroku.comit gets turned into a regular text link without any changes. If I highlightherokuand pasteheroku.comfrom my clipboard it does get turned into a button-link that says “Cloud Application Platform | Heroku”. If I think hit Cmd+Z (undo) on Mac the button is removed and it’s just a regular text link again.So if this is annoying you and there’s no way to turn it off in your Jira settings (I have no idea) you can perhaps at least use undo to get rid of the link “enhancement”.
No, I definitely hate JIRA for catering to and enabling exactly these kinds of workflows.
… and also for being slow.
… and buggy. Last time I had to use Jira there were half a dozen bugs that really got in the way. Like the formatting language being completely different depending on the screen at which you started editing a ticket, and the automatic conversion from one formatting language to the other being broken so that occasionally, even if you did everything right, sometimes your ticket would end up with piles of doubly escaped garbage instead of formatting. This wasn’t an extension, this was core Jira. Though I suspect that particular issue is fixed now.
Are you on a cloud instance or self-hosted server? I’ve seen both be slow, but self-hosted is usually the worst IMO (under-specced or poorly-configured hardware, I would guess).
Yeah, I’ve experienced slowness with both. Even with self-hosted and throwing oversized hardware at it, it still tends to be quite slow (albeit a little faster than cloud hosted).
Do you also hate the processors that run the instructions to make it possible?
If the feature set of the processor was driven by the sales team trying to make every last sale and meet every requirement no matter how weird, and the engineering team didn’t have a say in how it was designed, yeah I probably would!
I mean, if you put it like that, yeah I do kinda hate modern x86_64 CPUs for those same reasons.
They’ve been trying, for sales reasons, to meet the increasingly ridiculous requirement “more single-thread performance for the same old instructions”. And this has driven them to make increasingly dangerous engineering decisions, resulting in the slew of CPU vulnerabilities we’ve seen, along with mitigations for them that undo most of the performance wins.
I’d say that ties into my reasons for disliking it too. I think many of the “features” added were just to get more sales, no matter how it crippled other things that were working just fine. Meanwhile, highly requested features go unimplemented for years because Atlassian doesn’t think it’ll make them more money.
I’m fully capable of hating two things at the same time.
Just kidding, I like my manager. And Jira got less painful with jira-cli.
thanks for the tip on jjira-cli - i’m tired of Jira causing firefox to leak so much memory with their laggy UI that I have to restart my browser twice a week. i’ll have to give this a spin
Yeah, I also found it really hard to use it without a mouse, which I don’t have for disability reasons, and somehow I could never internalise the navigation tructure.
So the aforementioned “pain” was literal physical pain, due to having to use keyboard mouse keys in many places on Jira, while trying to find my way. Much easier with cli and some aliases.
Great tip. Also, like other issue trackers, you can use chat or code repository integrations to remove the need to open JIRA at all.
Some counterpoints: I fucking hate Jira
And my $0.02: Plain Jira with mostly default configuration (no “fancy” over-engineered workflows, no “fancy” issue types with multiple custom fields etc) is a pain, too. Multiple times I’ve found myself writing some Python script utilizing their API to get something done in a more efficient and (power)user-friendly way, than through their bloated web interface.
But the main problem I have with Jira is how easy is to hide information by for example, only reviewing a dashboard where tasks with a label or belonging to current sprint are shown. A few days back I wrote a little (8-10 lines) Python/Flask script for locally-run backend calling Atlassian’s API, with HTML+JS parsing JSON response. Boom - we missed a kinda crucial task because someone forgot to slap a label or mark it for current sprint. And as people’s “Your work” lists are growing, they forget backlog items in the constant flow of new feature requests and overall startup dynamics. One fairly simple change to Jira defaults and things not shown on a dashboard are being forgot.
I hate Jira even though my manager haven’t toyed with it much. It’s way too easy to break if one doesn’t have Ph.D in Jira.
I have personally found the “Assigned To Me Gadget”, available for Jira’s dashboards, quite useful. It allows me to always have an overview of the tickets I am set to work on. I do push to have a small list of issues assigned to me at any point, which might also help with maintaining an overview of the scheduled work.
I wonder if your point also falls under “management issues”, alluded by @djx: is the Backlog section properly used? What are backlog tickets supposed to be exactly? My interpretation is that such tickets are expected to be scheduled, but not resolved in the immediate future; from what I have noted, my interpretation does not appear to be shared, and Backlog tends to end up being the “storage room” for ticket; while I can appreciate the value in not deleting tickets, since they were added for a reason, product priorities, and available resources do appear to facilitate an overlarge backlog. My stance is that such tickets belong in an “Idea Pool”, or similar, before being consciously moved elsewhere.
Love that site, thanks for a good laugh :)
Decent writeup. A couple additional/complimentary points:
I look forward to the day I get to use a different tool, but Jira has enough of the stuff I care about and I know that if I leave a team with it they won’t have trouble maintaining it or keeping it around.
I love the idea of the mini-log/work log on the ticket, I am assuming that it is left as a ticket comment ? Can you add a bit of detail? Does the team appreciate it? It is something that I do for myself but I’ve never thought about asking others to do.
Basically something like:
Anybody who inherits the ticket should get a good timeline of how the work progressed, what surprises showed up if any, and basically be able to retrace the steps efficiently if they get assigned the ticket. The actual comments (the examples I gave above are deliberately terser than I’d expect, mostly) should always be read when inheriting the ticket or doing code review.
For tickets about bugs, I also want to see the reproduction of the problem, a creation of a working theory for how the bug happens, and then the confirmation of that theory, and then the fix.
Also, tickets without AC should be kicked back before people work on them, but that’s a different set of gripes.
I’m glad to hear it confirmed this isn’t just me missing something. Last time I used Jira, I was baffled by how much expressivity it had for these links (arguably too much, at least in the workflows we were using) and yet how nobody in the whole organization ever seemed to get even the tiniest bit of value from it.
I mostly agree with this article in that most of the time when I see people griping about Jira, they’re actually griping about their organization’s workflow. It is totally possible to use Jira to keep track of a lightweight workflow; my team uses it that way and I find it a net positive for both my personal productivity and my team’s productivity.
But it’s not as big a positive as I’d like. The software is obnoxious and full of blatant usability problems that remain unaddressed for years on end. It’s not the worst offender I have to deal with in my day job (that’d be AWS QuickSight, whose UI is so abominable and user-hostile it’s almost impressive) but Jira never rises above the level of “tolerable” for me, which is a shame considering how often I need to use it.
For a little while my team was using ClickUp. It had its share of annoyances and limitations too but I found it more pleasant to work with. Jira was imposed on us from above, and it didn’t seem like a hill worth dying on, but I wouldn’t say no to switching back.
FreeBSD evaluated JIRA when we moved our bug tracker away from GNATS. We rejected it for a few reasons but primarily because doing anything in JIRA required clicking through twice as many things as the second worst option, for the same workflow. Any time I’ve had to use JIRA, it’s been the same experience: I need to interact with the tool far more than I should and moving to the same workflow in any other tool has been an improvement. It’s pretty safe to say I hate JIRA.
For our use case, we rely heavily on the custom workflows. Think manufacturing, with thousands of tasks per week for hundreds of people.
I really liked ClickUp, but the workflows just aren’t robust enough. Many of the issue trackers that claim to have “custom workflows” are nothing more than a decision table based on status.
If we didn’t need to ensure a specific flow was followed, we would have picked something else a long time ago.
I completely agree with most of what is said here. Except, Clickup. Having had the move from JIRA to click imposed on us. Wow. I am in awe of clickup. It’s pure genius. Give users enough rope to hang themselves, then charge organisations consultancy time to fix the issues. Except. The consultants don’t fix the issues they just give everyone “homework” which is coming up with ideas on how to fix issues.
Truly a golden goose.
It’s easy to be glib and say “no it’s definitely jira that I hate”. I’ve used many systems, and I think jira is unpleasant and I think that it’s jira that is at fault, but this article basically goes out of its way to blame shift.
There are numerical us examples of things that people dislike about jira in the article, and every one is given a different scapegoat, to the extent it almost feels like a no-true-Scotsman defense of jira.
The reality is that even if jira does have a “good” setup, it’s clear that the defaults aren’t good, and it’s trivial to make it worse.
Hence: I hate jira
The article is definitely intended to polarize people, and hopefully make them think critically about their problems. It’s stated as an absolute, and absolutes are always wrong ;)
At the end of the day, there’s always the reasoning that you actually hate your manager because they’re the one who decided to use JIRA…
Google Docs, Office365, Zoom, Slack – all of them react instantly to my input. They feel like well-designed tools.
In JIRA I could go have a cup of coffee sometimes while waiting for a text form to save. I don’t even understand how that’s possible, with 2023-level computing power and relatively simple data fields. It’s like trying to chop down a tree with a saw made of cardboard.
I consider Slack pretty slow and tedious to use (measure the time it takes between your click on a channel and its content showing up,) but Jira is undeniably on another level of pain.
I suppose the right way to put it is that JIRA makes Slack feel fast by comparison.
To be honest, the “right way” to use Slack for me is to use Ctrl-K and Ctrl-F almost only and the Unread and Threads (I wish those could be merged) and Basta. 90% of the time, I don’t click on anything and just jump from channels to unreads and pm and etc.
Yeah, I’ve never been able to get accustomed to the keyboard-only workflow. Maybe if my setup forced me to not use the mouse, but it’s just too damn convenient of an input device for me to even consider dropping it.
But I do still feel a significant delay between clicking the search box and the input box appearing, so I assume it’s the same with Ctrl+K. Opening any window in Slack just likes to take ~300ms for some reason.
Oh I do use my mouse for scrolling/emoji reaction etc. But I just don’t want to use that sidebar of doom with hundreds of channels (triaged by section) ever 😅 So Ctrl-K provide me a kind of command pallette to move around via keyboard.
Re. this section:
What I’ve seen more often is devs who want more autonomy, and (project/product/people) managers who want their devs to work on what they (or the team as a whole) have decided is the right thing to work on right now, and to focus on that and get it done.
I think that (generally!) the right thing to do as a dev is not to hide their activity (working on what they see as actually important) but make the case for the business value of their work and switch teams or companies if they just can’t agree.
Just to provide a counterpoint to the comments here: our team of 20 has been using JIRA for over 10 years and we’re still happy with it.
Jira is designed to assist with micromanagement. It empowers a level of analytics and process that has nothing to do with assisting me, the person doing the work. It always becomes, at every job I’ve used it at, a tool for talking about the flowchart of work vs talking about the work.
Trello, for the years I used it, was designed for me, the person doing the work. The idea was I could get in there quickly, write down an update or move a status and then leave again. It didn’t have tags and assignee and group and status and tshirt size and all the other work management fads in a giant toolbar to the right of my screen. I had the work, a checklist of the work, a due date for the work and a place for people to discuss the work.
But because it doesn’t empower that layer of bureaucracy above me to generate charts and tags and kick off automation to move the tickets through this 1950s style factory, it can’t really compete.
At my previous job, I didn’t fine Jira to be that bad. Slow, yes, but otherwise, once I got things set up for our team, it was okay. At that time, each team had its own queue, and you could link tickets across team queues. Then new management came in, and insisted on everything being done in just one queue. So there went our work flow (ten years, on time, on budget, best vendor for our customer [1], only two roll backs during deployment to production) and the new flow forced on us make Jira painful to use (took less than a year for us to be chronically late, repeated deployments because we couldn’t do them right, lose our preferred vendor status and I’m surprised we still have our customer [1]). So I think it really comes down to how Jira is used.
[1] The Oligarchic Cell Phone Company
I agree - at my previous job we used Jira and it wasn’t horrible. In the end we switched away from it (in favor of Phabricator, which I eventually learned to.. not hate) because indeed it was too slow, and the pricing curve way too steep. There’s a step from 10 to 100 users where the price increase is so dramatic that it’s basically a nonstarter for smallish companies of just over 10 people.
No, no, I really do hate JIRA, I assure you.
It is vastly overcomplicated for the relatively simple sort of task it has to do. If an organisation’s workflows are so complicated that they need such a complicated tool to manage them, then the real problem is the workflows and they ought to resolve and simplify those, not adopt such a horrible tool to attempt to track them.
Conway’s law applies in spades here: complex organisational structures produce complex software.
Be more grug. Be grug brained. Make software grug understand.
I think you’ve summarized a lot of the points in the article, but your first statement is that you disagree :). If the wrong tool has been selected for your organization’s use case, then you should probably hate on the person who selected that tool rather than the tool itself.
If you have simple tasks, then you should be using a simple tool and not the complex configuration JIRA can do. But even with JIRA out of the box you get tasks that have 3 statuses and can be dragged between columns on a kanban board. It doesn’t get much simpler than that.
Heh. :-) OK!
Does anyone have a bug tracker they like?
I like GitHub issues a lot.
Prior to that, I found FogBugz pretty good.
The key thing with GitHub issues is that they allow but don’t enforce process. JIRA is set up with a particular workflow but a single workflow is rarely appropriate for more than 90% of tickets. You then end up fighting the system for the other 10% or you keep adding more complex flows to account for the long tail until no one understands the full process at all.
With GitHub issues, you either follow the process or you don’t. It’s up to you, and you’re an adult who is trusted to make decisions. Perhaps there’s a bit of truth in the article: if your manager chooses JIRA then they’re saying that they don’t trust their team to make judgement calls, so you probably do hate them.
I think Linear does it right.
From a pure user perspective, I enjoy using Trac for CHICKEN. It fits our small project quite well. I’ve also used it at my first job, and found it quite neat and easy to use. Our customer also never complained.
I don’t think it would suffice for larger companies, as it misses a lot of features that managers would probably want. But for simple project tracking, it’s perfect.
From an admin standpoint, I’m less happy with it. Recently we had some technical trouble where it would slow down and eventually report an error because the sqlite database would get locked (but only when logged in). This turned out to be caused by some obscure bug crashing during after-request cleanup in the session expiry code, causing us to accrete loads of dead sessions, leading to the db locked issue. Also, the project seems to be pretty much dead. For example, their ticket for releasing the next release has been open for 3 years (it’s an embarrassing read with multiple pledges like “I’ll get it done this weekend”). This release is essential, because it’s the first release to properly support Python 3. AFAICT, not supporting Python 3 is the reason the package has disappeared from Debian (it’s only available in oldoldstable right now).
Linear. It’s such a joy to use and I miss it dearly from my previous org.
We used Shortcut.com (clubhouse at the time) at my last job and I liked it quite a bit.
We used and quite enjoyed Height. It’s really light weight / fast and very flexible. https://height.app
Apart from Jira, I’ve only really used Github issues or sourcehut’s pleasantly-minimal knockoff of it. I like both quite well.
Oh, I’ve also used Trello and other kanban-y systems but I find for small projects or many small tasks they’re not worth the shuffling for me. Their value is really when you have a pipeline with multiple people doing multiple things that may take a long time or have high latencies. Physical engineers working on a pipeline of design -> fabricate -> finish -> test, for example. When the same person is doing all those steps, then having them separated doesn’t add a lot of value imo.
The issue-tracking built into Github and Gitlab has worked perfectly fine from my perspective as a developer working on projects hosted on both git forges. Apart from the fundamentally-ideological concern that Gitlab is in principle self-hostable and Github is not, I don’t even have a strong preference for one system over the other, they both seem perfectly fine for what I’ve had to use them for.
I specifically hate Jira for being an unbearably slow piece of crap. When my work is regularly interrupted by a 30 second long wait for a shitty web page to load. I hate how all the different widgets jump around while the site loads. I hate how slow it feels to navigate around to find what I need. That sort of stuff, every day, causes feelings of resentment.
Luckily, we only used Jira briefly many years ago. We’re now using Linear, which is much more pleasant to use IMO. I can just get in and do what I want to do and get on with my day, no more waiting for 10 different UI components to separately show spinners as they wait for data from the back-end, where each completes at a different time and jumps around as they do.
If it’s taking 30 seconds to load, it’s not JIRA. It’s your web server, customizations, network speed, or something else. This has to do with how it’s configured.
It’s 15 seconds for a cold load, here, and it doesn’t happen to other sites. Tell me, is Jira a schlemiel or a schlemazzel?
I believe we were using hosted Jira.
That probably has a lot to do with it then - and there isn’t much you can do about how Atlassian has set up their data centers, where they choose to host your site, and what they consider acceptable performance. Did I mention that I hate “the cloud”?”
For us, we’ve always ran it on-premise so we can connect it to internal systems we don’t want to expose over the internet. Apparently, the speed improvement was an unexpected benefit.
For a team that doesn’t care as much about their IP, has simple workflows, and doesn’t use the issue tracker enough to dedicate some admin time to - there are definitely better options.
My manager isn’t the one that takes 30 seconds to become responsive when i load the page, sorry. He also isn’t the one whose dogshit editor insists on doing the Wrong Thing™ with formatting any time I am trying to do something “fancy” like “have italics” or “add some code to a comment”.
My workflow and manager are fine – it’s the UI and UX of this specific tool that sucks complete ass. Every other issue tracker I have ever used has managed to be less slow, and fuck up less, than JIRA does. It just plain fucking stinks to use.
On one hand, Jira is a Taylorist dream. On the other hand, I can’t even see velocity values for individual people in vanilla Jira. So it really doesn’t even some of the most basic features.
I’ve found JIRA to be a excellent Vulnerability and Bug Tracker until we lost full admin rights due to the size of the business and that is when JIRA became unusable. JIRA’s IAM makes it near impossible to both have a secure instance and one that can be modified to suit the needs of each team. We couldn’t change workflows or add new tags or properties without reaching out to a JIRA admin and we ended up having to reuse workflows that weren’t created for us but that sort of looked like what we needed. We also found that other teams were using our special properties which would break our dashboards. It was a mess. I believe the only way to make it work in big enterprises is to have several instances (At least one per team) but then that breaks things like tracking issues across teams.
I found it hard not to stop reading at this point — it’s a perfect distilation of what I dislike about Jira. Those aren’t features I need or want as a developer trying to get work done as part of a small team, and Jira’s excessive flexibility and customisation makes it a much worse product for the “simple” use cases.
Workflows in specific are something I don’t want my task tracking tools to handle as they’re incapable of handling the nuance, flexibility, or vaugeness real-world processes actually have. I’m sure there are processes Jira is very well suited for, but it’s not the general purpose tool it’s presented as.
I’m sorry this was such a show stopper for you. It’s understandable that you don’t feel you need workflows, but it doesn’t make it less of a good tool.
I assure you it can handle very complex and custom workflows, if you put the time in to configure it properly.
Lots of teams at my work are ditching Atlassian before the new pricing changes: next February, they will no longer support “server products” and you will have to buy a “data center” license instead. That’s a minimum fee of $50,000/year for JIRA and Confluence.
I predict an uptick in GitLab users.
I think the comments all agree: yes we hate JIRA.
For me it’s the terrible UI:
It basically does everything the most basic UX designer teacher will tell you to avoid.
That was basically my reaction when we evaluated it for FreeBSD. We had advocates of each system configure a demo system for us to test. They were all implementing the same workflow. Everything in JIRA required between two and five clicks to do things that Bugzilla let us do in one. Bugzilla’s UI is pretty horrible, if you manage to build something worse then you must have been trying really hard.
I like my manager. We both hate Jira, along with all the people that report to us. But it’s the tool our ‘agile’ people chose, we’re gonna continue on this deathmarch until the next fad replaces agile. We’ve (as in, virtually everyone in my LoB who doesn’t have ‘agile’ in their job title) found the best way to use Jira is to figure out the absolute minimum you have to use Jira so that it looks like you’re using Jira.
I hate JIRA, and I was the manager :) We replaced it with Linear.app, which is fantastic. There are several great alternatives with customizable workflows.
We’re using ye olde Redmine at work. It has exactly this (which is why sometimes I’m frustrated with it - simple tasks require cycling through the statuses to close them, and you can’t reopen them etc, but that’s just how it’s been set up).
Redmine can be a bit challenging and is a bit more “raw” than Jira. It has no pretty kanban boards, burndown charts etc. And it’s starting to feel a bit crusty because it started off as a “better Trac” and essentially maintained the same sort of UI, which worked great for Trac, but with Redmine’s much larger feature set has become… shall we say, suboptimal…. OTOH, it could just be that we’re just collectively holding it wrong.
Redmine, nice, taking me back. One cool thing about Redmine is that it’s open source. That’s not really useful from a project management standpoint, but it is interesting that you can browse the code of a relatively large real world application.
At my current job we have some custom code extending it to make it more usable and also to add some features. I don’t know if that’d be possible/easy if it wasn’t open source. That’s useful from a project management standpoint!
Have you contributed that back? Because improving Redmine would be good for a lot of people.
I don’t know, really (I’m not the one working on Redmine). Probably it’s too specific to be useful in general. We’re quite open source-friendly, so if it were generally useful, I’m sure it’d have been contributed!
Why only hate one of them? I can totally hate both if I want so :-)
However, when it comes to Jira, my hate is pretty much guaranteed. With my manager, not so much.
I deeply feel this post, as an unapologetic Jira-liker. I’ve seen rough issues with performance in their dc product years ago (ones that forced my company to incorrectly use features for years while Atlassian fixed some of the major show-stopping issues for us (when I say show-stopping, I mean 7-8 hour Jira reindexes)), but after those issues were taken care of, it worked great. I love the dependency expression between tickets, which no other ticketing system I’ve used really seems to get right. I think the author is dead-on in that the “problem” with Jira is that it’s too configurable, and that leads to some truly pathological workflows and rules. In this vein, it’s like any power tool, there are plenty of footguns. They’re just different footguns than we’re used to avoiding as engineers.
The most frustrating Jira limitations that I’ve encountered on my jobs haven’t been limitations in Jira itself, but limitations in custom bullshit that consumes or manipulates information from Jira that doesn’t support basic features. At my current job, we can’t use both subtasks and epics, because the tracking they do (via querying Jira) only supports one or the other.
The only frustrating Jira limitation that was truly Jira’s fault was that for awhile, one of the issues that made Jira so slow was the large number of projects we had. The result is that we culled a ton of projects, and instead had mega projects and split them up via components. Again, Atlassian ended up fixing this for us, and once that was done, we could stop using components like projects.
I don’t have any deep love of Atlassian, their business practices, whatever, but ticketing systems outside of Jira just don’t really hold a candle to it.
It’s fair to say I “like” it enough for what it does, but there are many things I hate about it. I could fill a blog post twice as long with what I hate, and there are plenty of websites, blog posts, and now comments here, that do that already.
My point was people need to hate it for the right reasons. There’s a good amount of comments here that are the “right” reasons, and unfortunately there are many comments that miss the point of the article and prove that there’s a blind hatred for JIRA because of how they’ve seen it used.
[Comment removed by author]
Replace “USA” in this search with your country.
https://www.google.com/search?q=average+primary+school+class+size+usa
https://www.google.com/search?q=average+line+reports+team+lead
You need look no further.
I’m not sure of the point?
I’m sure I could manage 25 software engineers at a similar level of experience doing exactly the same task. But a diverse team doing a whole bunch of different stuff is more akin to having a kindergarten kid, a primary student, a high school student, a university student and a PhD to look after all at once.
Given everyone in your team has done preschool, primary school, highschool, university and probably a couple of years experience… and some with a lot more than that.
And none of them would have gotten that far unless self driven and self managing.
…I’m betting highest productivity is achieved at pointing them in the right direction and mostly getting out of their way.
The biggest problem with programmers is they can easily get too narrowly focused on their own tasks to know when they should be looking up and helping someone else.
A bit of “managing by walking around” can be useful for identifying people who are, un-usefully stuck (hint: being stuck is actually usually useful) and suggesting to the right person that they go help.
Highlighting where the goal posts are and providing feedback on where the costs and payoffs are is also useful.
I’m always amazed at how ignorant most engineers are of what really matters to the customer and what really adds to and subtracts from revenue.
I remember a decade or so back we lost our manager, he had resigned to do a startup.
Most productive couple of months ever… only bad side was nobody was assigned to track incoming customer bugs.
Once we woke up to that… things ticked along smoother than ever before or since.
That’s rather inconsistent with
The latter implies that constant management is necessary to keep developers focused on adding value.
Personally, I think the big difference here is in experience - fresh graduates and junior devs are more likely to get lost in chasing the next shiny thing, whereas seniors are probably more interested in actually adding value. But of course, things are never so black and white…
They are self driven and self managing, but disinterested in things directly out of their purview.
The ability to focus is a prime talent in technology.
So all they need is awareness, an onsite experience with the customer, a face to face chat with customer support, and click Aha! they are on to it.
Techies are always genuinely trying to do the right thing.
In a highly silo’ed company, it’s hard to know what that is.
Solution: Spread that knowledge where it’s needed.
The numbers of times I have asked a line manager “What is my loaded cost?” …and they haven’t a clue.
The number of times I have asked “What is the selling price and the BoM cost of the product?” And get a either blank looks or vague fumbly answers.
Sure B2B is complex and strategic pricing is involved… but unless you have a clue what the base prices are… I argue you aren’t being strategic… you are just being crippled by commission chasing salesman .
I also argue unless I can look up on your website and see what your “Click here buy now price” is, you’re losing business hand over fist. Sure having a salesman in the loop can up-sell etc etc.
But as soon as someone has to fill in the dread “Contact Form” to be plagued forever by spam…. they are not even going to consider your product in the list of possible solutions unless they are already committed to that category of products and are pissed off with the incumbent.