upvote
A dysfunctional organization will project its failures to everything it touches. I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process. Nowadays, I opt in for Atlassian because it works fine out of the box, I avoid heavy customization (which would mean tool lock-in), and Claude can move the tickets itself anyway - no scripting required.
reply
“ I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process”

I work in medical devices and our Jira is a mess too. Seems a lot of people try to solve process problems by customizing Jira.

reply
„Every organization thinks that they are unique, yet they all are doing the same thing“ (a quote I heard last time from an SAP consultant, which is probably a common knowledge or some named law).

This is the funniest thing about customization of enterprise products. They spent hundreds of years on user research and product development, so chances are high that their standard solution is sufficient for your problem, and you don‘t need anything else. Yet too many people are tripping on the hard problem of enterprise products: the custom fields, which they hardly even need.

reply
I find the problem is that engineering wants one work flow, product wants another, another department wants theirs, and so on.

As a CTO I have declared that Jira is owned by engineering and it is our developers’ process.

reply
Sounds… political. You have cross-functional teams interfacing via a tool. It would be reasonable to co-design this interface, so that all user goals are taken into account. When engineering owns the tool, do they approach the configuration of JIRA the same way as they build the product?
reply
We approach tickets that match with our development strategy. A ticket is tied to and represents a branch of code. When that code is merged the ticket is done. It cannot be reopened, you open a new ticket and link it and there will be a new branch.

I know everything that is in our main branch by looking at jira.

Product mangers and executives often want a very different view or workflow and it is hard to bend jira to work for everyone. Jira would need to have things like parallel workflows on a ticket and that would just get confusing and complicated.

reply
A colleague of mine said it even better, its like an old blanket filled with patches, small fixes and workarounds, so much that no one even remembers to how the patching was done ages ago!
reply
The funny thing is that Atlassian themselves uses “custom fields” so it’s not even clear which are actually org-specific. The new JSM uses a lot of them, for example. It smells like things got so convoluted internally that even first party features are just velcro’d on top.
reply
Yeah I had the exact same experience. What values does `custom_field_836` need when creating an issue? It seems to be required in the API but not in the UI, and feeding a value returned from an existing issue doesn't work!

It's the API equivalent of formatting a document in MS Word.

reply
Simpler setup is perhaps - have a the pm-informed list of req of what your teams' needs and habits, and implement from scratch. Perhaps would take less than customizing JIRA. With history and all.
reply
Sure, just gather all requirements upfront and hope they never change. Customers know what they want /s

If it was about the ticket system, it'd be solved already. But it isn't.

reply
Reminds me of automating FiServ in VBA. Omfg, but still worth it.
reply
I just had a thought: is there some API so obscenely baroque and painful to use that even AIs would flatly refuse to work with them?

It would be an interesting exercise to keep feeding a coding agent ever crazier interface designs until it cracks.

“The base64 of the rot13 encrypted EBCDIC string has to be included in a JSON in the XML SOAP request, but both the JSON and XML escaping is manual and incorrect...”

"...but first split the string into chunks no bigger than 64 bytes and spread the request amongst HTTP headers instead of the POST body. Reassemble by trying every possible ordering until one passes the decoding steps."

reply
AIs can barely handle PKCE OAuth flow. It’s not very hard to confuse them.
reply
deleted
reply
deleted
reply
that's nearly a requirement for anti-bot things. turnstile etc.
reply
>I just had a thought: is there some API so obscenely baroque and painful to use that even AIs would flatly refuse to work with them?

Copilot Studio. It's painful to try to set up any sort of logic within Copilot Studio. Worse if you're not on the most bleed-edging-new machine with overkill levels of ram. So I had a thought... why am I doing this when I have Claude with absolutely no quotas?

Turns out, there's just no way to drive it from Claude. It first started with the pac command line tool, but that's agonizingly broken. Tried to use Chrome next, but even it can't navigate that UI from the browser (neither could I, you'd click and sometimes the response occurs 10 seconds later). Copilot Studio is the quintessential Microsoft technology. Shortly after, Claude began experiencing what I can only call schizophrenic symptoms. It imagined that every time I queried it that there were embedded hacking attempts in my reply and that soon spread to every conversation I had with it even in new chats.

reply
It is kind of ironic that the AI building tool is so hostile to AI. Copilot studio really is a hot mess, at least for me.
reply
I’ve been trying for the last few weeks to get a really solid local model workflow going, and every single tool I use feels hostile af, whereas the stuff work pays for, it all “just works” together. It really irritates me.
reply
> Quite a few have, the issue is that every Jira instance is a fractal shit snowflake of custom properties several layers deep through old failed migrations to new organization strategies.

This is key, Jira is fantastic so long as you have an angry commissar enforcing discipline, otherwise its a total free for all wasteland.

reply
I am not using JIRA anymore but I guess in 2026 you could write AI wrapper around clicking on UI elements?
reply
The Jira API is less fragile than this, you will still have to change major things to your script when someone adds a field.
reply
"fractal shit snowflake of custom properties several layers deep through old failed migrations to new organization strategies."

Couldn't have said it better

reply