Don't think it's mentioned, but actually what I hate most about it is that there are plugins that seem to do useful stuff, but they're paid-for plugins that also require the IT department to do something.
It's hard to imagine a more hopeless prospect that even one of these two things occurring (people agreeing that we should pay for something, and IT doing it in a timely fashion), but both at the same time and just because some lowly IC (or even whole team) wants them to is far beyond the realm of possibility.
Why Jira Sucks
481–490 of 530 posts
Re: Why Jira Sucks
#482Jira is by far the worst software I'm forced to use. The fact that I can't even reliably find old tickets, not even by search which should be a last resort, is enough for me. It's a steaming pile of crap.
Re: Why Jira Sucks
#483Earlier quoted context omitted.
> ...you haven't documented the process... How does JIRA help with that? I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA. My $100 bet: They don't. While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.
> They don't. Funny. Can I get $100 please? Every team has their own process that is tailored to their needs, process is decided by devs, not managers, managers only do "I'd like to have this kind of visibility" requests some times and I yet to see those requests introducing any kind of burden, usually very miniscule things. We have very simple process in our team with two issue types for devs - task and bug. We have…
JIRA using JIRA.... is it too easy to claim this finally explains the total lack of end user experience in JIRA? I mean just look at all the comments here complaining about performance, search, dependencies or broken WYSInotWYG editors. The four primary features of such a tool. This has been the state of every jira installation i've ever used the past years.
I'm sure your internal burn down charts are straight and nice though.
But as top level says, this is not the tools fault alone, more the process it encourages.
Re: Why Jira Sucks
#484Earlier quoted context omitted.
Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room. The best teams I have worked with tend to be more collaborative.
There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will…
> An atmosphere where interrupting people randomly is commonplace is almost never good for productivity.
Almost everywhere I have worked there has been a way to signify that you don't want to be disturbed and you are working in the zone, be it setting do not disturb on slack or wearing headphones.
It's not an either/or situation, and if John has the credentials to a server and sits opposite me and doesn't have headphones in, I'm asking him to pop them across rather than raising a ticket to him.
Re: Why Jira Sucks
#485To 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…
>>> 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.
Hard disagree. Unless you're writing software for clients a crapton of ceremony goes into JIRA tickets when 99.9% of them will never be looked at again once marked closed.
>>> If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money.
JIRA is used when companies have no trust in their devs. We all use Git. There's a perfect, permanent record of anything I ever touch. Yet management is always worried we're going to "get distracted". As if that wouldn't be incredibly obvious.
It's like hiring a plumber to fix something then following them around the house to make sure they don't straighten your artwork or do the dishes while they're at at.
There's a pervasive theme that "PM knows best" among companies obsessed with JIRA. The best companies I worked at had no project managers at all and things ran great.
Re: Why Jira Sucks
#486Earlier quoted context omitted.
> 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…
That's not the idea. There's a shitload of middle ground between breaking everything down into daily tasks and daily meetings; and disappearing for 3 years until you emerge with a completed product.
I agree and there’s the right balance to be struck. But I’ve worked with big customers on big projects, and the one thing they all have in common is a love of metrics. When you’re spending a lot of money you need to be reassured weekly that all is on track and all is good
Re: Why Jira Sucks
#487Earlier quoted context omitted.
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 with…
Startups compete in the enterprise space all the time, [1], so I don't think your characterization is correct. I agree that client relations is important, but that's something that happens in many businesses. Like the comment I replied to, you assert that a managerial apparatus is necessary for that. I don't think that's the case. It's true that managerialist-dominated companies often prefer to work with other compan…
No again you’re mixing two markets. Just because a SaaS startup sells solutions to big companies, doesn’t make that the same thing as custom IT projects
Enteprise but Startupy: MS Teams
Not startupy: BMW need a solution to track how many defective gearboxes are detected every month, sorted by supplier, model and assembly site, data fed in from the various factory control networks, verified weekly by each quality responsible on an intranet and sent monthly to top mgmt.
What I’m saying is that the second type of project represents more than 90% of the software being coded out there today.
A startup by its very definition (or at least PG’s definition) does not operate in this space , because it’s not exponentially scalable
Re: Why Jira Sucks
#488Earlier quoted context omitted.
Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you. As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company,…
Of course there are details to figure out. Why wouldn't I want all the information from design and other teams in front of me when I'm figuring those details out? I'm struggling to see why a detailed ticket is a bad thing.
[deleted]
Re: Why Jira Sucks
#489Earlier quoted context omitted.
The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.
in my company we actually do estimate work and many people are so bad at it. however we learned from that and our trainees need to track how much time they spend on issues and then we talk about that after two weeks, so they get an understanding why something takes x or y and they can learn to estimate work. estimates do not need to be perfect, but we encourage everybody to estimate more time that they think instead…
Right, the goal of estimating in this since isn’t to have perfect estimates, but to get people thinking about how much time it takes.
It’s also important to not “grade” people on their estimates or treat them with great precision. Just an ongoing rough ballpark helps with planning. Although oddly I found that estimates got better over time.
Re: Why Jira Sucks
#490The problem with Jira is management shifting overton windows over time and making it into a blocker to work instead of a tracker of work. I just checked, on one of my main work boards, to create a new ticket, there are 33 fields to fill out, at least half of which are mandatory. In the middle of a highsev incident, I absolutely hate the time sink, and have been trying to figure out ways to automate away jira as much as possible. I think Jira can be used correctly, but over time PHB's ruin it's potential.
The other problem with Jira is the Atlassian push into confluence that tends to go with it. Confluence is so infuriating. Oh what, you want to do a simple operation like copy-paste data from one section of a table to another? Fuck you. You want built in markdown? Fuck you. You want to embed github pages? Thats a plugin and an ordeal to get approved...etc
People always talk about how it's just a wysiwg and so its for the non-techs, but the thing is it's so specific and non-standard they are still having to learn how to use it anyway. Why not just get them working on github wikis or something?
Also: ffs, stop trying to do "smart searching" for me! It's literally the most useless feature ever, and has never returned anything close to what I was looking for. Yay for having to learn JQL just to do a semi-advanced search. How many query languages do we need to know these days?