There's a bias in HN that favours the simple and clean. But the real world is full of bureaucracies and complications due to legacy and/or politics or some other factors (like momentum).

When HN users argue that certain tools (like Jira) is too complex, they imagine that a simpler tool following a simpler process would've worked. For them, may be it would, as a greenfield project, but not for the enterprise currently using Jira or is going to adopt it.

Is this complexity warranted? I mean could not the same goals be achieved by less formality and less complexity?

Most Engineering teams would probably work frictionlessly with any simple Kanban style board.

The pull force in JIRA is how much it gives PM's and other managers a feeling of air traffic control visbility. It ends up serving as a medium for less technical people to digest and participate in a project.

The features that in my opinion keep Atlassian profitable is all the automatic reports and analytics features more so than the daily work functionality.

I can't defend confluence for various reasons, but JIRA? HELL YEAH.

The problem is that JIRA is a powerful tool that is often misconfigured or otherwise made to suck more than it should.

For example on one of my current projects, both JIRA and confluence are put behind malfunctioning SSO meaning you have extra annoying steps that sap your energy and will every time you open them. And then you have to face that someone made a royal mess in it and we have to deal with it - without access to settings to fix IT. And the final nail is that effectively we can't use any external integration, because it's all blocked, including just using the API on your own.

Now, if I had the power of administrator there...

We would have better work flow, with automation supporting human overrides.

We could link issues with our Github Enterprise and use local clients (org-jira, gojira, etc) as well as a bit integration in MS Teams.

And I would fix login so that accessing JIRA or Confluence didn't feel me with annoyance of "where is that fucking RSAID" and "goddamn fix MFA already"

In some cases they could and in some cases they couldn't. For a particular example, in fintech development a bunch of formal ceremonies are non-negotiable, you need to track, document and query who ordered, developed, built and tested what and why and has a change request been formally approved by someone who has the authority to do so. In other cases, the formality is optional, but it's still a choice the organization has made.

However, in any case it's not a technical discussion about tools, that would be putting the cart ahead of the horse, it's about organizational change, which tends to be as slow and difficult as a rewrite of a technical product. If the organization chooses to have a particular process, then they'll switch tools if needed to support that process; and the fact that they could use a more conenient tool if they would choose less formality and less formality does not carry much importance, that choice is determined by other factors.

Conway's Law seems relevant here, but I don't think I've seen (or seen the desire for) it to be used aspirationally, like "we need to become the kind of company that operates with these complex tool systems).

We undertook a migration from not-JIRA to JIRA. Our previous issue tracker would let us have the same task in different columns on multiple boards. You could do your investigation, post your comment, reassign to the reporter, and move it into your "waiting" column. Then they would move it into their "in progress" column, do their piece, and get back to you. A complex cross-org issue might show this cycle 5+ times.

In JIRA it is completely impossible. A task has one project and one status. You're lucky to have view and comment rights on another team's task, forget about change-status or reassign. An admin can "move" an issue but then it's gone from your own world.

The net result: the issue tracker is no longer a communications medium, but a paper trail for the bean-counters, where you laboriously log conversations and decisions that actually occurred by email or Slack. There will be a JIRA corresponding to any give issue, but reading the JIRA will not tell you the story anymore.

That sounds interesting, what issue tracker did you use before?

It works well for simple stuff too. You can just _not implement_ a complicated workflow.