Hacker News Reader

Comment by aaronbrethorst | Hacker News Reader

To be fair, developers everywhere are probably more productive with JIRA unavailable.

But how will managers feel useful?

Now to mention, scrum "coaches" and that entire industry?

LOL no. If you think this way, there's something wrong in which your company is using it. It helps me personally to manage my work better.

It’s a near uniform “joke” at this point.

Eventually you need to stop blaming the user.

What issues do people have with Jira? I've always wondered.

How about the fact that it’s artificially slower if you’re not paying for the higher plan? For starters.

Can you provide a source for this claim? Haven’t heard of this before.

Jira is famously customizable, and middle managers famously add billions of fields to the bug pages, resulting in incredibly slow page loads.

That: middle managers famously add billions of fields to the bug pages - sounds strange. Jira should reflect a software dev process in your organization, it just helps you to follow it. The process is defined by a doc which can be changed, but not on a whim of any middle manager.

Your description implies that your process is broken, but if your process is broken no Jira can help you. I doubt than even God can help you…

Exactly, and many places have broken processes that are revealed by Jira. Before the dam holding back process stupidity was "the system can't do it", but Jira can do it.

Unfortunately once process stupidity sets in it usually metastasizes and there's no cure.

I’ve used it at multiple companies. I have nothing against it.

But the experience of using it is 100% in the administrator’s control. It works quite well in the default form, but it’s HEAVILY customizable. And that seems to be where most problems come from.

Trying to cram workflows where they don’t fit. Adding tons of extra required fields. Making special rules about how you have to use it.

I’ve certainly seen it go from good to annoying from new people deciding to “fix” some process by adding to it. Including the day you couldn’t create tickets because our admin added a required field that was hidden so you couldn’t fill it out.

It can be good if configured well, but it’s almost impossible to configure well. I don’t even know how to describe it, it’s so difficult to change settings to make things better and not worse. One can make different issue types, and each issue type has fields and workflows, and you can make different screens to deal with all of those things. It’s just so easy to add complexity and so difficult to remove it. Addons often add all these things, and trying 3 addons for 1 hour just to compare them can really mess things up if you don’t know what you’re doing. It’s even quite difficult if not impossible to do this in a completely isolated test environment. And of course you’ve often got people adding complexity on purpose.

Once complexity is added, it’s basically impossible to to reduce it, even by starting a new project with new screens, etc. Because at minimum your issue types will all be infected with complexity. The most competent managers I have seen try JIRA for 2-3 weeks max and then switch to a spreadsheet.

The mains complaints I see people make are that it's slow (which usually gets the response that it's configured badly), and something I'd summarize as installations being configured based on what management thinks they want rather than what the devs "know" they want. Which latter point would of course apply to any flexible enough tool used under the same culture.

The slowest UI I've literally ever experienced.

Any action you take has a 20-40% chance of not actually committing.

History view in some parts of it is literally useless.

Just avoid the ui and use the CLI instead. https://github.com/go-jira/jira Granted getting your custom templates configured with your custom fields set up by the administrator can be a giant pain.

Alternatively just say no to JIRA.

JIRA is one of the main reasons I left let's encrypt. JIRA is also one of the main reasons I said no to two companies.

Life is way too fucking short to deal with this. I think companies don't realize how much devex matters. A big reason of employee attrition in my experience has been shitty fucking tools that never get replaced.

This is good information. I used it 5 years ago and my memories are not particularly bad. But it was self-hosted by a capable admin and the people customizing it were decent developers.

From what I read here things have changed a lot: They force everybody to cloud which is slow.

And the fact that they are higly customizable (adding mandatory fields...) is of course a nightmare in all companies with too many incapable managers, which is probably a fair share...

I use gitlab these days. Its issue management has limitations, but being mostly snappy (despite cloud) and lightweight is a better exeperience than the nightmare I am reading here. I can run my own REST queries if some limitation bothers me too much.

Yeah there's just so many better solutions. Unfortunately a lot of companies think this is a low priority issue and never actually spend time replacing it.

Everyone at my workplace hated jira. We still never replaced it.

It absolutely has some nice features like how Jira and Confluence and BB can all work together.

But they prioritize feature velocity towards being "all things to all people" over usability. This means it's a mountain of inconsistency, bloat, and instability. It's super hard to use if page loads are many seconds long, your favorite button got moved into a hamburger menu to maximize unused whitespace, and their servers are a tangle they can't manage.

Speaking of consistency, IIRC the markup languages are inconsistent between Jira and Confluence. Why would you do that?

It went from an highly efficient and customisable ticket/work tracker to a clusterfsck of a feature creep mess that requires 10 clicks to add an item to a custom field, that’s when you remember where to look because if you are not an atlassian PhD, it will take more time to search how to do something than simply implementing it.

  I am still using it because my team is used to it and I don’t have the time to migrate the 3gb+ Database somewhere else for now.

Actually this is a good point, anyone migrated somewhere else using the backup? What was your experience?

The XML backup that is available in the Server and Datacenter editions was not meant to be used for anything other than toy instances. The documentation suggested that you restore from database backups and copies of the home directory that contained all the attachments.

Whenever possible, I've always used SQL backups (MariaDB or PostgreSQL) to clone or restore JIRA instances. The database information will accept changes in the base URL without issues. It makes setting up testing and mimic environments pretty easy.

When I recently had to move a project to a new instance that I didn't have jira-administrator access to, I had to provide the server admins a set of CSV exports of our JIRA project so that it could be imported over properly. All of the tasks subtasks, and linking had to be provided in separate CSV files because JIRA would fail to export more than 20000 entries in a single file.

It took weeks worth dry runs and checkouts to make sure it would be successful. This was because we had to give this other team a long list of custom fields, workflows, and schemes that represented our software development and program management methodologies.

On the transition date, I was out of the office on a prearranged cancer treatment. I still got texts from people freaking out while I was sitting in the cancer ward getting my infusion. I told them that I couldn't even look it anything until I got back in the office after my treatment and recovery period. Thankfully, they managed to limp along get 80% of the issues resolved within 2-3 days.

The most recent annoyance for me is the fact that you can't use it as a simple issue tracking system.

Without firing up my work laptop I can't provide a precise number, but when you want to file a new ticket, there are at least a dozen options for a ticket type, and once you've created a ticket you're stuck with the consequences of your selection.

Just give me a single ticket type. Let me create any relationship I want between tickets. If I want to assign one ticket as parent for another one, I should be able to do that.

I forgot one of my frustrations: when it’s time to create a ticket, the board selection drop down doesn’t display the full board names, so there’s a few seconds of friction while I try to remember which board I want based on a truncated name.

Or, often as not, I create it on the wrong board and can’t move it.

But it's where you get work, and sometimes people put shit in it!

It's not always the end user's fault, often its the organization's maturity, or lack thereof, as far as tasking.

However, pretending that there isn't a mass of programmers who think they know better than everyone else and couldn't benefit from task structure / documentation (be it SCRUM, Agile, whatever) isn't helpful at all.

Yeah I hear this often enough that maybe its just too hard to setup correctly… but no it’s the users who are wrong.

Reply on news.ycombinator.com