Item — HN Reader

There are a lot of engineers on HackerNews who have had terrible experiences with Jira (I'm one of them). You're correct, you don't have to migrate; However, if you work at a company where management all of a sudden realizes — "oh now we can integrate Jira for our tasks". It's a slippery slope down the Jira road.

I've had 3 jobs where we used Jira and it was always a nightmare. At Uber ATG it sucked because it was slow, extremely confusing, managers didn't know how to use it, engineers didn't either, it wasn't integrated into any developer tooling, and there was no dedicated Jira engineer so it just slowly wasted away. At Amazon, same story as Uber ATG, but we had a dedicated engineer, yet somehow it was still slow. At this startup called Attensity, it was the exact same story as Uber.

I've seen Jira work for other things that aren't software engineering related, where it seems like tolerances for crappy software are higher. We use Jira for creating tickets for new computers or requesting access to certain recourses. Those things are fine because they aren't really sprint related — it's more like a fancy to-do system with time stamps. However, if you're on the building and landing software train — nobody want's to hear the word Jira.

3 comments

Somewhere along this thread it became an indictment of Jira. I've spent a tonne of time over the years at multiple orgs both using Jira and trying to move away from it. 10 years later.. I'm back on Jira and won't move.

The issues I find (including speed) are really due to the incredibly flexibility of Jira, and things not being thought out by users. Ultimately, I feel like it's akin to the old adage about perl - it does everything including giving you the rope to hang yourself.. it's up to you if you hang yourself. That plus all my friends who insist one needs a PhD in Jira, to Jira... but I digress.

We're set up appropriately with issue types, differentiation between issues, bugs, tasks, (and our version of etc). We can plan sprints locally and remotely, and have all our dashboards and friends immediately update. Integrated (sanely) with confluence we get retrospectives, historic reports. We create bugs, move their states, deal with Agile and Kanban, have histories... the whole deal. To reduce the inherent pain in dealing with bug creation because it generally sucks, we have a slack integration I wrote to: a. Create a bug b. When you type ISSUE-ISSUE# into a channel, the robot picks up and gives us all the subject.

The combination above removed all friction. The one thing I wish would happen from a workload perspective is that when a PR is pushed upstream to bitbucket, for a branch matching an issue - the issue would move to the Code Review state. But that is our only point of friction, and one day I'll get off my rear and make our robot do it.

Such transition mechanism sounds like 'smart commit'[0] but attached to PR instead? Isn't simpler to just trigger transition directly from commit?

[0] - https://confluence.atlassian.com/bitbucketserver/using-smart...

Definitely would be, thanks!

What? I have used and i'm using jira for probably 7 years in 3 different companies with 6 different projects.

I always took care of our workflow and small issues by the side. Once configured properly (which has nothing do to with magic) it works as advertised.

there are a few small issues but not that relevant in daily life.

We used atlassian online service and on premise.

I would love to meet you and introduce you to any manager I have in the future (because I"m sure Jira will be reintroduced in my professional career). What were you using Jira for? Are you an engineer committing code daily? What style do your projects usually follow (waterfall, agile, etc)? What source control tracking do you use with Jira? Were you doing burndown charts?

I'm an engineer. Writing code but also doing code review.

I worked with jira and scrump but the last two years I introduced kanban. But those projects have a high level of uncertainty and supportrequests. Which just makes it hard to finish a Sprint.

Always git. Git with GitHub.com, on premise GitHub and selfhosted gitlab.

I do use the reporting Features. It is nice to see the progress. Seeing the backlog shrinking and also the time on how long a ticket is in progress. It helps a little bit of keeping priorities. It also helps showing the management why stuff takes as long as it takes. Especially unplanned work.

Working with Jira and Bitbucket and loving it all the way. We spend some extra time on configuration and learning people how to work with it. Sounds like they havent done any of these things.