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

511–520 of 530 posts

Re: Why Jira Sucks

#511

Post by SideburnsOfDoom »

devdas wrote: post #500
ryandrake wrote: post #447

Earlier quoted context omitted.

Great comment, and I'm glad you replied with these examples. The problems you describe are corporate software development process problems and not problems with Jira or bug trackers in general. It's a dysfunctional company welding their dysfunction onto Jira, and Jira gets the bad rap. Most of the time when people on HN complain "I hate Jira!" what they really mean is "I hate my company's inflexible software developm…

The problem with company C style work is when you do really small incremental changes. I have had 40+ commits for a single issue, being very gradually rolled out. The time taken to manage tickets in that case would easily have exceeded the time spent on the task itself.

This is correct. "one JIRA ticket = one git Pull Request" is not a good system even when the work can be rolled out in one go, since it encourages PRs that are overly large, long-lived branches and late integration with merge issues. Rather encourage having an idea of where you're headed with the chain of commits, and review and merge a sequence of smaller steps, and ideally validate each of them by deploying to production. This is easier to review, easier to merge and less risk to deploy.

If JIRA is not a good fit to this model, too bad, that's JIRAs problem. Don't make you dev process worse to appease JIRA.

Re: Why Jira Sucks

#512

Post by johannes1234321 »

pm90 wrote: post #335
coredog64 wrote: post #319

Earlier quoted context omitted.

Typically how I've seen this work in high-functioning environments is that devs aren't scheduled at 100% according to JIRA. They have time set aside in their schedule for work of this nature. They'll fix the bug, create a JIRA for the commit/PR, and get on with things. The coworkers on PR reviewers and get their notification that way or in standup. If it's more than 30 or 60 minutes they might log some time against i…

On a team I was on, there was a rule that we simply wouldn’t bother documenting 1 point JIRA tickets as then the documentation itself would likely take more time than just making the change.

That reasoning is weird to me. I could live with "there is no impact for users on this" but if it has impact for users (there of course is a difference between developing a library where a lot of things have impact from a GUI application where most things are invisible to the user) it should be documented, even if documentation takes three times the time. Good documentation is part of a quality product.

Re: Why Jira Sucks

#513

Post by julik »

p2t2p wrote: post #299
specialist wrote: post #280

Earlier quoted context omitted.

> ...you haven't documented the process... How does JIRA help with that? I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA. My $100 bet: They don't. While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.

Atlassian whole point is team centricity. The team decides the process, the team decides the metrics, the team decides what to deliver and how fast. The team decides what are the QA rituals. Yes, there checks to fix a disfunctional team but I have never seen those applied. So there are as many processes as teams in Atlassian.

Was lucky to see a few situations where it was the team that decided to use JIRA, as well as other situations where a team decided not to use JIRA - because they didn't like it and their process was achievable without

Re: Why Jira Sucks

#514

Post by devdas »

dbbk wrote: post #439
SideburnsOfDoom wrote: post #163

Earlier quoted context omitted.

> If devs aren't working on priority items Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.

Developers absolutely should not be deciding what is 'priority'. It's very unlikely they have access to the metrics, wider business strategy, internal and external stakeholders, necessary to determine this. That is the job of the Product Manager.

Developers should then be given access to those details so they can make better decisions.

Re: Why Jira Sucks

#515

Post by devdas »

specialist wrote: post #144
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…

Exactly right. Our folk wisdom metaphors for QA/Test and change management are wrong. Sure, given enough thrust, even pigs can fly. But polish a turd and it's still a turd. [1] JIRAs turrible implementation isn't even as bad as the CRM, ERP, enterprise products of yore. Turrible, sure. But I've seen worse. Much worse. [1] I was a QA Manager for a while. Someday I may publish (explain) the play books my teams used for…

That's not a new strategy.

Re: Why Jira Sucks

#516

Post by signal11 »

josephg wrote: post #507
signal11 wrote: post #472

Earlier quoted context omitted.

Great story, but re the “killed respect for Agile” bit: Agile done right is all about less process. It’s right there on the Agile Manifesto: > Individuals and interactions over processes and tools I’d also read https://agilemanifesto.org/principles.html for an illustration of what is considered valuable — especially the bit about simplicity which process heavy (aka fake-agile) agile consultants totally miss; also the…

Oh, I’ve read all that. But I feel like there’s two agile methodologies - one that the authors intended, a lightweight adaptive attitude where you ground out your process based on what works with your team. And then there’s Agile: The Process as prescribed by agile consultants who go to agile seminars. This agile insists on daily standup, point based estimation, velocity tracking, jira (for some reason), etc. Otherwi…

Fair enough, but that's just really shitty consultants. These days practitioners (the ones I run into anyway) are quite conscious of process overhead. It helps that many are into Lean as well.

FWIW, shitty agile consultants have had plenty of pushback too, with comedy sites like https://www.halfarsedagilemanifesto.org/ being set up to point out their buffoonery. I do suggest laughing in their faces when they pull out tripe like that. Sometimes their excuse is, 'well, we don't work for a startup, we're a regulated business' -- well, it's still tripe, there are plenty of regulated businesses with lightweight agile processes.

My favourite piece of writing on this, in fact, comes from the US Defense Innovation Board, and is called "Detecting Agile BS"[1]. Their recommendations may not 100% work for your organization, and that's okay -- tailor it with an eye to outcomes for your team.

[1] https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB...

Re: Why Jira Sucks

#517

Post by epriest »

IshKebab wrote: post #508
yakubin wrote: post #115

Earlier quoted context omitted.

> You also have to pay to even comment on issues. OP mentioned "non-cloud", so I assumed they wanted it self-hosted. You don't have to pay anyone for commenting in Phabricator when you're self-hosting it.

Err, I think you misunderstood. You have to pay to comment on issues about Phabricator . On their official bug tracker. Like, if you find a bug, or a solution for a known bug, you can't tell them without paying. Doesn't have anything to do with cloud hosting our self-hosting.

This is not accurate. You can report bugs, etc., on the community forum here, which has open registration:

https://discourse.phabricator-community.org/

Re: Why Jira Sucks

#518

Post by wpietri »

tootie wrote: post #499
wpietri wrote: post #479

Earlier quoted context omitted.

You specifically said Jira wasn't for developers, but rather for the managers and stakeholders. That sounds pretty top-down to me. I also don't understand how you believe Jira can be best for tight feedback loops, but also agree that the tight communication and focused teams make Jira unnecessary. That seems contradictory.

I only meant developers don't necessarily need it to organize their team. Or at least they could get away with something simpler. But organizing the team is only half the battle. Or really less. Knowing what to work on and how to prioritize is more important. Especially if you're managing multiple products and projects. Developers may not need it to write code but they absolutely need it to manage expectations as muc…

Developers absolutely don't need Jira to manage expectations. And we don't need it (or managers) to set expectations and track goals. There are more things, Horatio.

I get that Jira may be a way that works for you, for a local definition of "works". But there are a lot of good ways to make software.

Re: Why Jira Sucks

#519

Post by ogre_codes »

Closi wrote: post #484
ogre_codes wrote: post #445

Earlier quoted context omitted.

There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will…

> An atmosphere where interrupting people randomly is commonplace is almost never good for productivity. Almost everywhere I have worked there has been a way to signify that you don't want to be disturbed and you are working in the zone, be it setting do not disturb on slack or wearing headphones. It's not an either/or situation, and if John has the credentials to a server and sits opposite me and doesn't have headph…

Maybe it's just a poor turn of phrase, but when someone talks about "shouting" across the table to get some minor issue fixed, that isn't the kind of place where good coding happens.

With regards to your previous comment, I already said above

> "The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now...."

—and—

> "In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it."

If you are a developer and your workplace is filled with interruptions because people lack credentials or things are poorly documented, then your productivity is going to be terrible.

Re: Why Jira Sucks

#520

Post by TimTheTinker »

threeseed wrote: post #326
TimTheTinker wrote: post #275

Earlier quoted context omitted.

GitHub does all of this very well. "Ticket" => GitHub issue "status" => current column on GitHub project. This includes "is the ticket ready for me", "am I done with a ticket", "is the ticket ready for QA", "did QA reject the ticket", etc. -- each of these is a column in the project board. "who is working on it" => assignee(s)

It only does it well if you have extremely basic needs. It doesn't support custom attributes, workflows, approval hierarchies, statuses etc. There is a reason ZenHub had to be invented after all.

Custom attributes: use labels

Workflows: set up one or more project boards and PR merge restrictions

Approval hierarchies: where the above is inadequate, use CODEOWNERS files.

Statuses: use project columns and labels

Post reply on HN