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

381–390 of 530 posts

Re: Why Jira Sucks

#381

Post by hakfoo »

What I don't like about Jira is that eventually everything ends up in a poorly structured pool of "Work complete" tasks.

I regularly come across situations of the form "we finished Task XYZ a few months ago, but I want to come back to it." Maybe the ticket has an attachment we need for long-term documentation purposes or a test detail we need the next time we review the code.

Jira search rarely finds anything useful-- the S/N ratio is terrible with non-development tasks mentioning XYZ, yet ignoring actual XYZ tasks due to poor naming and heirarchy. I usually instead look at the code itself, see in the git history "This was modified in ticket 345675" and then use that to index Jira back to the info I want. From there maybe I can walk between linked blockers and sub-tasks to get what I want.

My pre-Jira experience was on Basecamp v1/v2. I appreciated the forum-style layout, because it tends to allow for a few key things: * "Search" and "browse" are both well supported use cases * Old content remains usable and structured, rather than dropping off a cliff after the last ticket closed. * Content can be grouped as it makes sense-- say you get a customer feedback item that touches on three eventual tasks. It would have to be (possibly sliced up and) attached to all three tickets in a Jira model. * It felt "discussion-first"-- the discussion of what to do and how we want to do it is central. This tends to archive some of the subtle choices and gotchas that won't appear automatically in a ticket.

I always dreamed of a system that basically added lightweight ticket/kanban model on top of Basecamp. I can see the value of tickets as a trackable unit of work, but it feels like this would be little more than a few tiny tags decorating a readable discussion flow.

Re: Why Jira Sucks

#382

Post by pmoriarty »

tootie wrote: post #153
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 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…

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

It's for developers too.

As a developer I want to know what the history of work on a certain issue was, who requested it and who worked on it in the past (not just at the code level, the information for which should be in version control logs, but also at non-code levels like approval, review, etc), what the communication was with other stakeholders, etc.

Much of this information is useful to me to figure out who to talk to if I have some questions which the documentation or sourcecode does not answer, and also how to communicate how/what was done on this issue.

This is the strength of a ticket tracking system, and that strength helps everyone.

Re: Why Jira Sucks

#383

Post by ccwilson10 »

jabo wrote: post #368
ccwilson10 wrote: post #348

Earlier quoted context omitted.

Whew. At 8 seconds I'd probably call for the tool to be removed. I had a similar experience while at Atlassian at one point and then we found a way to speed up the (Jira Core) boards by ~5 seconds after changing some JQL for the board logic. That change should be in effect for your org but you'd need to use Classic Business projects. Fun fact, next-gen might actually be a reason why your instance is running slower. A…

I appreciate you jumping into a thread like this and it's great to hear that effort is being invested to speed up Jira Cloud. However: > we've been able to load about 100 issues in ~1-2 seconds. I'm sure there are a ton of things that go into speeding things up and I don't mean to diminish the amount of work involved, but might I suggest raising the performance bar even higher? Is there a world where loading 100 issu…

Haha fair enough. The issue will be, and currently mostly is, the effect you see on performance at scale. Small instances don't have instantaneous interactions but they're still much faster. Here's a quick video (https://imgur.com/a/8ZJrhMZ) of a dev instance (slower than prod) with the new feature. Loading of this view feels way faster than the board does.

The work I'm doing is separate from the performance improvements, so hopefully the two initiatives combined will get us a lot closer to what you're asking for! Again, we'll have to see what it looks like in production at scale, but I'm optimistic it'll be a much better experience.

Re: Why Jira Sucks

#384

Post by ccwilson10 »

rightbyte wrote: post #353
specialist wrote: post #315

Earlier quoted context omitted.

You can split the prize money with u/p2tp2. I legitimacy want to see this. Hire some film students, have them embed with some teams for some sprints, post the footage. If Atlassian really does walk the talk, why aren't you already bragging about it? I just peeked at Atlassian's YouTube stuff. Nicely produced. So that's something. I'm not even going to move the goal posts, or play No True Scotsman. Show how any team a…

> I legitimacy want to see this. I wish I was sarcastic when I said I agree. Seeing a working 30 min sprint planning. Instant hit.

Totally, I'll bring it up with some people post-break! The JSW marketing team is really open to any kind of work that'll help product usability. Interesting fact, a couple of them are actually prior Jira Admins.

Re: Why Jira Sucks

#385

Post by namdnay »

wpietri wrote: post #308
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…

You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices. If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, ev…

I think it’s important to realise that the vast majority (I’m sure it’s more than 90%) of software development being done is technical people from enterprise A building something to help nontechnical people from enterprise B with process C. That’s not something that startups have ever competed with, for good reason.

I love startups and I love working on that space, but you must stay aware that it’s a tiny galaxy within a much larger universe of software that is built and sold like any other engineering project.

And in this “enterprise” (for want of a better word) space, management is important. Not because managers are omniscient or omnipotent, but because at the end of the day, when a customer is paying a large amount of money for something intangible, they need people to talk to, they need figures to see, they need metrics. And in business, the customer is king. Again, except for the startup galaxy where customers are two a penny

Re: Why Jira Sucks

#386

Post by namdnay »

ajkjk wrote: post #289
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…

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

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

My heart wants to agree, and I think that up to a certain level for internal projects you can do this. But at some point that’s just not possible from a business perpective.

Can you imagine going to your client and saying “you know that project you’ve paid us 150M$ for? Don’t worry about it, Bob’s on it, he’s the best. See you in 3 years’ time for the launch!”

Re: Why Jira Sucks

#387

Post by maccard »

ajkjk wrote: post #290
asciident wrote: post #287

Earlier quoted context omitted.

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.

I work on a team of 70 developers (directly) and another 50 or so work on a shared code base between our project and others, and I make daily modifications to that shared code. all those developers are spread from PST to CET+1. Bugs that get fixed are sometimes done by domain knowledge holders on he base team, and those fixes are large fixes that get done on a different release schedule to mine. Its an utter waste of time for me to bug some guy in Seattle about something that he fixed months ago in a release that I haven't received yet when I can see the fix version and change in jira, and either wait or take the fix from the upcoming release myself.

Re: Why Jira Sucks

#388

Post by jayd16 »

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…

>it is a LARP of the work

This is the major problem I see. Just like misleading code comments pollute a code base, bad tickets and fantasy tasks pollute any useful information you might get from a ticket older than a couple weeks.

If we're really being agile "moving something to the backlog" would just delete the ticket. If its important enough, you'll write it up again.

Re: Why Jira Sucks

#389

Post by ajkjk »

ryandrake wrote: post #378
ajkjk wrote: post #289

Earlier quoted context omitted.

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

> 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 I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up. Let's take two projects. Project A is estimat…

The first approach relies on a lead and a team that actually has the ability to do this style of development. No doubt it would not work with lots of teams in practice, but I think it would work for a lot if they were ever given the option.

Of course the way to do it is not to completely let the team go untethered with monthly checkins. You can still monitor progress, at the tech-lead level. But micromanaging the team members has always seemed hugely detrimental to me. In particular, let the team deliver in chunks: a prototype, a major feature, a reduction in bugs. But let them follow their passions in their day-to-day work.

In my experience, plan B gets something done, but you pay for it by shipping half as much and it's half the quality, plus everyone is unhappy. I guess if all you want is to ship something for a deadline go for it.

edit: to be clear, I don't think you should turn the team totally loose. I just think the right level of external micromanagement is at the scale of weeks, rather than the 'hours' I see useless managers doing in practice.

Re: Why Jira Sucks

#390

Post by specialist »

rightbyte wrote: post #353
specialist wrote: post #315

Earlier quoted context omitted.

You can split the prize money with u/p2tp2. I legitimacy want to see this. Hire some film students, have them embed with some teams for some sprints, post the footage. If Atlassian really does walk the talk, why aren't you already bragging about it? I just peeked at Atlassian's YouTube stuff. Nicely produced. So that's something. I'm not even going to move the goal posts, or play No True Scotsman. Show how any team a…

> I legitimacy want to see this. I wish I was sarcastic when I said I agree. Seeing a working 30 min sprint planning. Instant hit.

Heh. Totally.

My intent is to use Atlassian Approved Agility Methodology™ to push back against noobs.

I've released a lot of software. I'm tired of having these debates with the plebes.

Post reply on HN