Every time I upvote a submission by the title without reading it I regret it, and this time is no exception. Some of the items don't even make sense as written. The fourth item, for example, has two huge issues. 1. It's about Confluence, which is a different Atlassian product. There's some Jira/Confluence integration, but they are not the same thing. 2. "you have to save the other user changes also and while viewing the confluence, if you want to edit, the user will be redirected to other pages." That sentence is gore.
Why Jira Sucks
281–290 of 530 posts
Re: Why Jira Sucks
#282Earlier quoted context omitted.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer…
If you use Atlassian's git-based Bitbucket you get the same thing. It's very much like what gitub would be if you asked a project manager to design it. But that's very much an IBM-like approach, where they entice you into buying additional software because of their walled garden.
Re: Why Jira Sucks
#283For us Jira became the only option for scaling engineering.
Do not bother about if you have less then 3-4 teams. But if you scale, essentially it is the only solution we found which can fit everyone needs, and give deep enough insights about engineering metrics. And obviously Jira can be very light or very complex. It gives you a lot of building blocks and it is your choice how to use it.
Re: Why Jira Sucks
#284Earlier quoted context omitted.
You are an assembly line robot.
I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots. Yes I'm an assembly line robot and…
Have done the same and it was glorious!
Re: Why Jira Sucks
#285Use Azure DevOps instead
Re: Why Jira Sucks
#286It looks like one of may marketing websites, in this case build by clubhouse or zeppel. And I'll be frank, clubhouse does not work at all for complex software projects. Maybe it can fit some web consultancies flows or similar, but it is build for VERY specific niche.
Re: Why Jira Sucks
#287Earlier quoted context omitted.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eye…
It's not valuable because then later a manager will still assign the work to another developer, who will spend almost the same amount of time trying to reproduce the bug and finding it fixed. This leads to several back-and-forth slack group slacks to figure out that it was already fixed, and decreases morale. It wastes as much time as if it weren't done at all.
Re: Why Jira Sucks
#288Earlier quoted context omitted.
What bothers me is if I use JIRA, why do I have a meeting every single day telling you what I'm working on. If you care, look at JIRA.
To discuss blockers and what you'll be working on that day. Also many engineers aren't good about updating tickets, ruining it for everyone.
I plan on working on the tickets assigned to me on that day, yesterday, and the next day. If I have blockers I'll type up a slack message. It's not that hard.
Re: Why Jira Sucks
#289To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
I disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't know how to think about that at all.
A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort.
More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables.
Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.
Re: Why Jira Sucks
#290Earlier quoted context omitted.
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eye…
It's not valuable because then later a manager will still assign the work to another developer, who will spend almost the same amount of time trying to reproduce the bug and finding it fixed. This leads to several back-and-forth slack group slacks to figure out that it was already fixed, and decreases morale. It wastes as much time as if it weren't done at all.
This is not how it happens in my experience. The other developer, who sees their teammate's daily updates and code reviews, would just say "oh this was fixed yesterday". The manager trying to assign work is a tedious redundancy here; the engineers do a better job of owning the problems if the manager goes away.