Several years back, before Jira became the software everyone loves to hate, I worked at a smallish company where the engineers had brought up local Jira instance as a sort of skunkworks project, because the bug-tracking tool the company had been using wasn't working for them. They set it up to fulfill the basic need for programmers on a team to keep track of their work.
Fast forward a couple of years and it had become the company standard, replacing whatever preceded it, and the company had at least doubled in number of employees. The Jira workflows and ticket fields got the "corporate standard" makeover, including adding a field with so many values that alone it accounted for much of the increasingly poor performance.
The arguments the author makes here encapsulate the evolution at my then-employer. Everything became about using an enforced process and workflow. The worst part about it was how some of the changes were enforced on all projects from the top down, meaning teams (like mine) that had a reasonably good, workable project setup had to change the way we did things, use different terms, and generally give up the working style that made use successful.
Some time later, much to my chagrin, I ended up consulting at a company using something even worse than Jira: + Azure DevOps, Azure Boards, and all things Azure. These were coupled with the micromanagement and non-manager anti-patterns described in this article into a situation where developers spent more time pushing buttons and shuffling tickets arounds than writing code. The engineering manager made it clear how, to her, seeing tickets moving through the workflow on the board, on schedule was as important as working code.
No, I love my current manager, and really despise Jira. It’s slow, bloated, and tries to solve every project management problem and ends up solving almost none of them well.
someone on here a few years back said "You dont hate Jira. You hate that it's a mirror". It meant that Jira just reflects whatever your busines management policies are and I think there is some truth in it.
Nah. I hate how long it takes to load different pages. I hate the UI and how there's a bazillion non-removable fields that don't need to be filled in, but are present. I hate that you can't click on links inside Jira, but almost every real thing is actually a link, so that's unhelpful. I hate how it automagically saves changes.
I used to get snotty comments from people opining about how awful Perl was and how great python etc was.
The funny thing when it was time to get something done, I’d be finished by the time they hacked together whatever python dependency shitshow they were buried in.
Perl’s time is in the past, but I wrote a ton of it, and some is still running in production in a few places 20+ years later.
I hate all software that isn’t a mirror. And yet none of it can be.
I’ve never used Jira but every task or list program that I’ve used does not reflect me and to do it I would have to manage it constantly.
It doesn’t reflect the context switching I do, or all the communication I do outside it to make it work, or my notes on how I’m going to do a thing… rarely is it accurate on my time and so on.
Management _loves_ to observe and analyze tickets to death. They think that's their entire job.
This is why they buy JIRA. It lets them sit back and look at charts of BS points, BS tags with little to no understanding of what the work actually means. They don't buy JIRA because it helps engineering. They couldn't care less that it takes so much of engineering time.
Which leads to why engineering hates management. Because management doesn't care about engineers, why should engineers care about managers?
And when they don't reveal transparently what they use to measure, engineers feel the gaslight burning and stop complying. Then manager asks, "What's wrong?"
But it uncritically swallows the idea that the only way to have reasonable transparency is through atomizing work into trackable to-do items. I do successful work of all kinds with clients and collaborators and never come near a Jira.
It's a 'remembering' tool - but 'forgetting' is also a valid and productive activity. Some things should be remembered, e.g. important bugs, but other things quite often benefit from being forgotten, like irrelevant feature requests.
It is surprising how many problems can be solved by simply ignoring them - the trick of course is knowing which ones to ignore. To-do lists tend to preclude this strategy entirely though.
This is a keen observation and 100% true. A lot of people (both engineers and managers) willingly align behind this regime because the system gives them ostensible clarity on what they need to do, and a paper trail to show how hard they've been working as air cover if anything goes wrong. They are optimizing for comfort and covering their own asses.
Unfortunately, this puts a very low ceiling on the type of problems that can be solved. In fact, it works against creative problem solving because it obfuscates the big picture by drowning out the strategic summaries and narratives needed at different zoom levels for different stakeholders. The devil is in the details, and the only way to get the details right is to have real expertise and collaboration based on higher level understanding. Ideally every individual involved has the highest level goal they are capable of executing on, and is empowered to work out the details collaboratively with whoever needs to be involved. This is easier said than done, because most people—even experts in specific domains and skillsets—are not experts in collaboration and understanding other people's mental models. Management's job, if they are doing it correctly, is to understand these dynamics (hopefully rooted in deep hands-on expertise) and to set up the structure that facilitates the necessary collaboration.
Useful tooling for this problem is context specific, but less is usually more nuanced messaging or vision doesn't travel or align well across large groups of people. Jira does nothing to help with this; it's just not built for strategic planning or collaboration. It shines for tracking a huge influx of unrelated tasks that have to be passed around between silo'ed teams without dropping any balls. This allows project managers and operations folks to monitor things mechanically where the problem and process is already well understood. It offers very little to support higher-level problem solving.
First time I used Jira I was lucky that the company had it setup quite nicely. I really enjoyed it.
One of the things I really enjoy about Jira is the fact that a task and a sub-task have the exact same UI. A sub-task can be easily moved to be a full task and vice versa.
"Hey this PROJ-1234 task is in fact a subtask of PROJ-1111!"
"Agreed! let's move it to be a subtask of PROJ-1111! and here's a new PROJ-1235 for the second part, let's make it a subtask as well"
"Wait, I can't make PROJ-1234 a subtask of PROJ-1111..."
"Ah, I see, PROJ-1111 is already a subtask of PROJ-1002, which indeed makes sense"
"Oh, right! I forgot subtasks can't be nested. So maybe PROJ-1002 is an epic?"
"Sounds about right! Oh wait, PROJ-1002 is part of epic PROJ-223"
"Oh. I get it now, forgot about that epic which tracks things for product item foo"
"Alright, is foo still on track and required?"
"Yeah, it's merely been postponed because the currently worked on project item bar was priorised as we needed a bit more work to refactor and complete foo"
"So now we're set to do PROJ-1234 in the current sprint, and this would complete both foo and bar, two birds one stone!"
"Yeah that was the plan all along, having the design lend itself to that, with proper composition and all."
"But we can't make it part of both epics"
"Correct."
"What if we create a new task and link it with PROJ-1234"
"Could work. How do we qualify it though? It's "duplicated by" but we keep that for duplicate bug reports as there are automated workflows for it, notably a duplicate is supposed to be closed."
"Blocked by maybe?"
"Well it's kind of bidirectional and blocked by is one direction only"
"Drat there's no "Linked to" in the combo box"
"Yeah management wants everything qualified so that they can build reports. IIRC they don't scope it by kind "bug" because marking some tasks as bugs biases another counter, so some bugs stay as tasks, so they can count only bugs reported by customers and not internal bugs"
"Oh right, doubles down on why we can't use duplicate, we'd break the report. Actually I think we can't use the link feature at all because it's really the same task and that'd break their report too"
"Screw it let's just put a link on each one's description to the other. I'll shoot an email to the JIRA admin to see if we can add more link kinds, and maybe fix the automations and reports"
"Yeah, we're already overtime for that sprint planning anyway. Let's move."
"Should we do that at the PROJ-1234 level or at the PROJ-1111 level?"
"Not too sure. Maybe we should have used a checklist for PROJ-1111"
"But then PROJ-1478 depends on PROJ-1234 only, not PROJ-1111 as a whole"
"Ah, right. Maybe we cleaned up the arch a bit too much lol"
"Right? Maybe we should switch to an arch that matches how we can link tickets lolsob"
"JDD: JIRA driven development"
"Hold my beer while I write a JIRA plugin to export task structure as a code scaffold"
"Kill me right now"
"Goddammit time flies, let's finish this. So where are we on PROJ-1526?"
"Blocked, we're waiting on feedback from the user"
"Alright. Wait, there are two "Waiting on customer" statuses now? Which one is it?"
"Huh. Let me look at the browser inspector... Ok, id 17, so I think it's the second one. No idea where the other one comes from."
"Ha. Ok, moving on."
Slack pings
> Hey, meeting xyz has started 10min ago, are you joining?
In the majority of my consulting engagements, the client is using Jira. I don't think the permissions for my account have ever been right on the first day.
Between every PM, every manager, etc, everyone wants to track slightly different information. The ICs can't keep up - they have five people telling them to use Jira just a little bit differently. The bosses/PMs don't feel this tension, they see only their asks, their report they want to stay up to date, they wonder why its so hard. Eventually, ICs see it as confusing hassle (like TPS reports in Office Space). ICs don't know what to do, and everyone gets confused, information doesn't actually surface in Jira, real issues get dropped on the floor, etc etc
The problem isn't that any one of those bits of reporting is wrong. It's actually that the higher levels need to realize they're actually asking for different / conflicting / excessive information and need to have a stronger hand in reducing information reported so to ensure that which is there is actually accurate.
(The insane configurability of Jira and other PM tools just reflects this chaos)
I don't hate jira or my manager. I do dislike the misapplication of jira as a tool to problems by rote, and I dislike some of the consequences my manager accepts to achieve his KPIs.
Managers and Jira have their place. It depends on context and scale of problem amongst other things.
I can imagine a tool like jira helping prevent a space shuttle disaster, and I can imagine a tool like jira not preventing it. I can imagine a manager preventing, and not preventing a doomed launch.
I can imagine a 2D grid of jria and no jira, manager and no manager and every single square can have "maybe, maybe not" inside it.
I encouraged our IT team to try Trello (now owned by the same company, Atlassian) which sports a JIRA integration[0]. Either due to the fundamental limitations of the integration or a botched setup, it's useless. There seems to be two copies of each ticket (one JIRA, one Trello) that can be in different states. It was not just another UI for the same underlying data.
I do hate JIRA. JIRA adds all the beauty of a government bureaucracy to what should be post-it note management. It's hard to overstate how demotivating JIRA is to my work and especially to my planning. Worse, everyone in the organization has to use it.
I miss Trello sometimes. The Atlassian merger killed most of its old spark, and on top of that the micro-managers of Jira at my company wound up eating my old Trello account (because Atlassian decided to merge accounts on email address, which was dumb) destroying a lot of data in the process, and then decided to turn off Trello entirely (and block it).
I'm much more of a Kanban sort. Jira is awful at Kanban. Trello was great.
We migrated some of our Trello boards to Microsoft Planner (inside Teams), which is a laughable joke. Then eventually to Jira because Jira is an inescapable black hole and "oversight" from the micro-managers matters more than getting projects done on time.
A ticket for each bug or new feature, with commentary including images and videos as necessary, linking to consequent code commits, with a not-done/under-review/complete status field, raised by the reporter, assigned to the responsible person, and indicating the target release.
That is the essence of a good workflow tool, and Jira will do it fine. It is all the extra stuff that seems to cause the grief.
But at other companies I’ve been at, it’s not a productivity tool. It’s a management too.
Estimates for planning. Which is fine. Until pointless rules appear. We’ll use standard story points. But not 1, that’s too small. So things start at 2. But after a while that’s too small. So they start at 3. But you can’t go over 8, past that they have to be split. And you shouldn’t probably use 8 anyway. Pretty soon everything will be 5s. No matter how big or small. Good thing we point.
And of course the whole point of pointing is to put things in sprints. That’s fine. But then the rules come. You can’t go over your capacity. You can’t go below your capacity. You have to roll over everything you didn’t do. You can’t roll things over. We committed to finish by Junetober 37th even if we’re not ready so it has to go in the sprint now. So now you put things into the sprint after the sprint started and remove things before it’s over so that the magic numbers look correct even though they are complete BS.
But luckily you can track things.
Except every team is forced to use the same workflow even if they don’t work the same way. Because otherwise it would be “complicated“. So the IT tickets have to look like software development tickets. And the planning tickets have to look like software development tickets. It’s important to have tickets to plan your future plans so you know what tickets to make. After all, if you don’t schedule everything 18 months in advance to the day, are you really doing agile sprints?
But you can link tickets. For example you can choose requires, or needs, or is dependent upon, or can’t be done without, or is waiting on. Wouldn’t one thing do for all of that? No one actually knows. It’s an unanswerable question.
Did I mention there’s Kanban support? You’re not allowed to use that. Because.
And all this gets so complicated you need people whose job it is to wrangle Jira full-time. Make reports, add more fields, etc.
Of course those fields don’t make sense in a lot of cases. But sometimes they required. And other teams want them required but aren’t allowed to because everyone has to work the same way.
So the ZRX team invents their own email gateway to put issues into Jira their way. You didn’t know about that right? Because if you add the issue directly they’ll ignore it. Productivity!
I don’t know if it’s fair to call the thing I used at those companies “Jira”. That’s a bit like calling a battery made out of a box full of potatoes a “vegetable medley”. I mean it’s sort of true but that’s not the point anymore is it?
I like actual Jira. It’s a good product. Too bad almost no company will let you use it, only corruptions. It doesn’t exist to do its real job but to instead generate management reports. Which they don’t read.
Yes, but no one can say that. Managers need to go off on project management, team management, and all sorts of other scenic hotel retreats to learn how to use JIRA better because of course the fault is JIRA and the underlings.
That's the cloud version, the self-hosted version is actually rather good. Atlassian sadly don't really want to sell that anymore and it's only available as a "datacenter" edition at a completely insane price.
Over-the-wire latency is the tiniest fraction of the time spent in a transaction with Jira (and Confluence). Most of their slowness is due to poor implementation in the client and backend, i.e., their applications.
Your JIRA instance probably needs to be hosted on more powerful hardware. In my experience, JIRA on-premise is way faster than JIRA cloud (but I do prefer the new UI in JIRA cloud, though that's a matter of preference).
My biggest complaint with all of the Atlassian tools I use (Jira, Confluence, etc.) is how slow and unresponsive they feel. Creating a new Issue requires waiting at least a few seconds, sometimes more, for the newly created Issue to pop up on the bottom left. Editing a Confluence doc requires clicking the edit button and waiting a few seconds while the entire page does, what appears to be, some massive shift to editing mode (understandable that there would be big differences between read and write mode, that's not my issue). I think my perception of and feeling towards the Atlassian tools I use would be, no exaggeration, 10x more positive if everything just felt zippy and close to instantaneous. "Speed is a feature", or however the aphorism goes.
We use confluence and jira, an d for some reason it seems perfectly usable compared to others stories here. It's not a small organization either, so I wonder if it's some misconfiguration that's killing performance for others?
That's quite possible! I'd love to know what it is. If it's somehow a consequence of the total number and age of stories since our account's beginning, I'm not sure what we could really do about that other than to do bulk deleting which...we really don't want to do.
It could be a plug-in. But anecdotally I’ve also heard the cloud version is much worse than on-prem, which if true could explain the big differences too.
I’ve used both Jira and Confluence on premise and Atlassian Cloud. For what you pay (when you pay), the cloud service performance is an absolute joke. It’s god awful slow compared to alternatives, even with small orgs and datasets.
It is 100% possible that it's a config thing... but I've used Jira on-prem with a fairly complex setup and in the cloud hosted version with what I believe to be the simplest out-of-the-box setup it has and both were terrible at performance, so... if Atlassian themselves can't tune it right, I'm comfortable saying it's just bad (or at least) software.
EDIT: Someone else in the comments suggested that the cloud version is slower than on-prem. This might account for things; if I've only seen complex on-prem and simple cloud, it might well be that simple on-prem can be fast. But... that's still concluding that Atlassian themselves can't make their own software performant, so it's not exactly a redeeming quality.
We had a pretty complex on-prem Jira/Confluence/Bitbucket/Bamboo setup with pretty good performance, at least good enough that it wasn't something we thought or complained about. We also managed and used cloud installation for customers, those pretty much always felt slower. We did have a fairly large number of Atlassian certified people in the company, all of which are probably A-tier when it comes to managing Jira, so that might have helped our on-prem performance. It's not like we had massive database and application servers running the software, but we might very well have thrown more hardware at it than Atlassian does per client.
> We use confluence and jira, an d for some reason it seems perfectly usable compared to others stories here.
I've been using Jira Cloud off and on at various startups and it always had its slow moments. At my most recent startup, it's been working very well with no slowness thay I'm aware of (knocks on wood), and that includes all of the stuff I do directly via API.
Besides being slow as shit Jira and Confluence have terrible UIs. None of the controls are clear, it's hard to tell the difference between a clickable thing or a typeable thing. Then there's just nowhere you can place the cursor on the same screen that doesn't make something animate or change color.
A mystery meat UI is bad enough but a slow mystery meat UI is just infuriating.
Right! I didn't even mention the actual UI, but I agree. There's no cohesion, nothing feels intuitive. It all kind of feels like it was designed by engineers/developers honestly :)
> it's hard to tell the difference between a clickable thing or a typeable thing.
Or both at once, because the description on a ticket isn't a text field until you click it and then it becomes typable (oh, you weren't trying to select text, were you?).
Yup, that was my first thought reading the title: No, my manager is fine, I actually like the workflow, I like the process; it is very much the implementation of jira that I hate for taking good ideas and making them slow, buggy, and unintuitive.
This times 1000.
We use an XRay plugin for JIRA to create tests, test runs, executions etc.
I shudder every time I need to go into XRay's TCR (Test Case Repository) which isn't even that large (~3k tests in total). The amount of "desync error, please refresh" is bad when viewing but goes absolutely bonkers when actually creating or editing tests.
Not to mention that the actual "writing area" takes maybe 1/4 of the screen estate. I hate this so much in the modern web applications - "Here we have this whole screen... let's make 25% of it actually usable and put useless crap on the rest."
Sorry, I suppose I had to vent as JIRA makes my blood boil.
They want everything to be WYSIWYG and in consequence re-implement almost every browser feature in JavaScript, which breaks everything which relies on the native features. Every time I click on a text area, the cursor disappears. It works if I tab into the text area. Infuriating. And for this it downloads 10MB of JavaScript.
In my last job, I definitely hated my manager and how they used Jira, but I actually liked Jira for the most part.
What I hated about Jira was that it allowed my manager to decide on an expectation for how it should be used, and though technically it did do that, it didn't enable me to use it in a way that aligned with their idea of how it should be used. It frustrated him that I didn't accept the guilt he was trying to throw at me for not using the tool in the way he decided was important. Also, it suffered from the same problems as any isolated tool; being out of sync with other tools and invisible unless I'm looking directly at it. I never really got the unresponsiveness that others mention, even on an intel MacBook pro.
What I like about Jira technically, is that it has a pretty decent rich media interface for expressing ideas. If I found a bug, or needed to document how something currently works, I could use the native screen recording on my mac and then drag the video file straight into the comment.
It would have been great if my manager wasn't a petulant, controlling, and passive-aggressive tool, so that I could use Jira in a way that better suited the development process.
It takes an impressive amount of experience, self control, and perspective for the management and product types to not take full advantage of the kind of absurd abuse Jira enables.
Jira gives people bad ideas and makes them think they’re supposed to do things that way.
Jira encourages bad behavior.
I don’t hate addicts for being addicts.
People with not enough to do find things to do and with jira around those things are “bothering developers with ever increasing process”, it is indeed the tool’s fault.
Jira is like the `extends` keyword in Java... It makes it way too easy to create huge hierarchies of classes that then take tons of additional tooling to refactor. Sure you can have a simple process in Jira... but it will be constantly whispering into the ears of you and your coworkers, "wouldn't you like to have an approval step for that? I can easily add one here... How about we add another state that this issue can be in? Then we can hide those issues from this alternate view over here..."
Jira ossifies your company process in concrete which feels great when you first build it but then agility becomes a struggle. You don't even notice it at first but slowly over time your company will fight to get things done outside of the process. You'll then spend so much of your time adapting Jira to reality, you'll wonder what the point of it is.
So yeah, you hate your manager who is mostly just trying to use the best tool for the job, and bought the most commonly used and well regarded tool for it... but that tool is encouraging them to build a giant mess.
165 comments
[ 3.5 ms ] story [ 194 ms ] threadFast forward a couple of years and it had become the company standard, replacing whatever preceded it, and the company had at least doubled in number of employees. The Jira workflows and ticket fields got the "corporate standard" makeover, including adding a field with so many values that alone it accounted for much of the increasingly poor performance.
The arguments the author makes here encapsulate the evolution at my then-employer. Everything became about using an enforced process and workflow. The worst part about it was how some of the changes were enforced on all projects from the top down, meaning teams (like mine) that had a reasonably good, workable project setup had to change the way we did things, use different terms, and generally give up the working style that made use successful.
Some time later, much to my chagrin, I ended up consulting at a company using something even worse than Jira: + Azure DevOps, Azure Boards, and all things Azure. These were coupled with the micromanagement and non-manager anti-patterns described in this article into a situation where developers spent more time pushing buttons and shuffling tickets arounds than writing code. The engineering manager made it clear how, to her, seeing tickets moving through the workflow on the board, on schedule was as important as working code.
And many more things.
Huh? That must be configuration on your project. I haven’t experienced that.
Is this just a restatement of Conway's Law[1]?
[1]: https://en.wikipedia.org/wiki/Conway%27s_law
It's slow, it's clunky, it's ugly, it's bug ridden, it's unloved, and nobody understands it.
May it die a quick death.
Did I also mention it's slow? I think I wrote this entire comment faster than one Jira page navigation. Maybe two, if I have to be charitable.
I used to get snotty comments from people opining about how awful Perl was and how great python etc was.
The funny thing when it was time to get something done, I’d be finished by the time they hacked together whatever python dependency shitshow they were buried in.
Perl’s time is in the past, but I wrote a ton of it, and some is still running in production in a few places 20+ years later.
I needed a point of reference for the analogy. If I'd mentioned PHP instead, people would have come out of the woodwork and vigorously protested.
I figured there wouldn't be many Perl fans left. (Still tongue in cheek.)
I’ve never used Jira but every task or list program that I’ve used does not reflect me and to do it I would have to manage it constantly.
It doesn’t reflect the context switching I do, or all the communication I do outside it to make it work, or my notes on how I’m going to do a thing… rarely is it accurate on my time and so on.
This is why they buy JIRA. It lets them sit back and look at charts of BS points, BS tags with little to no understanding of what the work actually means. They don't buy JIRA because it helps engineering. They couldn't care less that it takes so much of engineering time.
Which leads to why engineering hates management. Because management doesn't care about engineers, why should engineers care about managers?
But after layoffs, it was revealed that management literally just counted up Jira tickets to measure developer productivity.
So any time you had spent helping others was essentially just time you spent destroying your own performance ratings. ¯\_(ツ)_/¯
Management is an utter bane of the tech industry.
But it uncritically swallows the idea that the only way to have reasonable transparency is through atomizing work into trackable to-do items. I do successful work of all kinds with clients and collaborators and never come near a Jira.
It is surprising how many problems can be solved by simply ignoring them - the trick of course is knowing which ones to ignore. To-do lists tend to preclude this strategy entirely though.
Unfortunately, this puts a very low ceiling on the type of problems that can be solved. In fact, it works against creative problem solving because it obfuscates the big picture by drowning out the strategic summaries and narratives needed at different zoom levels for different stakeholders. The devil is in the details, and the only way to get the details right is to have real expertise and collaboration based on higher level understanding. Ideally every individual involved has the highest level goal they are capable of executing on, and is empowered to work out the details collaboratively with whoever needs to be involved. This is easier said than done, because most people—even experts in specific domains and skillsets—are not experts in collaboration and understanding other people's mental models. Management's job, if they are doing it correctly, is to understand these dynamics (hopefully rooted in deep hands-on expertise) and to set up the structure that facilitates the necessary collaboration.
Useful tooling for this problem is context specific, but less is usually more nuanced messaging or vision doesn't travel or align well across large groups of people. Jira does nothing to help with this; it's just not built for strategic planning or collaboration. It shines for tracking a huge influx of unrelated tasks that have to be passed around between silo'ed teams without dropping any balls. This allows project managers and operations folks to monitor things mechanically where the problem and process is already well understood. It offers very little to support higher-level problem solving.
One of the things I really enjoy about Jira is the fact that a task and a sub-task have the exact same UI. A sub-task can be easily moved to be a full task and vice versa.
"Agreed! let's move it to be a subtask of PROJ-1111! and here's a new PROJ-1235 for the second part, let's make it a subtask as well"
"Wait, I can't make PROJ-1234 a subtask of PROJ-1111..."
"Ah, I see, PROJ-1111 is already a subtask of PROJ-1002, which indeed makes sense"
"Oh, right! I forgot subtasks can't be nested. So maybe PROJ-1002 is an epic?"
"Sounds about right! Oh wait, PROJ-1002 is part of epic PROJ-223"
"Oh. I get it now, forgot about that epic which tracks things for product item foo"
"Alright, is foo still on track and required?"
"Yeah, it's merely been postponed because the currently worked on project item bar was priorised as we needed a bit more work to refactor and complete foo"
"So now we're set to do PROJ-1234 in the current sprint, and this would complete both foo and bar, two birds one stone!"
"Yeah that was the plan all along, having the design lend itself to that, with proper composition and all."
"But we can't make it part of both epics"
"Correct."
"What if we create a new task and link it with PROJ-1234"
"Could work. How do we qualify it though? It's "duplicated by" but we keep that for duplicate bug reports as there are automated workflows for it, notably a duplicate is supposed to be closed."
"Blocked by maybe?"
"Well it's kind of bidirectional and blocked by is one direction only"
"Drat there's no "Linked to" in the combo box"
"Yeah management wants everything qualified so that they can build reports. IIRC they don't scope it by kind "bug" because marking some tasks as bugs biases another counter, so some bugs stay as tasks, so they can count only bugs reported by customers and not internal bugs"
"Oh right, doubles down on why we can't use duplicate, we'd break the report. Actually I think we can't use the link feature at all because it's really the same task and that'd break their report too"
"Screw it let's just put a link on each one's description to the other. I'll shoot an email to the JIRA admin to see if we can add more link kinds, and maybe fix the automations and reports"
"Yeah, we're already overtime for that sprint planning anyway. Let's move."
"Should we do that at the PROJ-1234 level or at the PROJ-1111 level?"
"Not too sure. Maybe we should have used a checklist for PROJ-1111"
"But then PROJ-1478 depends on PROJ-1234 only, not PROJ-1111 as a whole"
"Ah, right. Maybe we cleaned up the arch a bit too much lol"
"Right? Maybe we should switch to an arch that matches how we can link tickets lolsob"
"JDD: JIRA driven development"
"Hold my beer while I write a JIRA plugin to export task structure as a code scaffold"
"Kill me right now"
"Goddammit time flies, let's finish this. So where are we on PROJ-1526?"
"Blocked, we're waiting on feedback from the user"
"Alright. Wait, there are two "Waiting on customer" statuses now? Which one is it?"
"Huh. Let me look at the browser inspector... Ok, id 17, so I think it's the second one. No idea where the other one comes from."
"Ha. Ok, moving on."
Slack pings
> Hey, meeting xyz has started 10min ago, are you joining?
"Drat"
Between every PM, every manager, etc, everyone wants to track slightly different information. The ICs can't keep up - they have five people telling them to use Jira just a little bit differently. The bosses/PMs don't feel this tension, they see only their asks, their report they want to stay up to date, they wonder why its so hard. Eventually, ICs see it as confusing hassle (like TPS reports in Office Space). ICs don't know what to do, and everyone gets confused, information doesn't actually surface in Jira, real issues get dropped on the floor, etc etc
The problem isn't that any one of those bits of reporting is wrong. It's actually that the higher levels need to realize they're actually asking for different / conflicting / excessive information and need to have a stronger hand in reducing information reported so to ensure that which is there is actually accurate.
(The insane configurability of Jira and other PM tools just reflects this chaos)
Managers and Jira have their place. It depends on context and scale of problem amongst other things.
I can imagine a tool like jira helping prevent a space shuttle disaster, and I can imagine a tool like jira not preventing it. I can imagine a manager preventing, and not preventing a doomed launch.
I can imagine a 2D grid of jria and no jira, manager and no manager and every single square can have "maybe, maybe not" inside it.
“because it’s slow as balls” is conspicuously absent as the first reason!
I do hate JIRA. JIRA adds all the beauty of a government bureaucracy to what should be post-it note management. It's hard to overstate how demotivating JIRA is to my work and especially to my planning. Worse, everyone in the organization has to use it.
[0]: https://blog.trello.com/jira-trello-intregration
I'm much more of a Kanban sort. Jira is awful at Kanban. Trello was great.
We migrated some of our Trello boards to Microsoft Planner (inside Teams), which is a laughable joke. Then eventually to Jira because Jira is an inescapable black hole and "oversight" from the micro-managers matters more than getting projects done on time.
That is the essence of a good workflow tool, and Jira will do it fine. It is all the extra stuff that seems to cause the grief.
But at other companies I’ve been at, it’s not a productivity tool. It’s a management too.
Estimates for planning. Which is fine. Until pointless rules appear. We’ll use standard story points. But not 1, that’s too small. So things start at 2. But after a while that’s too small. So they start at 3. But you can’t go over 8, past that they have to be split. And you shouldn’t probably use 8 anyway. Pretty soon everything will be 5s. No matter how big or small. Good thing we point.
And of course the whole point of pointing is to put things in sprints. That’s fine. But then the rules come. You can’t go over your capacity. You can’t go below your capacity. You have to roll over everything you didn’t do. You can’t roll things over. We committed to finish by Junetober 37th even if we’re not ready so it has to go in the sprint now. So now you put things into the sprint after the sprint started and remove things before it’s over so that the magic numbers look correct even though they are complete BS.
But luckily you can track things.
Except every team is forced to use the same workflow even if they don’t work the same way. Because otherwise it would be “complicated“. So the IT tickets have to look like software development tickets. And the planning tickets have to look like software development tickets. It’s important to have tickets to plan your future plans so you know what tickets to make. After all, if you don’t schedule everything 18 months in advance to the day, are you really doing agile sprints?
But you can link tickets. For example you can choose requires, or needs, or is dependent upon, or can’t be done without, or is waiting on. Wouldn’t one thing do for all of that? No one actually knows. It’s an unanswerable question.
Did I mention there’s Kanban support? You’re not allowed to use that. Because.
And all this gets so complicated you need people whose job it is to wrangle Jira full-time. Make reports, add more fields, etc.
Of course those fields don’t make sense in a lot of cases. But sometimes they required. And other teams want them required but aren’t allowed to because everyone has to work the same way.
So the ZRX team invents their own email gateway to put issues into Jira their way. You didn’t know about that right? Because if you add the issue directly they’ll ignore it. Productivity!
I don’t know if it’s fair to call the thing I used at those companies “Jira”. That’s a bit like calling a battery made out of a box full of potatoes a “vegetable medley”. I mean it’s sort of true but that’s not the point anymore is it?
I like actual Jira. It’s a good product. Too bad almost no company will let you use it, only corruptions. It doesn’t exist to do its real job but to instead generate management reports. Which they don’t read.
Poor Jira.
We are apparently moving to the cloud version soon, and it’s being sold to the users as the saviour for all the performance issues we’re encountering.
On-premise was designed for LANs. It does not traverse the internet well.
As an example, Atlassian themselves still use the on-premise version, and it's really snappy: https://jira.atlassian.com/issues/
Also, I'd be remiss if I didn't link to https://ifuckinghatejira.com/ (for the lulz)
Atlassian tools are decent enough, and mostly usable is how I'd describe them. I'd take anything else though, even Rally.
EDIT: Someone else in the comments suggested that the cloud version is slower than on-prem. This might account for things; if I've only seen complex on-prem and simple cloud, it might well be that simple on-prem can be fast. But... that's still concluding that Atlassian themselves can't make their own software performant, so it's not exactly a redeeming quality.
I've been using Jira Cloud off and on at various startups and it always had its slow moments. At my most recent startup, it's been working very well with no slowness thay I'm aware of (knocks on wood), and that includes all of the stuff I do directly via API.
A mystery meat UI is bad enough but a slow mystery meat UI is just infuriating.
Or both at once, because the description on a ticket isn't a text field until you click it and then it becomes typable (oh, you weren't trying to select text, were you?).
Sorry, I suppose I had to vent as JIRA makes my blood boil.
They want everything to be WYSIWYG and in consequence re-implement almost every browser feature in JavaScript, which breaks everything which relies on the native features. Every time I click on a text area, the cursor disappears. It works if I tab into the text area. Infuriating. And for this it downloads 10MB of JavaScript.
What I hated about Jira was that it allowed my manager to decide on an expectation for how it should be used, and though technically it did do that, it didn't enable me to use it in a way that aligned with their idea of how it should be used. It frustrated him that I didn't accept the guilt he was trying to throw at me for not using the tool in the way he decided was important. Also, it suffered from the same problems as any isolated tool; being out of sync with other tools and invisible unless I'm looking directly at it. I never really got the unresponsiveness that others mention, even on an intel MacBook pro.
What I like about Jira technically, is that it has a pretty decent rich media interface for expressing ideas. If I found a bug, or needed to document how something currently works, I could use the native screen recording on my mac and then drag the video file straight into the comment.
It would have been great if my manager wasn't a petulant, controlling, and passive-aggressive tool, so that I could use Jira in a way that better suited the development process.
It takes an impressive amount of experience, self control, and perspective for the management and product types to not take full advantage of the kind of absurd abuse Jira enables.
Jira gives people bad ideas and makes them think they’re supposed to do things that way.
Jira encourages bad behavior.
I don’t hate addicts for being addicts.
People with not enough to do find things to do and with jira around those things are “bothering developers with ever increasing process”, it is indeed the tool’s fault.
Jira ossifies your company process in concrete which feels great when you first build it but then agility becomes a struggle. You don't even notice it at first but slowly over time your company will fight to get things done outside of the process. You'll then spend so much of your time adapting Jira to reality, you'll wonder what the point of it is.
So yeah, you hate your manager who is mostly just trying to use the best tool for the job, and bought the most commonly used and well regarded tool for it... but that tool is encouraging them to build a giant mess.