Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

Post reply on HN
Print view View original

211–220 of 530 posts

Re: Why Jira Sucks

#211

Post by Closi »

Terretta wrote: post #176
SideburnsOfDoom wrote: post #84

To 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…

Have you read David Allen’s Getting Things Done and looked at that system? You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward. Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING. These core mechanics work . Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown str…

One size fits all never works in reality.

Jira / Kanban works for some projects while Waterfall works for others. Some projects need high levels of governance while others move faster with low levels of governance. Some projects can get away without time-commitments, but others have dependencies and must hit deadlines, and this must be tracked.

And just because GTD is great for managing my personal workload, doesn't mean that it's great at coordinating the work of 100 people.

(I say this as a person that generally believes in Agile, is a huge proponent of GTD, and have also been on a dev team where Agile and Kanban was applied where traditional Prince2 would have been a better fit).

Re: Why Jira Sucks

#212

Post by toast0 »

paulryanrogers wrote: post #111
anotherevan wrote: post #74

RT @HackerNewsOnion: California has ruled it illegal to conceal a company’s JIRA subscription for the purpose of attracting engineers. https://twitter.com/HackerNewsOnion/status/98160924222131814...

Do people really avoid companies based on their choice of administrative services?

Software development and deployment process and the tools used to follow (or circumvent, as the case may be) are a large portion of the work of a software developer.

It makes a huge difference in my happiness if I'm fighting with procedures and tools all day, or fighting with user impacting problems all day.

I imagine this is true for people who don't share my process and tool preferences, too.

Re: Why Jira Sucks

#214

Post by LanceH »

SideburnsOfDoom wrote: post #84

To 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 just had this discussion this week. I'm doing work in Jira to build metrics, rather than metrics being tracked from what naturally occurs in Jira. While I understand that most of these problems come from the setup and the decision to use Jira a certain way, I feel the system itself encourages busy work.

As a developer, I've felt the Fogbugz way of doing this most closely mapped to my natural workflow. It is also built around the concept of a single person "owning" a ticket, providing a natural flow from person to person through the lifecycle of a ticket. This can be done in Jira, of course, but it is a mental drain as it requires more bookkeeping.

edit: I guess what I'm saying is that Fogbugz in particular is a bit more opinionated and lines up with what I think is good. Jira naturally guides management to all sorts of extra crap.

Re: Why Jira Sucks

#215

Post by benzible »

Terretta wrote: post #176
SideburnsOfDoom wrote: post #84

To 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…

Have you read David Allen’s Getting Things Done and looked at that system? You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward. Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING. These core mechanics work . Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown str…

I agree with your larger point but pointing to GTD as evidence that the "core mechanics" work is questionable. Many of its biggest advocates have abandoned it.

> Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an addiction. “On more than a few days, I wondered what, precisely, I was trying to accomplish,” he wrote. [...] It seemed to him that it was possible to implement many G.T.D.-inflected life hacks without feeling “more competent, stable, and alive.”

[1] https://www.newyorker.com/tech/annals-of-technology/the-rise... (or https://beta.trimread.com/articles/59839)

Re: Why Jira Sucks

#216

Post by Closi »

ogre_codes wrote: post #206
SideburnsOfDoom wrote: post #84

To 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…

> Fixing a bug without filing a JIRA ticket is in itself progress. When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it. Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to revi…

I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket.

With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket.

I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself!

8 person teams are usually the recommended max team size anyway under Agile (two pizza team).

Re: Why Jira Sucks

#217

Post by runarberg »

aplummer wrote: post #201
runarberg wrote: post #194

Earlier quoted context omitted.

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…

You can complete JIRA tickets just by using a commit title format, and I don’t buy that there is a better system for QA to report the bugs or feedback themselves...

QA can be automated in the same way using CI/CD. A QA engineer should be able to read the existing process documents from the git history and have confidence in the CI/CD. In fact a QA engineer’s job is made easier if a robot is cataloging the process (as human developers are prone to errors and sloppy work).

Regarding feedback, a developers dream is to never have to ask for one or give one. Tickets should be well formed and ready for the developer to start work efficiently. A customer service engineer is in the perfect spot to ease the work of the developer. If a developer has question they can ask the customer service engineer which in effect is responsible to document the process.

Note that I pick JIRA apart here for no specific reason, it is possible to use GitHub as inefficiently as JIRA and vise versa. However GitHub has developer friendly workflow set up by default, whereas JIRA does not. In fact I’ve never seen a JIRA workflow that is developer friendly.

Re: Why Jira Sucks

#218

Post by paulryanrogers »

chrisseaton wrote: post #156
paulryanrogers wrote: post #111

Earlier quoted context omitted.

Do people really avoid companies based on their choice of administrative services?

Are you asking if people care about the tools they're going to have to work with to practice their profession? Yes, of course. I imagine you do as well! If you were looking for a job and they were programming in VB 6 and using CVS for version control I would imagine you (or almost everyone if not you) would say 'hmmm I'm not sure that's how I want to spend my day'. I know I don't want to spend my precious hours on Ea…

CVS and VB6 are more central to my role as an IC. So to me the issue tracker is not significant. Though I agree the inconsistency in JIRA input formats is a bit maddening

Re: Why Jira Sucks

#219

Post by aqme28 »

mdoms wrote: post #162
tootie wrote: post #153

Earlier 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…

Elaborating on your point.

When has JIRA actually been effective as the documentation for a bugfix? JIRA in its most effective will just tell you whether we agreed to do this work and the state the work is in. It is not "documentation."

Re: Why Jira Sucks

#220

Post by jeffreyrogers »

I haven't encountered a bug/feature tracker that doesn't suck. They're really designed for managers so that they have some glimpse into what the people they are managing are working on. Something designed solely for engineering teams would be much simpler I think.
Post reply on HN