NHacker Next
- new
- past
- show
- ask
- show
- jobs
- submit
login
Rendered at 13:26:58 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
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.
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.
As a CTO I have declared that Jira is owned by engineering and it is our developers’ process.
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.
it is not, as long as focus is on goals rather than on solutions (applies to everything). Nobody needs a view or a workflow. Everybody has jobs to be done. That is the starting point in process design.
It's the API equivalent of formatting a document in MS Word.
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."
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.
[0] https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod...
This is key, Jira is fantastic so long as you have an angry commissar enforcing discipline, otherwise its a total free for all wasteland.
If it was about the ticket system, it'd be solved already. But it isn't.
Couldn't have said it better
Like adding a custom text field to each ticket with a human description of what a ticket did which someone would fill out along with a timestamp that got auto-filled out when a release shipped (deploy script). We'd release 1 ticket at a time as a line of work (many tickets per day). This combined with custom filters resulted in Jira providing us a human readable changelog for each board and the whole company. These messages were Slacked to the business so everyone had a pulse on what was going live. It was also a searchable audit log of all releases, tying back to a code change.
The deploy process also transitioned Jira tickets so a developer never had to do anything more than merge a ticket to main to have it get deployed and completed on Jira.
Lots of little scripts that automatically created tickets for routine tasks, etc..
It was super solid for years and I'm going to guess it's still running today. The naming conventions of the custom fields were lame but if your team is in control of setting up Jira, it wasn't hard to keep everything on the same page.
I started off not liking Jira and it had a lot of issues many years ago but it's actually not that bad nowadays once you set it up. I wouldn't choose it for my own company but as a developer and someone who has administrated it, used it as an end user and developed against it for internal tools, it mostly gets out of your way once it's configured and working.
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.
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.
* "Corporate hackers" is a... not a very common thing. In the corporate world most programmers do what they are told to do and nothing more. Initiative is punishable.
* API wrappers aren't actually good. Not to mention that the API itself is very poor. JIRA has a tradition of arbitrary changing things, especially removing things, or not exposing the useful functionality. It's not a well-designed or well-executed product.
* AI is too immature and too non-deterministic to be useful for most of the things you want from a bug tracker. Also, for most companies, it's going to be too expensive to do it this way.
* QA is usually an afterthought, unless... we are talking about budget cuts and cutting corners, then it's left, right and center. Most companies see QA as a liability. They don't see it as producing value. They just have to pretend to have QA so that they can tell their customer they have it. When it comes to making QA do meaningful things, that require hiring good engineers, allocating development time, allocating compute resources... well, good luck with all that! Most QA I've seen, especially in international huge corporations was all for show, to produce appearance of work while following the same, mostly useless and mostly manual process.
I had a bunch of ideas about how QA can be made more efficient, both in terms of resource use and in terms of problem space it tries to address. Doing things like RCA automation or exploratory dynamic* testing... and after trying to see if any of such ideas would have any luck of becoming an actual successful product, I realized that nobody wants to improve QA. If a product made the "certification" (the ability to claim to have tested the product) cheaper, then it could be viable... but this is neither the direction I wanted to go, nor is it really all that feasible to improve a bug tracker in this direction.
----
* What I mean by exploratory testing is a sort of "fuzzing", however one that's more structured. Fuzzing, typically, is applied to the input, which then tries to explore all possible ways through the program under test. Exploratory testing is a test made up of modules that can be combined to produce longer tests. This addresses the problem of difficult to reach "corner" cases in the program, also the problem of reaching code paths that aren't directly (or at all) dependent on input.
It's amazing how far just a little bit of programming can
So it's a world where it's not just that one wants simple automation for ticket creation, but you might want to ask an LLM to update it. Dear Claude, I need to put a request with team X. I know John Doe works there. Please figure out what the hell their intake looks like, and what we have to fill out for the last few sprints and write it down, because I sure don't have time for this.
That's because corporate IT makes the tokens expire every 2 seconds so scripting becomes useless.
Seriously we have some tokens that expire every 1 hour.
Not a single of the many organisations that I worked for which used JIRA would give the credentials to do anything of this sort.
that thing does not exists
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...
Hold up, did I miss something? Fall into a time hole? Why are we talking about Jira like it’s Visicalc? Not currently working for an IT company, so maybe I missed something cataclysmic in the past two years…
Asana, Notion and Linear have major penetration in small companies.
Jira is usually pushed by more corporate types who want to “control” what gets done, not understand it.
Well one of the problems anyway. It's also unimaginably slow, and has weird limitations like issues can't be parents of other issues.
Given a highly configurable system, users will find ways to (unintentionally) tie it into knots, so adding some guardrails can help reduce complexity demons down the line (both in the technical implementation and the user experience).
I guess I prefer to give people making things the benefit of the doubt.
Based on the rest of Jira, it's definitely not that!
I guess that the ability to toggle recursion on or off might be helpful.
By far and away, linear.
The task tracking features you actually use, it’s fast, you don’t waste a billion years playing “who knows how to do this and has the permissions hell” that you would with Jira. The integrations work properly. The layout and UX makes sense, and all the nontechnical people I’ve used it with liked it and had no issues with it.
Not whatever abomination Atlassian targets.
Linear is quite seriously one of the best products (in any category) I’ve ever used.
They have a first class MCP server, and you can basically run a project from your agent. Implementing something, and you find out there's more to do later on in a separate issue? Agent creates the issue for you and off you go. It works very nicely, and also has a great UI but I mostly using it from my agent.
It came with its share of paper cuts too, like going from 4.x to 6.x or literally anything challenging to the rickety boxes of OFBiz and wholly-different products skinned for looks-maxxing.
Those engineers dipped out a while back and took their $280 shares with them.
1. All the checks it has to do to see if there are relations between tickets, states, triggers, actions, reports, etc.
2. Accessing separate subsets of data for each ticket from different locations and bringing it all together (epics, sprints, user lists, comments, reactions, linked issues, linked PRs and branches, etc)
3. The code is apparently a complete dumpster fire, from what I've heard from people at Atlassian.
Prove me wrong!
https://developer.atlassian.com/server/jira/platform/creatin...
I also explicitly mentioned workflows on my comment.
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.
Because there is no software in the world that Microsoft can't make worse.
Many moons ago, in like Office 2003 times, I used Outlook as well, and I don't remember it being this bad. How did it regress so badly?
Don't even get me started on Teams - I don't really know what problem that program is supposed to solve. Also our shared files are in OneDrive. But they're also in Teams. And they're also in Outlook for some reason. I had to transfer a bunch of computer backups (CloneZilla images) to OneDrive/Teams/Outlook. About 30 or so GB. It took forever, and my 6-core Ryzen laptop with Win11 was spinning its fans like mad the entire time. How? Why?
The number of times at my last job I had to tell someone to re-send me an e-mail because Outlook search couldn't find anything with "GitLab Upgrade" in the subject line (let alone the twelve message thread it was part of) was staggering.
Also, my most hated functionality in Outlook: distribution groups (or whatever they call them). Instead of saying "devops@corp.com forwards to this list of people", you say "Devops is this group of people", so when you send an email to "Devops" it goes to all of those people. Sure, great.
Except that it means that you can't filter by that. Saying 'Devops' is just shorthand for saying "This guy, this guy, this guy, and this guy" explicitly. If you say "e-mails sent to Devops" Outlook interprets that as "e-mails with any of this group of people in the To or CC field", meaning that Outlook filters couldn't distinguish between "e-mails sent to me" and "e-mails sent to my team". Since I almost always had someone from my team CC'ed on e-mails I sent, it meant that my "e-mails sent to Devops" filter just matched every e-mail coming or going.
It ended up being that the alerting and monitoring e-mails we got I was only able to filter because the relevant tools put various headers into the e-mail (like X-Nagios-Alert or whatever) or they came from specific e-mail addresses (which was not always reliable but was often reliable enough).
But it remains unread until you open another email and read it ... and only then, not immediately but after like 1-2 seconds, the previous email gets marked as read ...
Why?
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...
I was actually surprised they offered such simple options. Of course the complexity is there, the moment you start wanting an extra column, you're in the rabbit hole.
Jira is absolutely huge, so it's hard to tell what parts of it you're interested in.
I haven‘t used it myself, though
Can be easily extended and unneeded fields can be disabled via template.
We use it since 20 years at a 6000 heads company and it's totally fine.
Fully self-hosted, dockerized.
We made the pricing reasonable -- YMMV.
No you fool, don't you see? Now you're all going to going to be forced to learn how to code...in Project Manager BWA HA HA HA HA!
> A Minsky program that adds register A into register B looks like:
> 1. DEC A; if A == 0 goto 3 else goto 2
> 2. INC B; goto 1
> 3. HALT
If A initially equals 1 it will be decremented and hit zero; the conditional triggers, and the program halts without ever incrementing B.
...which suggests that Jira is a Turing tarpit in which even the simplest programs are immensely difficult to implement correctly. Who knew?
I'm saying that as a former ACE-certified Atlassian Consultant from a Platinum Partner. I'm much happier now.
If Atlassian actually fixed these papercuts their product would be better but they wouldn't be getting a cut of all subscriptions from the dozens of plugins people install to make it a usable tool.
We are going to chat about it on June 9 in an online Developer Event
Turning complete is a measure of whether something can be used as a programming language to run as a universal Turing machine.
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)
Giving an API key to Claude however gets you exactly what you need. Albeit in quite a risky way though.
Disclosure: I'm CTO of an ITSM product in this space (Siit), so I think about this a lot.
and they keep. adding. redundant. features
yes, but:
1. not anymore
2. That's the price you have to pay if you want the tool you like to have corporate buy-in
If you read other people's comments here though, this is not what Jira APIs look like. Instead you have cruft built upon cruft, ever increasing in complexity, and seemingly no engineer was allowed to look back and fix things, find good concepts to represent things on a lower level. Lets build more features, accumulating more cruft on top, instead of fixing a broken design.
So to get buy in to the tool you like, first you need to make it into a tool you don’t like? Why would you go after buy in to that tool?