Jira is popular and has good API wrappers for your favorite language. I'm surprised corporate programmers with the hacker spirit haven't automated most of the things they are asked to do in Jira with Python command line scripts or whatever.
If you can make Jira an order of magnitude easier to use for yourself than for the people pushing it, suddenly the script flips and Jira is something you push to protect yourself. I've used Jira to almost a malicious extent at times, and it's a great tool to cover your ass. If you ever get in trouble for something you just point out "this was all made clear in the hundreds of Jira updates I've written, you've been reading those, right?". What are they going to do? Ask you to use Jira less?
We have AI now. Hook it all together with a custom script and have the AI do all the Jira crap for you.
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.
And many times the API can do stuff that the UI doesn't allow, and everyone's relying on the UI to drive things, so you end up in weirdly broken corners because you didn't notice that you need custom_field_5537 to be paired with custom_field_442 or it doesn't appear on anyone else's dashboard. Also it claims custom_field_10995 is an integer type field, and returns as integers in the XML, but there's a pile of undocumented magic constant strings that you have to use instead when creating (but not updating!) a task or you get useless error messages. The web UI doesn't do this though (it's just integers in html and the request), and only 80% of the strings match the display text in the dropdown.
Automating Jira is the absolute worst programming experience I've ever had. I can completely believe that simpler setups exist and they're probably quite easy, but omfg.
Sadly it's still completely worth the effort. Highly recommended.
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!
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."
Our entire company is basically ran through Jira. Most processes rely on Jira and certain transitions fire of webhooks for automation.
One of the first things we did when we got access to AI was make a Jira MCP. I try not to touch Jira anymore. I get Claude to just create the Jira issues, write comments, create subtasks, link issues together, etc.
I used to dread having to investigate how to implement something and break it down into tasks because the more granular I broke things down, the more Jira issues I had to create to capture each task. Now I can just write everything up in a file and send an LLM to do all the Jira crap.
Our main problem is only that they are hijacking the prices incredibly.. Lately we had to cut the number of licences and users, since it was incredibly expensive.
I particularly like the hike between 10 users and 11, some startups begin with 5 people and when they reach more than 10 employees they are hit with the licence costs
> Hook it all together with a custom script and have the AI do all the Jira crap for you.
As if the bloat on Jira isn't big enough already. Adding more text will make it even slower since it will somehow automatically run everything over all that text all the time. If you need heating at your company, use Jira.
I came back to a workplace, that still used JIRA. Obviously during the interview I was like oh JIRA yeah yeah yeah you still use that? I can use that.
Anyway yes, I can use JIRA. But it was a real shock to see the latest version of JIRA. It has a thousand papercuts, one of the worst is double clicking on text select stuff suddenly kicks fields into editor mode.
What I was remembering was JIRA Server 4.0, you can walk down memory lane here* - zoom in enough and you'll see each issue has a title, type, fix version, affects version, and so on, and then you end up going straight to the comments. Very straightforward.
I love Jira automations. Whenever I start on a new team using Jira, I go in and set up automations that do things like auto-count the subtask story points to fill the parent task's story points, or automatically move tickets to backlog if they don't have fully refined properties (missing user assignment, missing story points, missing priority, missing description, etc). In one sprint the team has a more organized board. Dunno why they're not the defaults, but easy enough to fix with automations.
I think at least 60% companies that use Jira could do better with just Trello. I dont know how it is possible to create such a horrible mess with task manager and some reports. But it probably keeps the managers and POs bussy so :D
This is true because Trello uses simplicity as a constraint, so users can't make quite as big a mess. They can still make a mess though and as a source of truth it still requires people to move things properly, so it isn't really any better. All project tracking applications suffer from the same ultimate root cause of problems: users.
Jira is the one product I feel needs to be AI native.
AI native in the sense that it papers over the pain points.
New JIRA admin? AI will set it up to do what you want (after all, Atlassian has a great training set as they can see which Cloud installs work well)
Need to set up a workflow? Bam, AI to do that.
Need to onboard a user or manage permissions? Again, have a chatbot to do it (as a time-to-time Jira standin Admin, changing permissions always needs doing in 2+ places and devolves into a "Can you see this yet?" round of questions)
I don't think so. First, JIRA is not orchestration. Second, all workflow needs to do is associate some status with external information, and make it easy to manipulate those. You need triggers and rules, some thing like infinite counters, two stacks, a bidirectional tape, etc.
Not surprising if you've worked with their automation flows in-depth before. What's surprising is how awful their automation flow tools are to work with. Feels like programming in assembly to accomplish what you want.
It can’t be because in order to administer Turing test the system has to be usable straight away. This system requires extensive training and specific knowledge and
steps for that.
Jira is popular and has good API wrappers for your favorite language. I'm surprised corporate programmers with the hacker spirit haven't automated most of the things they are asked to do in Jira with Python command line scripts or whatever.
If you can make Jira an order of magnitude easier to use for yourself than for the people pushing it, suddenly the script flips and Jira is something you push to protect yourself. I've used Jira to almost a malicious extent at times, and it's a great tool to cover your ass. If you ever get in trouble for something you just point out "this was all made clear in the hundreds of Jira updates I've written, you've been reading those, right?". What are they going to do? Ask you to use Jira less?
We have AI now. Hook it all together with a custom script and have the AI do all the Jira crap for you.
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.
And many times the API can do stuff that the UI doesn't allow, and everyone's relying on the UI to drive things, so you end up in weirdly broken corners because you didn't notice that you need custom_field_5537 to be paired with custom_field_442 or it doesn't appear on anyone else's dashboard. Also it claims custom_field_10995 is an integer type field, and returns as integers in the XML, but there's a pile of undocumented magic constant strings that you have to use instead when creating (but not updating!) a task or you get useless error messages. The web UI doesn't do this though (it's just integers in html and the request), and only 80% of the strings match the display text in the dropdown.
Automating Jira is the absolute worst programming experience I've ever had. I can completely believe that simpler setups exist and they're probably quite easy, but omfg.
Sadly it's still completely worth the effort. Highly recommended.
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!
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."
Sounds like the IOCCC[0] of APIs
[0] https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod...
Our entire company is basically ran through Jira. Most processes rely on Jira and certain transitions fire of webhooks for automation.
One of the first things we did when we got access to AI was make a Jira MCP. I try not to touch Jira anymore. I get Claude to just create the Jira issues, write comments, create subtasks, link issues together, etc.
I used to dread having to investigate how to implement something and break it down into tasks because the more granular I broke things down, the more Jira issues I had to create to capture each task. Now I can just write everything up in a file and send an LLM to do all the Jira crap.
moved to Jetbrains YouTrack many many years ago, and this is what we do via its APIs. It's quite versatile. With AI, it unlocked it even more.
Our main problem is only that they are hijacking the prices incredibly.. Lately we had to cut the number of licences and users, since it was incredibly expensive.
I particularly like the hike between 10 users and 11, some startups begin with 5 people and when they reach more than 10 employees they are hit with the licence costs
> Hook it all together with a custom script and have the AI do all the Jira crap for you.
As if the bloat on Jira isn't big enough already. Adding more text will make it even slower since it will somehow automatically run everything over all that text all the time. If you need heating at your company, use Jira.
> corporate programmers with the hacker spirit
that thing does not exists
I came back to a workplace, that still used JIRA. Obviously during the interview I was like oh JIRA yeah yeah yeah you still use that? I can use that.
Anyway yes, I can use JIRA. But it was a real shock to see the latest version of JIRA. It has a thousand papercuts, one of the worst is double clicking on text select stuff suddenly kicks fields into editor mode.
What I was remembering was JIRA Server 4.0, you can walk down memory lane here* - zoom in enough and you'll see each issue has a title, type, fix version, affects version, and so on, and then you end up going straight to the comments. Very straightforward.
* https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
That explains why it's impossible to tell whether any given Jira operation is going to halt or not.
Jira is completely awful and thus has the potential to take on any other form of awfulness.
Or is it Awfully-Complete? :)
Jira is the ultimate example of the concept of alienation. If Marx knew about Atlassian the Grundrisse would have been insanely lit.
Woof. JIRA is so slow, and managers never seemed to set it up correctly. I have trauma from using it!
I love Jira automations. Whenever I start on a new team using Jira, I go in and set up automations that do things like auto-count the subtask story points to fill the parent task's story points, or automatically move tickets to backlog if they don't have fully refined properties (missing user assignment, missing story points, missing priority, missing description, etc). In one sprint the team has a more organized board. Dunno why they're not the defaults, but easy enough to fix with automations.
I think at least 60% companies that use Jira could do better with just Trello. I dont know how it is possible to create such a horrible mess with task manager and some reports. But it probably keeps the managers and POs bussy so :D
This is true because Trello uses simplicity as a constraint, so users can't make quite as big a mess. They can still make a mess though and as a source of truth it still requires people to move things properly, so it isn't really any better. All project tracking applications suffer from the same ultimate root cause of problems: users.
it's actually easy to be turing complete. it's a feat for a system to be non-turing complete and be "complex".
Jira is the one product I feel needs to be AI native.
AI native in the sense that it papers over the pain points.
New JIRA admin? AI will set it up to do what you want (after all, Atlassian has a great training set as they can see which Cloud installs work well)
Need to set up a workflow? Bam, AI to do that.
Need to onboard a user or manage permissions? Again, have a chatbot to do it (as a time-to-time Jira standin Admin, changing permissions always needs doing in 2+ places and devolves into a "Can you see this yet?" round of questions)
Can't wait to run DOOM on it
All workflow and orchestration engines are Turing complete, the whole purpose is to automate execution flows.
How many of them can run infinitely? Or be re-triggered by humans to continue where they left off?
Depends on how you code the workflow and transition state triggers.
I don't think so. First, JIRA is not orchestration. Second, all workflow needs to do is associate some status with external information, and make it easy to manipulate those. You need triggers and rules, some thing like infinite counters, two stacks, a bidirectional tape, etc.
Prove me wrong!
Yes, and the rules engine is there when creating custom workflows.
https://developer.atlassian.com/server/jira/platform/creatin...
I also explicitly mentioned workflows on my comment.
You implied all workflows, not just Jira.
And I stand by it, naturally it depends on the specific workflow engine how those features are exposed.
Then we can split hairs about which one don't really support it, so that you want win Internet discussions about all not being all.
Not surprising if you've worked with their automation flows in-depth before. What's surprising is how awful their automation flow tools are to work with. Feels like programming in assembly to accomplish what you want.
What annoys me about Atlassian products (Jira, Confluence) is the long load times and terrible layout shifts:
you never know if the layout is about to shift ever so slightly more causing another in a series of misclicks.
Oh how many times I've accidentally assigned a newly created ticket to some poor fella I'd never even seen before...
Any good alternatives to Jira, locally hosted without a huge licence cost?
https://www.openproject.org/blog/open-source-jira-alternativ...
I haven‘t used it myself, though
Even more nauseating than https://brainfuck.org
It can’t be because in order to administer Turing test the system has to be usable straight away. This system requires extensive training and specific knowledge and steps for that.
The Turing test is to test whether a programme exhibits intelligence.
Turning complete is a measure of whether something can be used as a programming language to run as a universal Turing machine.