Hacker News new | ask | show | jobs
by killjoywashere 1207 days ago
I oversee multiple teams and have one R&D team that I built. Hired every person. They are all far better coders than I. But I’m the outward face negotiating for resources. And my team using Jira helps me get them resources. I use Jira with them. I’m also pulling tasks across the board. The brutal reality is it’s my reputation that brings in money and resources. I need to effectively estimate what we can do. And Jira really helps with that.

The other teams I oversee use project management tooling too. And I see them. I’m here to tell you there are SOTA companies, led by engineers, that use Gantt charts.

I used to think the anti-Jira, anti-management crowd was inherently right. Now I’m quite a bit more skeptical of those views.

3 comments

As someone who is fervently anti-jira, it wouldn't be that hard to make it tolerable. Just make it so that I can't measure page loads with a wall-clock (I've clocked multi-minute loads before) that need 3-7 clicks to get where I need to be. Don't have an abundance of weird subviews that hide half the editable fields I use for another half that I don't. Make the currently active filters clear. So on and so forth, just make it usable.

I would still think jira is a bad tool (in the same way that JNCO jeans are bad pants), but at least using it wouldn't be painful.

I used to consult on JIRA a while back.

These complaints seem like they have a couple of potential causes.

One very common load time issue is downloading too much data at once, especially on boards. I understand some work has been done to make this better, but you may get some relief by creating new boards with very limited number of issues on it - you want the board's primary filter to be specific (eg a board just for stuff assigned to you, rather than for everything asssigned to your team).

The weird subviews tend to be configurable, and Atlassian has been moving more and more towards defaults (and locking down those defaults) for these configurations that push a specific persona/way of working. I'm sure they have data that supports those choices, and there is strong selection bias going on here, but almost all the consulting I did was trying to figure out how to work around those defaults (the simple ones you can just change!)

Probably, a lot of those issues could be fixed by your administrator - you may even have permission to fix them yourself, though that process can still be quite cumbersome and labyrinthine.

So many complaints about JIRA come down to complaints about how it's configured. Atlassian knows this, and I think they are trying to make it better, but it's a hard problem. I enjoy the endless customisation available as an admin but it takes time and effort to understand what's possible, more time and effort to design those changes, and the most time and effort to make those changes match what the teams need. It's a hard problem to fix.

Sometimes people, frustrated by this big bohemoth, will pick an opinionated tool that matches their way of working. This works great for as long as that tool keeps focused and the needs of the team don't grow.

> I used to consult on JIRA a while back.

If consultants exist for a product, you know up-front that the product is intended as an "enterprise," end-all-be-all product, intended to be bought by high-level people, implemented by middle-level people, and configured to frustrate low-level people. It's not the product; it's the implementation, and it's a misalignment of incentives. Most companies big enough to afford JIRA are going to have the same kind of middle layer that winds up making people complain about JIRA on forums like this.

Mate... Jira is ~$8 a user per month. Complain about it all you like but you can't make comments about it's affordability. It's by far the cheapest option out there given it's feature set.
I wonder if self-hosting is the performance difference. I have worked in projects with 15 years of history in Jira. And they were fine. It feels kind of slow but in reality it takes maybe three seconds to load any ticket.

But actual minutes to load stuff? That is insane and I can see where the loathing would come from.

> But actual minutes to load stuff? That is insane and I can see where the loathing would come from.

It's also a comment from a random internet person who has an axe to grind and no data to back it up. So take it with a grain of salt.

It's amazing how a ten second load time can turn into several minutes when it's software you dislike and you're telling people about it later.

...not saying previous commenter is wrong either. Just a reminder to be sceptical about all such claims when they're presented without data.

A ten second load time is about 100x worse than it should be.

Exaggerating it to several minutes is less egregious by an order of magnitude.

A lot of anecdotes are possibly from some years ago where self-hosting JIRA meant a single server on-premise. You might not get a lot of resources and can be used by the entire organization. The server would be at or over capacity 90% of the time so things could take forever to load.

Self-hosted JIRA also opened up to lots of customisations and hacks, which often weren't performant.

With enough data it's possible - I remember a colleague going to a conference and chatting with some Atlassian people and they said their priority (this was probably 2016 or 2017) was getting Jira to be performant for companies with 500,000+ people. With enough users, labels, releases etc I can see Jira churning on something for minutes.
Small Jira instances usually aren't a problem. It's the ones with thousands of projects or plugins. It's the way enterprises force developers to use Jira so they can have "visibility". The problem with the visibility those corporations think they have is that it's incomplete. That incompleteness is a mixture of things:

- Jira isn't well integrated to things like GitHub Enterprise or GitLab Enterprise. Instead it tracks on a regex that mars commit history or messages. It's fundamentally disconnected from the VCS workflow.

- Enterprises want to manage visibility by team, but Jira provides few if any tools for managing multiple projects within a single Project. The data structure doesn't map to how many enterprises need to use Jira in order to do reporting.

- Many enterprises rule over definitions of p0 and p1 for anything. Local context gets rolled over by this and Jira just becomes a kind of table splattered with cards.

- Jiras query system is skin deep at best and doesn't support things like querying all issues of a given epic. Much of this is fueled by their plugin API. Do a GET request on any issue and take a look at all the null fields or objects with just pure nonsense in them.

There's probably more to this list, but the point is that Jiras problem is mostly its own doing. ZenHub does a great job of filling these gaps.

I think the problem with observability/visibility/monitoring is: you need a good internal model of the domain to have any insight. When people see a aesthetically pleasing dashboard that makes sense to them, they think they have insight.

It should be the other way around, because once you have a good mental model, you can get the data you need without it being plated for you. But the presentation fools people into thinking they have insight, so they come to depend on the tools that generate this illusion of insight.

It's not too dissimilar from powerful people being cut off from reality by sycophants and yes-people. Or managers who say 'bring me solutions not problems'. Once you outsource filtering, you lose control.

Can you elaborate on how Jira helps you estimate?
If you have good developer providing honest estimates, no data protection concerns and they diligently provide actuals agile tooling like in Jira can provide great results.

But that all depends on culture. The poster seems to be an engaged manager, pays attention to the data and uses it in a sane way and has hired a group of strong developers.

This is not your average setup…

It's hard to tell. How does someone truly know if the estimates are honest? It's more like the manager "assumes" it's right and fine.
The manager does not assume. OKRs are made or not. The delta is measured. Repeat.
You use an estimate to figure out if another estimate was accurate?