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

171–180 of 530 posts

Re: Why Jira Sucks

#171

Post by johannes1234321 »

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…

It depends on your organisation size and structure, but probably you want to run the bug fix through some triage first (meh management overhead, but needed if you have many bugs to make sure the "important" ones are fixed), then code review (well, that doesn't happen in jira, but probably should be (automatically) reflected there to have one place to look later) and after fixing probably should be routed to the documentation team so docs are being updated and to support team so they can talk to customers accordingly.

Re: Why Jira Sucks

#172

Post by SideburnsOfDoom »

kiaulen wrote: post #169
SideburnsOfDoom wrote: post #157

Earlier quoted context omitted.

You are an assembly line robot.

This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.

> Jira makes it easy to track what's actually going on.

No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".

Re: Why Jira Sucks

#173

Post by wkoszek »

postexitus wrote: post #41

does anybody use monday.com ? it looks very capable at high level (and addresses some of those observability issues stated in the site)

If you want a normal software engineering process, where you want to check in with your colleagues after 1-2 weeks on the progress etc. it's not going to happen. The normal concepts of sw. eng. aren't in Monday. It's more like a clunky to-do for non-techy people. Simple things are extremely hard in Monday. For example seeing all the tasks from all projects assigned to you -> hard. I'd rather stick with GitHub/JIRA

Re: Why Jira Sucks

#174

Post by d23 »

marcc wrote: post #167
mdoms wrote: post #162

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

I don't think the comment was implying that a manager has to eyeball the ticket to make it worthwhile. The comment said there's value in documenting the process, and I agree with that. We use a ticketing system to track work. It's not Jira. But we do have a requirement that all work is tracked in that system. It's not so that a Product Manager or Engineering Manager can chime in and micromanage; it's so that we have…

It's just so obviously an absurd statement to say that if a bug is fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all. A huge portion of the day to day work of software engineering happens without explicit documentation of every decision for every change for every line of code. Life continues, software is built.

The necessity for documentation exists along a spectrum, and the means of documenting things exists along a spectrum. We have lots of tools for documentation. Design docs, commit messages, the commits themselves, JIRA, email, chat. Which one is appropriate depends on the given situation.

Re: Why Jira Sucks

#175

Post by d23 »

polote wrote: post #133
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…

Any better software to replace it ?

Napkins and crayons.

Re: Why Jira Sucks

#176

Post by Terretta »

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 structure fit into a project management iron triangle, per your middle management point.

Of course, middle management is just trying to lie to senior management that writing software isn’t invention because invention isn’t predictable — but senior management wants perfect predictability so they know they’re hitting their bonus, by pleasing C-level execs, whose packages depend on pleasing shareholders. Everyone’s building a Jenga tower of predictably hitting the numbers.

So if you don’t like JIRA, blame shareholders. :-)

Re: Why Jira Sucks

#178

Post by 3np »

kwertyoowiyop wrote: post #139
Lazare wrote: post #119

There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone , but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all ? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, b…

It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit, every time I... What’s the opposite of “delightful”?

Delightless

Re: Why Jira Sucks

#179

Post by EpicEng »

SideburnsOfDoom wrote: post #163
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…

> 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.

>and what happens when JIRA does not reflect the actual priority as observed by devs?

Why do you believe devs alone define the "actual priority"? This stuff is collaborative, and I've worked with many devs who don't have the first clue as to what needs to be built by when in order to keep the business thriving.

Re: Why Jira Sucks

#180

Post by jeff303 »

SideburnsOfDoom wrote: post #157
TheFunkyMonk wrote: post #154

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.

How do you prefer to gather the context for something that may have been hashed out months or years ago by different people?
Post reply on HN