Get the top HN stories in your inbox every day.
bschne
ta1243
I work in a mid-to-large org. The more agile part use tools like jira and slack. The older part (established in the 1920s) use Remedy and Teams.
Jira is brilliant. It is team-led. Different teams have different approaches, some love all the features like components, versions, issue types, assignee, kanban boards, scrumms, reports etc etc. Others like my team use it with subject/description/comments. You make the tool fit what the team needs.
Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I have no doubt you can use Jira in a "KPI led" way. I do doubt you can use Remedy in a responsible way, but even if you can, it relies on the culture of those selling the tools.
Sadly I fear jira and slack will be next -- they already took Zoom and gave us teams instead, after all we "already pay for teams with office" (which aside from cloud-based email, I, and my teammates, never use).
Never has an anti-trust move been so obvious or damaging.
zac23or
“Jira is brilliant”
I've never read that sentence before!
My feeling is... developers hate Jira, managers love Jira. And that is expected. The tendency is for things loved by managers to be hated by developers, such as meetings, metrics, etc.
An example of a very misused metric: In one of my jobs, managers started using Scrum Poker results as a productivity measure. “My team scored 100 points in the last sprint.” Imagine the chaos this generated. Quickly teams began to hate the Scrum poker.
Jira is probably just a scapegoat in corporate theater, something needs to be to blame. Jira is a good culprit.
psunavy03
> The tendency is for things loved by managers to be hated by developers, such as meetings, metrics, etc.
There's an unfortunate tendency for some people to scoff at the immutable fact that to write software, you have to talk to other human beings. And that if a company is paying you good money to do it, they are going to want to know when it will be done and what ROI they are getting on your salary.
Sure, there are stupid meetings and stupid metrics. But to lump "meetings" and "metrics" into a "hated" category is the mark of an immature dev who doesn't understand why he/she has a job and a salary in the first place.
kortex
I'm a developer, and while I don't love it, I certainly don't hate it, and I don't see it worse than any other task-tracking tool. I haven't used trello or asana in a hot minute, but they were way worse in terms of UI and UX.
I'm not totally sold on the whole points poker process though, but that could be a criticism of agile as a whole.
cqqxo4zV46cp
Yes, but orgs that want to do this would likely have done it regardless of the use of Jira. I have my team use story points yet I don’t ever use them to measure team or individual velocity. The fact that Jira enables incompetent managers (which is not the same thing as ‘managers’, one is necessary and one is not) to be incompetent is in my opinion a fairly low-level mark against it.
The reality is that most developers don’t know what degree of organisation / visibility is required for it to even be tenable to do their job in the context of a wider organisation. ICs, and the experience of ICs, should certainly be taken into consideration when picking PM tooling, but it’s not a bad mark against an org to also take into consideration the very real needs of management, PMs, etc.
There are always going to be those people that will categorically associate management with ‘bad’ and I just simply cannot respect that opinion. It’s the equivalent of being mad at your parents for setting a bedtime. Some of the Jira hate definitely comes from people with that mindset.
ta1243
I use jira, I do not use points, sprints, scrums, etc
Jira doesn't require those features. My workflow is "Ready, On Hold, In Progress, Done". It's a glorified task list with assignees, tagging, emails etc, that's corporate-wide -- no need to get random people to get accounts, everyone has one. All over our documentation and configs are references to "TKT-1234", which explains the background to a specific thing far more than an inline comment could.
It does the job just fine, I didn't need to jump through any hoops to get it working like that.
The alternate system engineers in other departments use is email. Tracking things in email is awful.
You can use Jira for far worse things, but that's not a problem with the tool, that's a problem with the culture.
bitcharmer
> My feeling is... developers hate Jira
I'm a developer and I like Jira. People who hate it are probably forced to use some bloated setups. We just use Kanban and the backlog and that's it. It's great if you don't turn it into a fully blow project management tool.
LtWorf
Read the rest of the comment and what he loves about it. He's not a dev.
NikolaNovak
Interesting; I think this is a demonstration of how much what seems like a "Tool" is actually "organization", because my current experience is completely opposite:
* In MS teams, I can create conversations, group chats, organic meetings, and add people (and include history) as I want and desire. I prefer it for quick discussions with my colleagues and to get a rapid problem solving or critical incident conversation where I don't immediately know who I need / what it's about, and it'll scale as I add people. I push a button and talk to people, push a button to add people, push a button to video chat, all seamless.
* Slack is structured and formal and based around enterprise-created channels and workgroups, with way too much noise in each massive channel and way too little content that's even remotely relevant to me. Outside of channels, conversations are horribly gimped: A) I can only have one conversation with each set of people, I cannot simply rename a chat and have three different chats with same people around different topics B) If I add people to an existing conversation, it will create a new chat without history (this may have improved recently as I know we sent a TON of feedback to Slack admins). Basically, to get anything done you have to create channels, which is great for "top down, I know ahead of time what I need / want to enforce" structure, but awful for "this started as a one-on-one and is now a massive discussion with 17 people"
I'm looking at some of the other comments, and it seems they have some weird gimped version of MS Teams. E.g.:
>>"Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel."
This... is how it works for me. I start a conversation with some people, then I add people, then I click "Call", then we all video call together, then we are done and keep typing in it, repeat as needed.
Weird!
TJSomething
> Basically, to get anything done you have to create channels, which is great for "top down, I know ahead of time what I need / want to enforce" structure, but awful for "this started as a one-on-one and is now a massive discussion with 17 people"
In Slack, you can turn a group DM into a private channel and keep the history.
https://slack.com/help/articles/217555437-Convert-a-group-di...
Tagbert
That sounds like you have a very top-down organization and they have setup Slack to mirror that dynamic. Slack by itself does not have those restrictions.
Individuals can create Slack Channels (often too many channels). You can setup adhoc groups through DM and can add people to that group . You have the choice when adding people to a chat to block the history or give them full access to the history. At any point you can convert a adhoc group into a Channel and decide if it will be private or public. You can click to start a call or to start a zoom with those present in the group or channel. it's pretty seamless, too.
It sounds like the difference is your organization.
vundercind
Teams would be fine with two things:
1) Let a Team channel be a normal-ass chat instead of some weird forum-in-a-chat-interface. Shit gets lost. Creating a new post feels very formal and high friction, because it’ll push everything else out of view (another, minor problem: teams’ padding and whitespace is way out of control). Make it configurable! That’s ok. The weird chat-as-forum thing is fine for a very low-traffic announcements channel (and very bad for anything else) so having it as an option is alright.
2) Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel.
These two problems force conversations away from the “Team” and into meeting-specific chats and DMs. It’s really, really bad. It silos knowledge and makes it hard to tell wtf is going on.
Teams is horrible for distributed or hybrid work because of these two deficiencies.
apple4ever
OH MY GOSH yes. I first started using Teams and these two things drive me crazy.
Just make it like Slack, and Discord, etc. its a solved problem!
a1o
There is probably some feature request somewhere in Microsoft weird tech channel with thousands of comments and upvotes and some MS person appearing every three years to let us know they "are looking into it".
stackskipton
On Number 2, you can schedule a meeting in a channel that have meeting show in the channel and keep the chat there.
ClimaxGravely
2) Is that the equivalent of a slack huddle?
kstrauser
I can personally vouch that Jira can be inflicted on engineers in a “KPI led” way.
freedomben
yes same, in fact the access to metrics (for use in part in KPIs) was a primary driver of our adoption of Jira
ta1243
And a screwdriver can be used to destroy. Doesn't mean that's the only way to use it.
almostnormal
> Jira is brilliant. It is team-led. Different teams have different approaches, [...]
That doesn't sound real. There's supposed to be some central department(s) that collect ideas from the process framework of the season or requested by customers (especially those items for levels that are not requested), add their own ideas and create a superset of that as configuration with everything set to mandatory. The result is infliced upon everyone, except of course the department that was responsible for the definition.
blueskythinking
If by “team lead” you mean the noisy few set the rules and the rest of us have to deal with it, then that also matches my experience of Jira.
fennecfoxy
Isn't that just human interactions in general? Society etc.
ta1243
My team is 3 people so we're all the "noisy few"
wkat4242
I don't want to use any tool or methodology.. I just want to do my work.
NikolaNovak
I'm assuming that's a funny/sarcastic comment, but the scary part is... there's a chance it might be serious! :-O
fragmede
how do you want to do work without tools?
lmm
> Jira is brilliant. It is team-led. Different teams have different approaches, some love all the features like components, versions, issue types, assignee, kanban boards, scrumms, reports etc etc. Others like my team use it with subject/description/comments. You make the tool fit what the team needs.
> Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
> Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I'd say it's the other way round. Everywhere I've seen Jira, the person who can change the tool settings (e.g. make mandatory fields optional, add a transition to allow you to move a card to the column it should be in (because Jira is deny by default, you can only move things in ways that are specifically allowed) is a very distant part of the org chart from the team doing day to day work on it. "not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance" is exactly how I'd describe Jira, given how I've seen it used (across a great many organisations, large and small - indeed I'd say switching to Jira is the most reliable indicator that a previously fun company has grown too big and it's time to leave).
Some stuff is probably just typical managerial bullshit. But the fact that Jira defaults to working as a slow, drag-and-drop interface with no undo is absolutely an unforced error.
> Never has an anti-trust move been so obvious or damaging.
Atlassian buying Trello and gradually ruining it is worse than MS giving away crappy products for free.
ta1243
Your jira seems to be set up to reduce your control
My corporate jira gives me full control over the workflows, what fields are shown, etc
That's not a jira problem, it's an organisation problem
There's no way I could extract any usable metrics from my jira, but that's not its purpose. It can however tell me where we are with the new upgrades to Site 95 (waiting on the people running the fibres), or who wanted that new device in Site 5 and crucially why.
VonGallifrey
When I clicked on the site the very first opinion called Jira shit because they had 20 different boards for the same thing, 2000 tickets in the backlog and 20 different mandatory fields for each ticket.
Which is absolutely not the fault of Jira. Jira does not make you create 20 boards and per default a Title is all you need to create a Ticket. By the complaints own wording they had 2000 tickets because management refused to delete outdated and irrelevant tickets.
A new tool would not fix this since I would bet that management would insist that all 20 boards with all tickets in the backlog would need to be transitioned to the new tool. The mandatory fields are obviously also highly important to management, those need to be configured in the new tool as well.
Instead of complaining about the obviously bad management they just complain about Jira. That is, I think, very common when complaining about jira.
lmm
If one company uses a tool badly that's a bad company. But if most companies use the tool badly that's a bad tool.
Jira certainly seems to push people towards having a handful of manager users who are the only ones who can create boards/transitions or adjust which fields are mandatory, and this leads to bad behaviour - if only one VIP can create boards, they'll probably create 20 once and then never create another. "Title is all that's required" may be the default in some editions of Jira today but it certainly isn't widely used. And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have - there may be occasional use cases where you need e.g. an action that's impossible to undo, but it's an awful default.
VonGallifrey
Well... for us every team gets a "Project" and the Team Lead is admin for the Project. The TL can then Create Boards, Issue Types, and Workflows. The Team is in control of what their Board and Workflows look like. Not some far away manager and if we do need the company Jira Admin to do something, it just needs a IT Support Ticket and that will be handled.
We set up our Board and Workflow fairly minimal. Which is probably why I don't have any problems with Jira.
> And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have
What do you mean by that? The default Workflow in Jira is that all Issues can transition into any status.
michaelt
Would you at least agree that it's bad that Jira is slow as shit, in both its hosted and on-prem forms?
Management didn't insist on that.
VonGallifrey
It isn't slow for me. So no, not in my experience.
matt_s
The problem with JIRA the product vs. any instance of JIRA is feature bloat in the product has allowed for people to spin their wheels with all sorts of whiz-bang categories, labels, charts, and other nonsense.
The dopamine hit from tweaking charts and organizing digital clutter is probably the same area of the brain where the social media infinite scroll dopamine hit happens. If JIRA the product didn’t offer all these dopamine hits for doing busy-work, aka “features”, and stuck to basics then people wouldn’t be complaining about the tool and how their management/admins have implemented some nonsensical process.
goalieca
Medium sized orgs have a full-time jira person to manage all this. I’ve seen this now at three different orgs.
sb8244
This hits the heart of it for me.
I've used Jira (last job) and Linear (now). I don't really see any compelling reason that Linear is "better" than Jira. Jira was always pretty easy to use and navigate for me, and we had team-focused views for ourselves.
Even on this site, several opinions I looked at are about the idea of process or the implementation of a process—not really about Jira. And several of the ones about Jira just came off as whiny nitpicking and not actually meaningful.
stackskipton
Linear being strongly opinionated helps keep Project Managers (broad term for manager types) in check. Jira trying to be everything to everyone means KPI management is just a few clicks away.
AtlasBarfed
I'm not going to "stan" for JIRA, but I've developed software before Jira with Bugzilla and other smorgasborgs of tools.
JIRA was a dramatic improvement at one point, however, it is bought and sold to managers, so it is unsurprising it eventually converges to managerial overengineering.
mgkimsal
> it is bought and sold to managers
That is the root of the issue.
I've seen many small orgs adopt trello, slack, discord and other tools organically. I've rarely seen a small org willingly choose jira or teams; that is a choice that is almost always imposed by non-users of those tools.
commandlinefan
> disdain for the specific tool vs. disdain for what working in a mid-to-large org
You're kind of missing the problem here - it's both and neither. It's not the tool (it's awful) or the mid-to-large org itself, it's the concept that a tool as blunt as a ticketing system can meaningfully capture software development management in a useful way.
If people just treated it as a "necessary evil" time-tracking type system to make sure people were really working when they said they were, that would be irritating but not damaging. But far too many people without a lot of mental faculties actually take it completely seriously and try to put everything in it and expect meaningful results out of it. It actually ends up being worse than "nothing at all" because it _insists_ on the "only do what can be predicted and whose predictions is measured in hours" model of software development that stupid people think encapsulates creative activities.
dboreham
> the concept that a tool as blunt as a ticketing system can meaningfully capture software development management in a useful way.
The background to this is : yes it can. I worked in organizations (long pre-Jira) where we developed the bug/ticketing system specifically to drive our development management process. The two evolved in concert. The result was excellent, and sadly has never been re-achieved with any of the modern tools.
My take on this is that somebody was told that the bug system can be used to drive project management (which it can) but then implemented a bug system without any real understanding of what that means or how to achieve it.
lijok
> But far too many people without a lot of mental faculties actually take it completely seriously and try to put everything in it and expect meaningful results out of it. It actually ends up being worse than "nothing at all" because it _insists_ on the "only do what can be predicted and whose predictions is measured in hours" model of software development that stupid people think encapsulates creative activities.
You’re conflating ticketing systems with work estimation.
commandlinefan
So are they.
sverhagen
My team does a lightweight agile process, we don't hate it. If we used a better tool, we'd love it. We have Jira, and I don't have the energy to change it, nor do I want the responsibility to decide or suggest what other tool that should be. I've always used Jira, I have no suggestions ready. I'm sure it's easy to pick a simple tracker, like GitHub Issues, but I would not know if it'd suffice all our needs and if it would scale, and again, I don't have the immediate energy to invest time into that. But meanwhile Jira is slowly eating away at me. I think the general concepts are acceptable. It's just all the rough edges, all the stupid little design decisions, and its slowness that I hate (passionately).
lmm
> I'm sure it's easy to pick a simple tracker, like GitHub Issues, but I would not know if it'd suffice all our needs and if it would scale
The irony here is that those simple trackers scale a lot better. Jira's complexity is part of why it scales poorly - it's really bad when you have 500 people trying to use it.
emllnd
- Monday.com
- Airtable
- A giant board on Miro.com with a bunch of notes in frames
Of course the scaling needs are different whether it’s for just a single team or if the data needs to be aggregated into some KPI. In my experience it’s better to keep KPI publishing separate from task tracking, though
IshKebab
Trust me it's distain for the tool. Jira is bad on three fronts:
1. It's too configurable. It's like the company wiki. People come in, set up some random projects, processes, fields, statuses, etc. and then move on. There's rarely someone making it all consistent and sensible. This results in task statuses that can be TODO, BACKLOG, PENDING, WAITING, TO DO, etc. etc. etc. You also end up with waaaay too many fields for tasks. Arbitrary distinctions between "Tasks" and "Stories", etc. You're at the mercy of your Jira admin who will definitely make worse decisions than e.g. the developers of Phabricator or Gitlab. Hiding useful fields, adding pointless ones, etc.
2. Despite being super configurable, it can't do some really basic things you'd expect from something whose sole job is task tracking. For example you can only parent tasks 2 or 3 levels deep. A task can't have two parents. Subtasks can't be in different sprints. You can't reorder tasks by priority in the backlog.
3. Most offensively it is just incredibly slow. The main way you add tasks to a sprint is drag and drop on the backlog, but it performs so badly (100% CPU all the time) that they've had to add context menu options to move tasks to the top/bottom or to a sprint. I believe there's also an option to disable animations. A simple web page should not consume 100% of my CPU.
It's by far the worst issue tracker I've ever used.
Companies still pay for it though because PMs love the pretty burndown charts and being able to add a gazillion fields to tasks. How will they report project status to their bosses if they can't have Jira work out the exact-to-the-second estimated delivery time automatically? And by "automatically" I mean by making someone else do all the work.
erik_seaberg
My favorite is trying to figure out the subtle inflection differences between “won’t do,” “rejected,” “deprecated,” “won’t fix,” “can’t fix,” “cancelled,” “invalid,” “abandoned,” and “declined,” as well as the priority at which we aren’t doing something (um … low?)
spondylosaurus
Re. your third point, Confluence is also slow as shit. Using both together is like returning to the age of dial-up.
toolslive
Not only that. Once you've battled the sucky editor and have the document in confluence, you will realize that if you export it to pdf (or word) it will look like shit. So what's the point?
"Confluence is where information goes to die"
emmelaich
I could tell when some other team were having planning meetings when Jira slowed to glacier level.
Even a small drag'n'drop resulted a vast amount of computer power grinding away.
DarkNova6
I am thinking the exact same thing. Right now I wish I could use Jira because I‘m using this IBM equivalent tool „CCM“.
CCM is so bad it’s nearly dysfunctional. Image Jira but 3 times the necessary clicks (this is not hyperbole).
With Jira I can see the good intentions and how they go awry. But CCM is pure madness from top to bottom.
username135
Gods, anything thats interactive and IBM related is generally annoying and not user friendly.
emmelaich
Friend in IBM said the tool they used had 10s and 10s of mandatory fields...
Which were ignored because everyone found it easier to just read and search the comments. So a thick chunk of commenting became de facto mandatory.
dakial1
Even IBM is getting rid of IBM (or ex IBM) stuff. They are using outlook now, lots of teams use Jira/Trello/Confluence etc...
MichaelZuo
They sold their in-house wiki system back in 2019 so they pretty much are forced to.
itronitron
Jira + Scrum is a soul crushing nightmare, Jira + Kanban is fine.
OJFord
I agree that scrum is a soul-crushing nightmare & kanban is fine, but Jira a nightmare of a tool to use regardless of your process, IME.
lmm
Disagree; Jira + Kanban is if anything even worse. Since Jira is such a pain to use and Kanban doesn't have any requirement for estimation or timeboxing, people will write one ticket that says "do everything" and work on it for 6 months. While admittedly avoiding Jira for 6 months at a time is good for the soul, when you put your head down and work on something with no context for 6 months you usually end up making something that wasn't actually wanted and has to be thrown away or drastically reworked, which ends up being more soul crushing.
ch4s3
Until someone comes along and tries to put some scrum into your kanban.
toomuchtodo
Ahh, someone woke up and chose violence today.
psunavy03
It's no different than Agile or Scrum. It's just a tool, but if you put it in the hands of morons, you're going to have a bad time. Especially when there are explicit assumptions about how you'll use it built into said tool, and then said morons ignore them.
Unfortunately in any medium-to-large org, there are a non-zero number of morons.
he0001
Jira tries to solve everyone’s problem. It tries to incorporate everyone’s idea of how and what’s needed to be tracked.
I can just say from my own experience that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer or anything near a software project, and yet enforces all this garbage for their illusion of control. And yet they have none. Just because they are higher up in the hierarchy than the people that works with the actual product.
And then there is all these managers that think that everything should be a ticket and all changes can absolutely map to a ticket. Or that everything is actually done by the guy on the ticket.
I bet when I die and go to hell, my punishment will be to fill out Jira tickets and push them through the workflow.
Edit: formatting and spelling
submain
I share the sentiment and frustration of having to fill useless boxes.
However, as a manager, things go south very quick if you're not tracking what's being changed and by whom. You won't know what's included in your release, nor if it was tested properly. You won't know who to reach for fixes after testing or even what to tell clients when they ask if a feature/fix was shipped.
I hate overly complicated processes, but tracking things is essential.
TheCoelacanth
Continuous deployment is the solution to that. You always know what is in a release because it's the one thing that you were trying to change when you clicked merge.
Overly complicated processes are just patches to try to cover up for immature engineering practices.
ozim
Bonus points for insisting on tracking everything in Jira and then not making effort to open it up to check and asking for status updates via im/mail/call.
jdmoreira
Your developers must be children then. (Maybe because you treat them like children).
The source of truth is their changelog not your Jira tickets
submain
Quite the opposite actually. My developers barely touch their tickets. Most of the updates are done rather informally. They mostly interact with git and I make sure things are tracked.
You’ve used quite strong words there.
undefined
scubbo
There are already 4 replies telling you that you're trying to reinvent source control, and that's still not enough.
_dain_
>tracking what's being changed and by whom
git
>You won't know what's included in your release
release notes
>nor if it was tested properly.
CI
vundercind
Resistance to simply reading data we already fucking have is so very weird to me in “agile” (and much of non-agile, to be fair).
Part of the trouble is using things like Jira and moving tracking-what’s-happening and chatting-about-features farther from the code than it needs to be.
occz
Seems like the kind of thing that Git is really good for, right?
dingnuts
> that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer
This is all configurable by the JIRA admin at your org. You're not complaining about JIRA, you're complaining about someone at your company who set up the workflows. I figured this out after bitching endlessly about JIRA at company 1 only to move to company 2 and discover everything I had hated about the process was set up by my previous boss...
I thought it was JIRA, but it was the org..
bigmattystyles
The problem is when your instance has too many masters - all fields are global, then their visibility is controlled at the project level. In a big company with one instance, holy sh!t. There are so many duplicated fields, unused fields. When you go to the bulk change option, it shows you all of these and it goes for days. It works well if you keep it under control, but word to the wise to any company. Create a governance board that's not afraid to tell a VP to fuck off with their requests for yet another ill-conceived field. That's from the user / web viewpoint. Don't get me started on their API. v2, v3 changes - the stuff you can't filter out that bloat responses, etc.... But otherwise, if well controlled, it is good. Or at least one of the least bad systems.
robertlagrant
Lots of things can be a ticket, though.
bern4444
Eh - I like Jira or rather I don't dislike it.
My team has done a lot of work to lean into the tool IE well defined issues, epics, tickets, t shirt sizing for pointing via 1, 3, 5, etc.
There is lots that can be improved for sure.
With this system, my team, in addition to any one else at the company, is able to click into our JIRA board and get a very high level to a very low level understanding of what we are working on.
This allows for very clear reporting structures and ensures our goals are on track with those of the company's. This also makes outcomes more measureable which is exceptionally helpful for reviews.
At the end of the year or halfway through I can go in and say: I worked on these 4 epics that are part of these two Issues which serve company goals A, B, and C. I completed x% of the tickets for each of these epics, led this entire other epic which was completed on time etc etc.
Where we run into issues is when there is a ticket that has to move between boards. The ideal situation is we just move the ticket from board to board as needed but based on the user they may or may not have permissions and have to open a new ticket linking it to the previous one. Not ideal but that's up to us to resolve to make sure the right people have the right permissions.
We ignore all the analytics IE burn down and friends. Those are useless.
kstrauser
I wrote “Jira Is a Code Smell”: https://honeypot.net/post/jira-is-a-code-smell/
Short version: Jira, in a vacuum, is neither great nor awful. It just is. But it has a complication that makes managers I want to work for dislike it, while strongly appealing to managers I don’t want to work for.
That’s not universally true, I’m sure. However, it’s been my experience.
kagevf
> But it has a complication that makes managers I want to work for dislike it, while strongly appealing to managers I don’t want to work for.
I think that could also be described as Jira gives people who don't really have anything to do, something to do, but for those who are blessed with an abundance of work, Jira can be unnecessary overhead.
Supermancho
My primary problem with JIRA, is that there is very little support for dependency trees. I have tickets X and Y linked to A,B,C,D and nothing but an ad-hoc way of determining how they are related. A visualization and tool to assign places in a tree, are part of what keeps JIRA from being excellent...ok that AND the horrid UX.
n4r9
If Jira could take a dependency tree and estimates against each item and build out a timeline and display it like a Gant chart, that would be incredible. Even better, factor in employee working hours per week and bank holidays. Even better, dynamically update the timelines based on estimate updates, delays in external dependencies, or sick days.
But actually my biggest grievance is the terrible search function. You can search for the literal title of an issue and it won't come up in the results.
neilkk
Didn't our whole software industry come to a consensus to stop doing things like this because the results were fundamentally inaccurate and the invariable outcomes were stakeholders feeling hard done by and/or ICs being victimised by middle managers?
noddingham
Jira needs an admin to help manage the configuration. It's like a Swiss army knife and the reason many teams hate it is because they don't have an admin helping them get what they need out of it and keep the rest of the tool out of the way. The flexibility is both a blessing and curse. If you don't like Jira it's likely your configuration is shit, or your process is shit, or both.
sodapopcan
This, yes, but it's also sllllllow. I'm assuming this is due to the high configurability (all those options must be a pain to cache) but that is just a guess. In any event, I moved to a company that used Shortcut (formerly Clubhouse) and it was crazy fast! Like, every action was sub 100ms. While it worked very similarly to how my previous company had configured Jira, I found myself missing some stuff, mostly Jira's backlog. My current company uses Zoho and its "Projects" module is a similar but different pain from Jira. It also suffers from being way too configurable.
dopamean
Maybe I'm lucky but I have yet to work in a place where any of the organizational or project management problems could be blamed on JIRA. Not even as like a top 5 reason. I don't love many of the tools I use day-to-day but JIRA is the only one that I consistently hear and read so much vitriol about. I think there's something else people are so angry about and JIRA is getting an outsized share of the attention.
alistairSH
My "issue" with Jira is that it's a large, amorphous piece of enterprise software. So, there's a million ways to do things. And a million plug-ins to extend functionality.
So, when I try to do something new (to me), and I search the web, the hits are frequently outdated or related to a plug-in that I might not have access to. Makes it really difficult to do anything that isn't part of my company's baseline.
et1337
The problem with JIRA and its ilk is that they try to do bug tracking, planning, and historical data all in the same tool, when those are really separate problems.
Have a bug? JIRA makes perfect sense, you have a ticket with comments, it keeps track of how long it's been around, it can automatically move the bug through a process, etc. All these tools started out as "bug trackers" after all.
Trying to plan future work? What I usually want is some kind of lightweight graph tool to figure out task A unblocks task B, etc. This graph changes a lot over time, with tasks merging and splitting apart. I've wasted a lot of time trying to enter all this in tickets.
Want to know about work that's already completed? I would never look at JIRA. Look at your Git forge. Pull requests should have proper descriptions. The Git history will always be more accurate and detailed than a bunch of JIRA cards.
So basically, use JIRA for bug tracking, Git/Github/Gitlab for historical tracking, and I'm not sure what to use for planning. Honestly I've been reaching for Excalidraw recently.
nomel
JIRA includes integration for Github Enterprise. If a commit message or branch references an issue number, it will automatically be included in that JIRA issue.
hkchad
The issue w/ jira is usually the people running it. Jira will let you customize just about every aspect of it, this typically leads to a garbage experience.
web3-is-a-scam
The only thing worse than Jira managed by an obsessed micromanaging manager/Jira admin is when they leave and you’re left with their godforsaken configuration that everyone hates and nobody can change.
tomohawk
But this is exactly the problem with Jira. It enables overachieving in doing tickets, which should never be a goal, to the detriment of things that are actual goals.
harry8
The people who make the purchase decision to pay Atlassian are a tiny fraction of those using the tool. The rest have no say in the choice that results in sales dollars. Atlassian can treat this majority with contempt because their only option is to bitch &/or quit which is a very limited amount of power. So Atlassian does treat the overwhelming majority of its users with total contempt and this is financially rational.
Right up until Atlassian and Jira become synonyms for everything bad amongst the overwhelming majority of people who have encountered it. About when "Jira-free workplace" goes on job ads. Which has got to be a pretty good strategy by now. Anyone seen it yet?
morkalork
Confluence is where documentation goes to die.
Washuu
Confluence search is terrible and never finds what I want even if I type in the exact title.
gyudin
They gave a try fixing it a while ago before giving up completely
circusfly
I much prefer Confluence to something like myriad Word and Excel sheets of uncanny versions floating around mostly unknown Sharepoint locations.
rightbyte
At least you can search more or less properly in network folders.
At my old work I usually left a search going from the root network folder over the weekend, scanning for some keywords, when I needed a doc none knew where it was or if it existed at all.
There was a parallel documentation system from IBM that didn't work, where the canonical docs should be. But you more or less had to know the document ID to query it. So most documents were also in the network folders spread out between hundred project folders and meeting folders.
fuzzy2
Where would it need to be not to die? Also, what kind of documentation? Technical? Or business?
wwilim
In the repo with the code, linked to from a sensible wiki that serves only as an index
morkalork
In the repo with the code. Seeing commits where both the code and doc change together is a sight to behold.
fuzzy2
Okay, but again, which documentation is that? Technical or business?
Because I do not see business documentation evolving with code. And depending on what the code does, business documentation could be much more important than technical documentation.
ta1243
That's how our conflusence is used.
Some departments do stupid things like duplicating information. We use confluence to describe the requirements, the concepts, then point to the right locations.
Take IPs, some departments have pages and pages with the same IP, subnet, etc in
expazl
You can do that in confluence.
ben7799
That's cause it's write-only.
It's like:
cat $DOCS > /dev/null
rm $DOCS
slingnow
What do you use for documentation? My experience with Confluence has been similarly bad.
tomohawk
markdown, in the repo with the code.
throwawaaarrgh
Terrible experience for anyone who isn't already a contributor to that repo.
Docs exist for people other than those that wrote them. The people that wrote them don't need to know the information, they already knew it.
dingnuts
It's the worst documentation tool, except all the others.
Seriously though, what is better?
sa46
I’ve been pretty happy with Slab. Straightforward shared wiki with a good editor, governance, and integrations. https://slab.com/
I tried using README files in the repo but there’s far too much friction to get most folks to bother. Google Docs tend to disappear content due to a lack of structure.
paiute
At my current job, i need to make a jira ticket, a branch, do a live review… all to change a minor thing in a README
morkalork
Speaking of Google docs, I just now had the joy of talking to a co-worker while trying to figure out the source of truth for something and we spent 10 minutes thinking we were looking at the same doc when in fact we were not! The owner had made and shared multiple slightly different copies.
nomel
> I tried using README files in the repo but there’s far too much friction
I have confluence links in my Readme, which seems to be a pretty good balance, since it's physically impossible for people to use a search bar in a wiki.
throwawaaarrgh
Nothing! Confluence is literally just a Wiki with a REST API and a hundred plugins. You could replace it with a different Wiki, but that won't have as much useful plugins and won't be integrated with the other Atlassian products.
paiute
Readme.md and an examples/ or tests/ I liked notion for business wikis.
amai
Random word documents in MS share point are the industry standard. Compared to that Confluence is a good tool with a great search.
ClimaxGravely
I loathe confluence, tried to get a markdown plugin around 2016 and IIRC the charge was 5$ per person at the company per month.
For what it's worth it's a lot better than it was in 2016 but I'm still not a fan.
wcoenen
There is much worse out there. We were forced to use Rally[1] for a few years, and I'm absolutely thrilled that we're going back to Jira.
[1] https://www.broadcom.com/products/software/value-stream-mana...
glxxyz
I was at a company where we were forced to migrate from a simple lightweight internal tool to Rally, against my advice. It was much worse, and we migrated back within a year. Waste of everyone's time, and our issues got completely mangled and all the formatting looked like total garbage.
tiltowait
We're forced to use Rally. I look at Jira with envy and longing.
iamacyborg
I quite like Jira, it does the job I need it to.
Get the top HN stories in your inbox every day.
I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.