141–150 of 160 posts
Earlier quoted context omitted.
The engineer is not the target user
> The engineer is not the target user 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
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?
Jira is the best way to destroy morale.
Earlier quoted context omitted.
I don't think JIRA is fully capable of being truly awful without people adding most of the awfulness to it. A awfulness-vessel rather than awfully-complete, but it is certainly part of the torment nexus humanity is building for ourselves.
I like to think of it as a Torment Nexus SDK. Start with a punishing UI (the web UI work and become unresponsive frequently, always wait at least 1.5 s before responding to interactions, etc.), add infinitely customizable bureucratic rules on top, and then make people's jobs dependent on making the numbers go up in the correct manner.
This appears bugged: > 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 cor…
Earlier quoted context omitted.
Yeah the slowness is what always gets me. Like in essence a ticketing system isn't more than just a database of tickets and relations between tickets and states. And okay you can kinda make it explode by having tons of interconnected tickets and custom fields and plugins. But I will never understand how something that just works with simple textual data and attachments can be so unbearably slow.
Presumably it has to do with: 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 h…
Earlier quoted context omitted.
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 cust…
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.
Any software that breeds a consultancy culture around it is a software that has become too complex and should probably be broken up into or replaced by smaller, more manageable parts. 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.
Earlier quoted context omitted.
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?
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…
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.
Any good alternatives to Jira, locally hosted without a huge licence cost?
Jira is absolutely huge, so it's hard to tell what parts of it you're interested in.
Earlier quoted context omitted.
That version of JIRA could still easily be configured to be awful. That's the main problem with JIRA - the power to actually configure it to be sane is always reserved by a few people who don't want to bother, don't have time and don't care because they aren't really using it every day. Well one of the problems anyway. It's also unimaginably slow, and has weird limitations like issues can't be parents of other issues…
The non-existence or non-availability of recursive features, like an issue being parent of an issue, or in Slack a thread being started inside a thread and so on, to me usually indicates, that the developers of the tool are afraid of recursion, and have never learned how to implement this easily in a database, used a programming language that easily deals with recursion, and don't know how to deal with it in other la…
I guess that the ability to toggle recursion on or off might be helpful.