Live data from Hacker News

Why Jira Sucks

whyjirasucks.com

491–500 of 530 posts

Re: Why Jira Sucks

#491

Earlier quoted context omitted.

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

In my experience, their PM tools tell a lot about the possible complexity/overhead of their process. Jira and the other behemoths tend to come with a lot of process/formality. Tends to be borderline waterfall. The lighter-weight tools tend to be used by teams that actually run an Agile process.

Perhaps. Could also be that management uses the tools they are familiar with, even if overkill. I use Git for one man projects even though Subversion or even just periodic rsync would suffice.

Re: Why Jira Sucks

#492

Sucks indeed. Ended up using the CLI for most JIRA related activities in my previous job. https://www.npmjs.com/package/jira-cli Some utils to add to `bashrc`: alias jo="jira open" alias js="jira show" jos() { ticket="$1" if [ $# -eq 0 ] then jira open else jira open PROJECT_NAME_HERE-"$ticket" fi } jss() { ticket="$1" if [ $# -eq 0 ] then jira show else jira show PROJECT_NAME_HERE-"$ticket" fi } jqlf() { jql="$1" ch…

[deleted]

Re: Why Jira Sucks

#493
post #437

Earlier quoted context omitted.

> 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 responsible for budgets. As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based ar…

This is so nicely formulated, thank you so much! I'm just thinking, isn't what you describe the general problem of agile methods/processes, and not Jira's, as it's just one of tools built to assist in agile implementation?

That's an excellent question. To me, the difference is "is agile development part of our process?" or "is agile our entire process?" I once worked on a development team that did a great job of using agile as a narrowly-scoped thing that applied to the act of producing work. They viewed picking their large product and engineering changes through a different lens, which was trying to constantly put yourself on a holistically better footing with both your customers and the engineering codebase. It wasn't "agile" in the sense that it didn't follow any specific methodology - it was top-down, not iterative, etc. But the work to meet the objectives could be done with agile development.

So to me, it's a question of how good teams are at isolating agile development to be scoped to just development. Can they separate strategic thinking (which JIRA basically tries to prevent) from commoditizing development (which JIRA excels at)? If you just rely on the tool that makes work easy, you're not going to get there.

Re: Why Jira Sucks

#495

Earlier quoted context omitted.

I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.

You are an assembly line robot.

Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.

Re: Why Jira Sucks

#496

Earlier quoted context omitted.

You are an assembly line robot.

Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.

And certainly there are better things.

Re: Why Jira Sucks

#497

Earlier quoted context omitted.

Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.

And certainly there are better things.

Sure, with probably very different stability and risk profiles as well as entrance requirements.

Re: Why Jira Sucks

#498
post #437

Earlier quoted context omitted.

This is so nicely formulated, thank you so much! I'm just thinking, isn't what you describe the general problem of agile methods/processes, and not Jira's, as it's just one of tools built to assist in agile implementation?

That's an excellent question. To me, the difference is "is agile development part of our process?" or "is agile our entire process?" I once worked on a development team that did a great job of using agile as a narrowly-scoped thing that applied to the act of producing work. They viewed picking their large product and engineering changes through a different lens, which was trying to constantly put yourself on a holist…

This makes a lot of sense. Thanks for your answers!

Re: Why Jira Sucks

#499
post #460

Earlier quoted context omitted.

That's not what I mean at all. JIRA doesn't imply any sort of top down approach. In fact, I'd argue it's the best tool for those tight feedback loops. Each ticket is a versioned history of the decisions, feedback and work history of a single task. Startups can get away without tools because they can communicate very tightly. That doesn't scale much past an org of even 20 people. Not everyone can talk directly to the…

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 much as managers need it to set expectations and track against goals and budgets.

Re: Why Jira Sucks

#500
post #434

Earlier quoted context omitted.

Not the person you responded to, but I'll take a swing. In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are in the middle of a sprint. you are not allowed to change the sprint. 2 weeks (or whatever) later you have a meeting, where you have to argue for your ticket being next. That probably doesn't result in success, but pretend it does. Then it gets assigned to some…

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.

Post reply on HN