Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "shitty jira tickets"
-
Welcome back to practiseSafeHex's new life as a manager.
Episode 2: Why automate when you can spend all day doing it by hand
This is a particularly special episode for me, as these problems are taking up so much of my time with non-sensical bullshit, that i'm delayed with everything else. Some badly require tooling or new products. Some are just unnecessary processes or annoyances that should not need to be handled by another human. So lets jump right in, in no particular order:
- Jira ... nuff said? not quite because somehow some blue moon, planets aligning, act of god style set of circumstances lined up to allow this team to somehow make Jira worse. On one hand we have a gigantic Jira project containing 7 separate sub teams, a million different labels / epics and 4.2 million possible assignees, all making sure the loading page takes as long as possible to open. But the new country we've added support for in the app gets a separate project. So we have product, backend, mobile, design, management etc on one, and mobile-country2 on another. This delightfully means a lot of duplication and copy pasting from one to the other, for literally no reason what so ever.
- Everything on Jira is found through a label. Every time something happens, a new one is created. So I need to check for "iOS", "Android", "iOS-country2", "Android-country2", "mobile-<feature>", "mobile-<feature>-issues", "mobile-<feature>-prod-issues", "mobile-<feature>-existing-issues" and "<project>-July31" ... why July31? Because some fucking moron decided to do a round of testing, and tag all the issues with the current date (despite the fact Jira does that anyway), which somehow still gets used from time to time because nobody pays attention to what they are doing. This means creating and modifying filters on a daily basis ... after spending time trying to figure out what its not in the first one.
- One of my favourite morning rituals I like to call "Jira dumpster diving". This involves me removing all the filters and reading all the tickets. Why would I do such a thing? oh remember the 9000 labels I mentioned earlier? right well its very likely that they actually won't use any of them ... or the wrong ones ... or assign to the wrong person, so I have to go find them and fix them. If I don't, i'll get yelled at, because clearly it's my fault.
- Moving on from Jira. As some of you might have seen in your companies, if you use things like TestFlight, HockeyApp, AppCenter, BuddyBuild etc. that when you release a new app version for testing, each version comes with an automated change-log, listing ticket numbers addressed ...... yeah we don't do that. No we use this shitty service, which is effectively an FTP server and a webpage, that only allows you to host the new versions. Sending out those emails is all manual ... distribution groups?? ... whats that?
- Moving back to Jira. Can't even automate the changelog with a script, because I can't even make sense of the tickets, in order to translate that to a script.
- Moving on from Jira. Me and one of the remote testers play this great game I like to call "tag team ticketing". It's so much fun. Right heres how to play, you'll need a QA and a PM.
*QA creates a ticket, and puts nothing of any use inside it, and assigns to the PM.
*PM fires it back asking for clarification.
*QA adds in what he feels is clarification (hes wrong) and assigns it back to the PM.
*PM sends detailed instructions, with examples as to what is needed and assigns it back.
*QA adds 1 of the 3 things required and assigns it back.
*PM assigns it back saying the one thing added is from the wrong day, and reminds him about the other 2 items.
*QA adds some random piece of unrelated info to the ticket instead, forgetting about the 3 things and assigns it back.
and you just continue doing this for the whole dev / release cycle hahaha. Oh you guys have no idea how much fun it is, seriously give it a go, you'll thank me later ... or kill yourselves, each to their own.
- Moving back to Jira. I decided to take an action of creating a new project for my team (the mobile team) and set it up the way we want and just ignore everything going on around us. Use proper automation, and a kanban board. Maybe only give product a slack bot interface that won't allow them to create a ticket without what we need etc. Spent 25 minutes looking for the "create new project" button before finding the link which says I need to open a ticket with support and wait ... 5 ... fucking ... long ... painful ... unnecessary ... business days.
... Heres hoping my head continues to not have a bullet hole in it by then.
Id love to talk more, but those filters ain't gonna fix themselves. So we'll have to leave it here for today. Tune in again for another episode soon.
And remember to always practiseSafeHex13 -
Another day, another shitty set of JIRA tickets.
In this week's edition, we run into an issue you'd think is a meme, something you couldn't even make up: three tickets with IDENTICAL titles, but miraculously, they actually refer to three DIFFERENT tasks! (Also comical, they're not bugs, they're tasks, but mouth breathers don't really know the difference, and at this point I just don't have the energy to attempt to explain what could be explained to elementary school children.)
I present a rare look into our national archives!
This document features two exhibits:
Exhibit A: product owner's original ticket titles
Exhibit B: translated-into-competency-because-i'm-not-mentally-deficient ticket titles
Just more proof that 'product owners' don't own shit, the devs are the real ones who actually know what is going on.
I mean just LOOK at Exhibit A's titles. As a big smart manager, do you write those tickets, smile, and say to yourself "Ah, yep, that's very clear, I'll definitely remember what each of these mean literally 5 seconds from now!"
Is asking for literally 30 seconds more of thought too much to ask for? Apparently.
Just kill me
Happy friday ☠️7 -
Fuck it, fucking fuck it.
Consulting company, been here for 2 years, had some decent projects (surprise, only those that me and my coworker started from scratch), but OMG the fuck ton amount of bizarre code I've seen is just mindblowing.
Everytime I start on a project, spend days improductive because the stack won't fucking work.
We use some frameworks, but the creators of the projects said fuck it, why would we follow the framework guidelines if I can create a supersmart way that nobody fucking understands way of doing things. I mean, It will look smarter and so nobody else can touch this shitty code.
I hate that the most praised developer is the guy that created most of this shit, and his nº 1 skill is moving Jira tickets to the correct state, tracking time (PM's love this, I hate it) and blocking my fucking merge requests because I left an extra blank line, dangling comma or whatever the fuck else, he's like a human linter.
Dude, the code is a piece of shit, my dangling comma is not going to be the problem! And if you really care that much, setup a linter or something.
Fuck this, I'm quitting this week.3 -
Fuck you Jira, for your shitty implementation of the board, which causes written comments in tickets to simply disappear.
You clicked on another comment during edit? Say goodbye to what you have just written!
You clicked on the send button to send your comment? Well, many things can happen with our overcomplicated pile of shit that we call Jira. So, your comment might get lost. Fuck you. We are complicated. This shit can happen. Deal with it.2 -
We often give access to a product owner from the customer on our Jira to keep up a good communication and everyone stays up to date as everything is on the board and not hidden in emails or paper notes on the desk of the guy that is on vacation.
So far, so good
Our customers really like this as they can comment on tickets and they are integrated in the workflow because they can push into the backlog and can review finished tasks.
It is just getting better for everyone so where is the rant?
One project is just a dump of shitty mixed content tickets. But how? They look really neat. There are tickets like "fixes from meeting 20th of may" which are initially well structured with approximately 4 subtle changes to the UI and some explanation and screenshots.
PM says: Good ticket. There you go ticket, into the customer review loop of doom.
20 comments and 13 status changes later. Point 43 from comment 17 is referenced in comment 20 to keep on hold as a third party needs to give feedback, point 7 is still not solved correctly as dev 2 was not aware that it was already discussed and changed in the ticket "Call from 25th of may" where in addition the resolution of points 5-12 were requested with an additional excel file to import.
By now we have the 8th of august and literally 17 of these kind of tickets.
I guess we need to improve the workflow and request a new product owner. But this far I just table flip everytime I get one of these tickets assigned.2