[HN Gopher] I fucking hate Jira
___________________________________________________________________
I fucking hate Jira
Author : yakshaving_jgt
Score : 682 points
Date : 2022-06-20 18:40 UTC (4 hours ago)
(HTM) web link (ifuckinghatejira.com)
(TXT) w3m dump (ifuckinghatejira.com)
| geocrasher wrote:
| The main problem with Jira is that it echoes the people who
| manage it almost perfectly. Crappy Management = Jira Hate, but
| it's really Manager Hate. I figured this out at my last job. Then
| I left.
| ggm wrote:
| Love the idea, hate the implementation.
|
| How can it be proper to show me the outcome of applying JQL to a
| db query but refuse to show me the JQL because of an
| ownership/acl problem.
|
| Want automation? Chain tasks but it has no "this" or "self" so
| that last thing you made? Have fun reconnecting to it.
|
| So many options but no way to flatten them and define a template
| with specific ones: some are baked in and some can't be easily
| specified as important to float to top.
|
| Still no clean way to uplift org to confluence with native
| support
| hn_throwaway_99 wrote:
| I feel like hating on Jira is the pastime that is now passed down
| from each generation of programmers to the next.
|
| I'm going to stick up for Jira. I certainly don't "love" Jira,
| though I do think they've made significant improvements with "new
| Jira" (I think they call them team-managed projects now).
|
| The problem I have with the incessant Jira bitching is that I
| rarely feel that bitchers have a true understanding for the
| _extreme_ difficulty of the _organization-wide_ problem Jira is
| trying to solve. It 's always taken on from the position of
| "well, it didn't make my specific use case easy", but never with
| an appreciation with some of the complexity that Jira needs to
| solve for other users at your company, never mind other
| companies.
|
| Obviously some of the complaints (speed, stability) are very
| valid, but here's a question I think is just as valid: why don't
| you think some other company has come along and toppled the Jira
| crown? Certainly tons of them have tried, and while many have
| their supporters, they are almost equally likely to have their
| detractors.
|
| The fact is, building a generic project management and tracking
| tool is a really difficult, hard problem. In my old age as a
| programmer I feel like Jira is kind of like our form of
| government: "Jira is the worst project management tool, except
| for all the others".
| blowski wrote:
| I totally disagree with you, but I upvoted you for making me
| think about it differently.
| tootie wrote:
| JIRA is the medium that cranky devs interact with disinterested
| managers. It's just a vessel for data and metadata. And as far
| as I'm concerned it's one of the best at doing what it does.
| There's no tool I prefer to JIRA. Asana is a joke by
| comparison. TFS is just Bad JIRA. Issue trackers like Trello or
| GitHub issues are fine for creating a dumping ground for ideas
| but not for organizing.
|
| If you can get away with less structure than JIRA affords then
| congratulations for not having a budget or timeline but the
| rest of us need some deniability. Every other problem in the
| world of software projects is human and can't be solved with
| tickets.
| jayd16 wrote:
| Your point is admirable but its also short sighted. You're
| right that building a one size fits all tool is a large task
| and it's easy to complain about something hard.
|
| But the flaw is in assuming it's a problem that should be
| solved in a one size fits all way. In my experience the pain
| points come from top down process that's at odds with the
| reality of the work.
| throwk8s wrote:
| > It's always taken on from the position of "well, it didn't
| make my specific use case easy"
|
| For customers, their own specific use cases are the only ones
| they _should_ care about.
|
| I don't know why there isn't a good solution to the problems
| Jira attempts to tackle, but that's no reason to get
| philosophical. It's OK to hate every existing option.
| babypuncher wrote:
| People who hate Jira need to spend a year working in VersionOne
| pjmlp wrote:
| Same here, I really don't get the cargo cult hate against Jira.
|
| Before I got to use Jira for the first time around 2006,
| everything I used before was crap, either in-house solutions
| out of CGI scripts or crap like ClearQuest.
|
| Stuff like Trello just seems too basic for typical enterprise
| workflows that overlap sprint planning, with project roadmap,
| milestones and change requests, mapping of tickets to source
| code, pull requests, documentation,...
|
| If I have decision power, I will always pick the Atlassian
| product suit versus the competition.
| timmytokyo wrote:
| >Same here, I really don't get the cargo cult hate against
| Jira.
|
| That's funny, because I've always thought of Jira's most
| ardent defenders as a cargo cult. As this comment section
| indicates, Jira can do no wrong. It can only be done wrong.
| Cult.
| pjmlp wrote:
| Jira is like democracy, it isn't perfect and is full of
| flaws, yet it still is better than the alternatives.
| cotillion wrote:
| I think those of us who have had to suffer through
| ClearQuest, Lotus notes etc have an entirely different scale
| on how bad things can be compared to those who appear to
| really really hate Jira today. I'm not a fan of Jira but
| atleast it loads, eventually.
| bamboozled wrote:
| Those things were like 20 years ago ? JIRA is working years
| old. We've developed better more simple issue trackers
| since, such as GitHub issues and projects. Much simpler.
| prmoustache wrote:
| I think the problem is not what it does or solve. I have used
| jira in 8 companies, maintained an instance in 2 of them and
| I have never seen a fast one nor figured out to make them
| fast.
|
| Any single click you do on it reminds you of the time when
| people were waiting literally minutes to be able to do
| anything when booting windows on a laptop with 5400rpm hard
| disk.
|
| Whatever help it is for your company, it makes you pay for it
| with billions of swears.
| djur wrote:
| Trac has been around nearly as long as Jira and I'd much
| rather use it.
| zild3d wrote:
| Jira is Salesforce
| sanderjd wrote:
| I think the answer to your question is that it's because the
| complaints aren't actually mostly about the tool, but about the
| processes the tool targets. Jira competes both with different
| tools and with different processes that use neither Jira nor
| its competitors.
| throwawaymaths wrote:
| > the organization-wide problem Jira is trying to solve
|
| Yeah that problem is that in many places management sucks and
| can't trust their developers to get shit done, so you have to
| put metrics on it to bring down anxiety brought about by
| incompetence.
|
| There are large open source projects that don't use jira; the
| extreme complexity of managing a distributed team with all
| sorts of interests -geneally even more complex than what a
| company has to deal with- is _empirically doable_ without jira.
|
| When an organization pivots to using jira it is a sign that
| their managers are no longer capable of respecting the
| programmers that work for them. If an organization starts out
| using jira, that means they never were.
|
| To be charitable I'm sure there are a few corner cases where a
| manager came up through the ranks and "only knew jira" but that
| really means they don't understand open source IC, especially
| in the era of GitHub and gitlab issues.
|
| (Btw GitHub issues is absolutely the thing that is slowly
| replacing jira)
| asah wrote:
| +1 to all this. Plus, Jira *scales* - all the cutesy drag-and-
| drop tools are good for 100 tickets/issues/etc and then fall
| over.
|
| JQL and bulk edit are just warming up at 1,000 tickets.
| sidlls wrote:
| You must have been using some alternate-universe Jira. The
| Jira installations I've had to suffer with fall over bulk
| editing a handful of issues. I've never seen a "bulk edit"
| like feature implemented as poorly as it is in Jira. It
| shouldn't take 15 seconds to complete a simple bulk edit of a
| handful (single-digits) of issues.
| bityard wrote:
| > The fact is, building a generic project management and
| tracking tool is a really difficult, hard problem.
|
| This is pretty much the core of it. I use Jira daily, but my
| exposure to it is the tip of the iceberg in terms of what it
| can do.
|
| I think what most people forget is that this Jira is basically
| an ERM but for development-focused organizations. (Where the
| resources are time and people instead of processes and
| inventory.) If you've ever seen the complexity (or price tag!)
| of a real ERM, Jira actually looks very reasonable.
|
| That said, smaller companies and teams should definitely use
| simpler tools that are more appropriate for their scale. Hire a
| Jira consultant and make the switch only when you're big enough
| to justify it.
| tshaddox wrote:
| I'm not sure what "the usual complaint" about Jira is. It
| sounds like you perceive the usual complaint to be about
| feature bloat. You only briefly mention speed, which is the
| _only_ complaint I had about using Jira as an IC developer.
| From the perspective of an IC I think all these systems are
| incredibly similar. Jira is the only one that was, very simply,
| ridiculously slow. As in 5-10 seconds to load any page.
| TameAntelope wrote:
| Jumping on the "Jira isn't the problem" bandwagon, 99% of what
| people hate about Jira now is that the people who manage it
| make Jira hard to deal with.
|
| I'm at an early startup and we use Jira; it's great because I'm
| an admin and I can make Jira reflect whatever I need it to
| reflect.
|
| It's also highly compatible with compliance nonsense -- if you
| can say, "Every change to code is tracked in Jira" (the
| decision process not the literal diff) the auditor's eyes glaze
| over and they just move on.
| randomdata wrote:
| I'm not sure that is quite the right take. When someone says
| "Jira" they are referring to the style of product management
| that Jira enables, not the specific tool. Like how "Google" is
| used to refer to web search, even if one actually uses Bing.
|
| Jira, the software, is far from perfect, but when one talks
| about hating Jira, they are really talking about the people who
| use Jira. The same people moving over to a competing product
| that offers the same feature set perfectly implemented would
| still leave people hating it. The software itself doesn't
| matter that much here. It's a people problem.
|
| So, why do people cling to a project management style that
| everyone hates? There is a lot of friction. Nobody wants to be
| the guy who pushed for an alternative that turns out to be just
| as bad. "Nobody ever got fired for buying IBM", as they say.
| You know that IBM will deliver a failure, so everyone is ready
| when it does fail. If you hired Mom and Pop, you are doing so
| expecting them to be better than IBM, so when they fail equally
| there is a buildup of blame to go around. That's not a
| comfortable position to be in.
|
| I would suggest that winds of change are in the air, but it is
| indeed a slow process to find a critical mass willing to take
| new risks.
| ziolko wrote:
| I get paid for developing plugins for Jira since 2014. One can
| complain about UX and speed of this software, but I saw it
| being the hearth of businesses of all kinds and sizes.
|
| Just like you won't get fired for using React in your project,
| you won't get fired for using Jira. It will support whatever
| your workflow is (and I don't mean only software development,
| but things like hiring or office management). If the built-in
| features are not enough, you will find a plugin that meets your
| needs.
|
| I think long-term it's important to use a tool that give you
| this flexibility.
| wpietri wrote:
| > building a generic project management and tracking tool is a
| really difficult, hard problem
|
| I would say building a good one is an _impossible_ problem,
| because of conflicting needs both across and within companies.
| The primary job of Jira isn 't to help work get done. It's to
| give managers and executives feelings of knowledge and control
| even when that makes everything worse.
|
| You don't need fancy planning systems to get good work done.
| Indeed, I think it's the opposite. I've done many years of work
| with only index cards. E.g.:
| https://williampietri.com/writing/2015/the-big-board/
|
| As Poppendieck has talked about, we live in a "Tyrrany of the
| Plan" age, but that's not necessary and it often makes things
| worse: https://chrisgagne.com/1255/mary-poppendiecks-the-
| tyranny-of...
|
| I think this has happened because of the rise of managerialism,
| where management becomes a self-justifying caste. :
| https://en.wikipedia.org/wiki/Managerialism
| mountainriver wrote:
| Yes this is exactly right, it's all about top down feeling of
| control. You can very easily manage even a large organization
| with just basic Kanban boards
| NikolaNovak wrote:
| >>"You don't need fancy planning systems to get good work
| done"
|
| I mean, as a single individual, in some circumstances, sure.
|
| If we think a bridge or railroad or spaceship get built
| without fancy planning, we've taken our software engineering
| paradigm to new level of delusion. Why does engineer or
| constructor worker understand that you need planning to align
| thousands of people over many years to build a great big
| thing, but we feel in software we are just too darn special
| of snowflakes to need or agree to that?
|
| Sorry if I got your comment way out of context or scope, but
| it just struck me as a very circumstantial statement, but one
| that is bandied a lot as a generically applicable one - which
| it isn't. For many things you need very fancy planning
| indeed.
| BlargMcLarg wrote:
| I'll ask you the reverse. What proof is there we absolutely
| _need_ all this to function? If people are so sure of this,
| surely they can substantiate it with more than just
| rationality. If the similarities are fine, just pull that
| information from the other disciplines you insist know
| better than the "special snowflakes".
|
| >Why does engineer or constructor worker understand that
| you need planning to align thousands of people over many
| years to build a great big thing
|
| You're conflating "needing to align thousands of people"
| with "needing a fancy system which pulls everyone in its
| web to deal with multiple times a day". If anything,
| construction shows just how little ICs need to know to
| function. You don't boggle your construction workers with
| bureaucracy, you take it away and let architects, managers
| and foremen deal with it.
| 8ytecoder wrote:
| It is an issue in all fields. The reason why we have delays
| in major infrastructure projects and why software projects
| are notoriously hard to plan both boil down to unplanned
| and unexpected changes to requirements. The fact that it's
| easy to change software makes it that much more vulnerable
| to last minute requirement changes. If something is exactly
| the same we can just reuse existing software and we don't
| call that "development". It simply becomes "buying"
| instead. And that makes most software development
| explorative in nature. Now tell me how many explorative
| real world, non-software projects have a well-adhered to
| and exact plan.
| wpietri wrote:
| You're exactly right about software being exploratory,
| but I think the whole notion of fixed, up-front
| requirements is part of the problem.
|
| In the lean analysis, the problem isn't changing
| requirements, which is a natural consequence of changing
| circumstances and people learning over time. The problem
| is building up a large inventory of poorly-tested,
| underinformed plans and then doing a lot of work based on
| them without taking advantage of the opportunities to
| learn.
|
| Especially here on HN, we know that startups don't
| succeed because they come up with a fixed initial plan
| and then spend years marching to it. Instead we have all
| set of techniques for releasing early and often so we can
| see what really works for users. A key competitive
| advantage for startups is how their fast OODA loops allow
| them to run rings around larger companies that slowly
| drift into being very plan-based.
| wpietri wrote:
| I was talking about software, not spaceships. Software,
| being soft, is fundamentally different.
|
| However, you should watch the Poppendieck talk I linked.
| The Empire State Building had construction start before
| they finished designing it. The waterfall hallucination,
| where people imagine perfect results come from perfect
| plans perfectly executed, has been hugely enabled by
| software. But if we look at the actual results of heavily
| planned activities, like buildings, roads, and weapons
| development, the track record is terrible.
|
| So if modern planning techniques don't work well even in
| areas, like construction, that they are most suited for,
| then it should be no surprise that people are skeptical
| when they are applied to domains that are very different,
| like software.
| silisili wrote:
| I agree, but wish/think this can change if the product is
| good enough.
|
| Meaning, if someone could write a super fast, easy to use,
| minimal planning/task tracker, with a good set of reporting,
| I feel it could coerce companies to adjust their models to
| use it.
|
| It's a risky venture, but products like Slack, Docker/K8S,
| git, and VS Code gained wide adoption without trying to cater
| to existing organizational processes.
| wpietri wrote:
| I hope you're right, but I'm suspicious. For the ones I
| know well there, they worked because the didn't need
| permission from the powerful Git, Slack, and Docker were
| definitely like that in the early days. But planning
| systems are chosen by the powerful and cater to their needs
| first.
|
| There are plenty of minimal planning tools out there.
| Github issues, for example. Or I use KanbanFlow quite a
| bit. But having driven adoption of simple tools, I think
| you at least need an environment of benign neglect, as with
| a skunkworks project, or a tech project at a non-tech
| company. From what I've seen, in a lot of companies systems
| like Jira are too entrenched and too visible to management
| to allow for guerilla-style adoption of something that's
| more developer/worker friendly.
| ulkesh wrote:
| For the most part, I agree.
|
| But...
|
| If the UX wasn't garbage I'd defend it, too. It has a lot of
| nice features and integrations. But the UX changes they have
| made in the recent past (few years-ish), made it worse, for me.
|
| And, in my opinion, the reason some other company hasn't come
| along and toppled it: critical mass. It's the same reason Epic
| is king in the hospital IT world. The UI/UX can be garbage (and
| it's so much worse with Epic than with JIRA), but organizations
| will still stick with it, because it's what they know.
| hammock wrote:
| >It's always taken on from the position of "well, it didn't
| make my specific use case easy", but never with an appreciation
| with some of the complexity that Jira needs to solve for other
| users
|
| Your insight is the same reason why people hate boarding
| selection for planes, or McDonalds breakfast ending at 10:30am
| or fill in the blank.
| polotics wrote:
| Does Linus use JIRA on that little project called the Linux
| kernel? Why is git with good readmes and clear pull requests
| not enough project management? If you're not doing PR's you are
| just LARPing software development. I don't hate JIRA, I hate
| "IT" employees that can't program.
| jsiepkes wrote:
| No Linus uses Bugzilla [1]. Have you ever used it? You'll be
| begging for Jira once you've used Bugzilla.
|
| Also Linux doesn't use pull requests. GIT doesn't even know
| the concept of a PR. You are supposed to generate a patch
| with 'git format-patch' and submit it to a mailinglist.
|
| [1] https://bugzilla.kernel.org/
| polotics wrote:
| git doesn't know the concept of a Pull Request?
| https://git-scm.com/docs/git-request-pull
|
| Bugzilla is for bugs and that's the point, right? A project
| is not a set of bugs...
| djur wrote:
| What's wrong with Bugzilla?
| lamontcg wrote:
| > I rarely feel that bitchers have a true understanding for the
| extreme difficulty of the organization-wide problem Jira is
| trying to solve.
|
| I think the problem is that Jira is optimized for productivity
| theater and top-down management.
|
| When an organization deploys Jira it is usually because upper
| management thinks that it needs a deluge of task tracking so
| that everyone can stay perfectly "aligned" all the time.
|
| This creates an annoying amount of make-work on the part of
| Engineers and their immediate managers, slows down velocity and
| the vast majority of the time spent on inputting data into Jira
| never results in anything actionable.
|
| Jira is just a symptom of the disease though.
| serial_dev wrote:
| > Jira is optimized for productivity theater and top-down
| management
|
| Hit the nail on the head.
|
| I don't hate Jira.
|
| I hate working for companies and with "micromanagers" that
| prioritize bs metrics over improving customer satisfaction,
| and busywork over impactful projects. And these kinds of
| people / companies always use Jira.
| atoav wrote:
| I worked at a company once (not programming, more like an
| online shop) which did _everything_ via email. And I mean
| _everything_. Tickets, issues, orders, repair requsts, refunds,
| you name it.
|
| It worked flawlessly -- in fact I haven't been at a place that
| was as well organized since. And it all came down to one thing:
| everybody understood that there is only email and that if it
| isn't an email it will be forgotten and fall in some crack, so
| you better make it an email, that has a propper subject, is
| searchable, etc. That meant everybody was writing emails with
| nearly military rigour, while the asynchronous nature of the
| electronic letter always reminded you, that you just needed
| your emails done and then you were fine. Depending on your
| position you had multiple (shared) inboxes that corresponded to
| the tasks. Of course there were some old emails, that were more
| of a "if anybody finds the time and will" type and sometimes
| emails from the guy from the day before had to be done etc. But
| all in all it was surprisingly pleasant to work just with
| email.
|
| The point of the story is: You can turn _any_ tool to shit if
| people use it in a bad way. And you can make anything work if
| people use it in the right way. Most problems with
| communications are people-problems, not tool-problems. Sure
| certain tools may lend themselves to certain behavior more than
| to others but ultimately a team can decide how they wanna
| communicate effectively and which behavior produces chaos and
| problems.
| zwischenzug wrote:
| I couldn't agree with this more. What people hate is not Jira
| but the organisational thinking that it facilitates. I've used
| jira in other contexts and it's been mostly a joy because the
| processes it modelled were happily simple.
| nipponese wrote:
| Totally agree with this argument, INCLUDING almost making the
| same Churchill quotation joke at the end.
| thefaux wrote:
| It's not that I think is a particularly good or bad
| implementation of project management software (though I think
| as others have pointed out, in its effort to be all things to
| all people, I think it has converged on a lowest common
| denominator solution). I reject the concept of general purpose
| project management software. I think that at best these tools
| are primarily surveillance tools for middle management. They
| disempower workers and make them fungible. The workers are
| evaluated on tool points rather than the actual value they
| create (sometimes these may be alignment, but often they are
| not). At worst, I think they actually lower product quality
| because of the poor incentives that are inherent in a system
| that rewards closing issues and creating "features".
|
| I believe the best workers (at both the management and IC
| level) are not going to want to waste a significant chunk of
| their professional lives in Jira world and the worst workers
| just want to keep their paycheck coming every month so they
| will just submit to it and keep cashing their checks. The
| organization will thus rot and converge on the lowest common
| denominator employee, which is indeed what the tool kind of
| promised: fungible, low skill workers with predictable (low)
| output.
| shagie wrote:
| > why don't you think some other company has come along and
| toppled the Jira crown?
|
| I really wish Jetbrains Spaces was around when the organization
| I work for was doing the "everyone under one umbrella"
| migration.
|
| Prior to Jira, we had one team using GitLab issues, one team
| using Redmine, one team using Borland Star (with a tight limit
| on licenses), and one team using Excel.
|
| I personally would have gone with Redmine over Jira...
| _however_ that also would have tied me to doing a lot more
| setup work, upgrades, and care and feeding of the system
| compared to the relatively turn key setup of Jira.
| lmm wrote:
| > Obviously some of the complaints (speed, stability) are very
| valid, but here's a question I think is just as valid: why
| don't you think some other company has come along and toppled
| the Jira crown? Certainly tons of them have tried, and while
| many have their supporters, they are almost equally likely to
| have their detractors.
|
| Trello was a much better solution to the problem, that's why
| Atlassian made sure to buy it and is now hard at work ruining
| it.
| josephcsible wrote:
| > why don't you think some other company has come along and
| toppled the Jira crown?
|
| Because the people who get to decide whether or not to use JIRA
| aren't the people who it causes the most suffering for.
| cogman10 wrote:
| > why don't you think some other company has come along and
| toppled the Jira crown?
|
| Because it's really hard to kill off the market leader when the
| market leader is embedded into the core of how a company works.
|
| I don't buy that it's a matter of competitors not being better.
| It is more about inertia.
|
| The argument you have here could equally be applied to C++ or
| Cobol "Why is new code being written in these languages? Why is
| C++ so popular even when there are many other competitors?
| Certainly tons of languages have tried."
|
| I currently work in a field that is disrupting existing
| products that were, no joke, written in the 90s in VB6. It can
| be super hard to sell our product to a lot of people, not
| because our product isn't better, but because they've been
| using our VB6 competitor since the 90s.
| bee_rider wrote:
| It isn't that surprising that a programming language has
| inertia, it has lots of 'mass' so to speak -- programmers
| have to specialize in the language, and an ecosystem of
| libraries has to be built. It is more surprising to me that
| an issue tracker like Jira does. Surely people aren't
| specialized in... Jira-ing or whatever.
| Judgmentality wrote:
| > Surely people aren't specialized in... Jira-ing or
| whatever.
|
| There are people who build their careers on this. Their are
| consultants who do this, and _only_ this. And the
| unfortunate reality is, Jira is so complicated, there
| actually is a reason for these people to exist.
| halostatue wrote:
| You get a few projects in JIRA...and you're stuck. Then you
| add JIRA Service Desk or Service Management or whatever the
| hell it's called these days...and you're stuck. Then you
| add some Confluence docs linked to your tickets...
|
| Unless one is really willing to throw institutional
| knowledge _out_ , changing tracking systems is extremely
| costly.
| thomastjeffery wrote:
| Here's a better answer to that question:
|
| Crowns don't come from inherent value. They come from
| monarchy.
|
| Jira holds the crown because so many are convinced the
| "industry" in which it leads is worthy or valuable.
|
| What value does a monarch provide? Order. Structure.
| Authority. Corporate environments value these because - art
| its core - that is what "Corporation" is: a new system of
| governance.
|
| Most of the complaints about Jira can be turned to
| Corporatism itself.
| hn_throwaway_99 wrote:
| I disagree with this. Absolutely, once Jira (or any
| particular project management tool) gets it's "tentacles"
| into a sizable enterprise, it's very difficult to dislodge.
|
| But I've seen _tons_ of other examples in my career of
| companies making larger, more difficult transitions because
| they clearly felt the risk /benefit was worth it: moving from
| CVS/Subversion to git, moving from on-prem to the cloud,
| moving from Windows to Mac, moving from hipchat to Slack,
| moving from Oracle to postgres, yada yada yada.
|
| I'm certainly not saying it's easy, but I fully believe that
| if a project management solution came along and _all_
| stakeholders went "holy shit, this is so much better than
| Jira", that many companies would make the switch. This hasn't
| happened, and honestly if you hear people complain about
| Fogbugz or Asana or whatever that it's probably an equal
| "per-capita" bitch rate.
| kelnos wrote:
| I think it's maybe a bit of both? I worked at an org that
| was using Trac for most things. It's probably fine for a
| small, engineering-driven company, but it's not very full-
| featured and isn't great for PMs and other business types.
|
| So once the company got large enough, management wanted to
| switch. Many of us essentially said, "ok, that's fine, but
| please please please not Jira". And yet, they went and
| hired some consultants who were like "oh, Jira is the
| industry standard for your line of work, you'd be taking on
| a huge risk not using it, blah blah blah". Management
| bought it, and they've been on Jira ever since.
| hn_throwaway_99 wrote:
| If you said "please please please not Jira", what other
| options did y'all suggest that you thought would be
| better?
| cogman10 wrote:
| > moving from CVS/Subversion to git
|
| Was that really painful? We did that transition and it
| amounted to having teams one by one run the "git-svn"
| script on their repos to port over to git. Even with over a
| million commits on our central SVN server, the whole
| process generally took around 5 minutes per project. Even
| in the worst cases, it was something like 1 hour.
|
| The most painful part we had was putting a rate limiter in
| place to keep our SVN server from toppling over.
|
| > moving from on-prem to the cloud, moving from Windows to
| Mac, moving from hipchat to Slack, moving from Oracle to
| postgres
|
| These are certainly all more difficult but also things that
| aren't central to the way the company operates AND can be
| done a piece at a time. Moving from Jira->something else
| can't really be done in a piecemeal fashion.
|
| The other big problem here is Jira has a wider audience
| than just the dev department. Dev saying "Let's go from svn
| to git" is something that doesn't hardly need involvement
| from the C levels. They never (usually) touch or look at
| the VCS interface. In fact, the only thing you listed that
| I think would be a hard sell to C levels is switching from
| windows to mac. Though, I suspect a lot of them are using
| macs anyways. Try getting your C levels to agree to switch
| from mac or windows to linux and I bet that'd never fly in
| any organization.
|
| > I fully believe that if a project management solution
| came along and all stakeholders went "holy shit, this is so
| much better than Jira"
|
| I just disagree. The best counter example is Internet
| Explorer. Both Firefox and Chromium have been better than
| IE for a long time (10->15 years). So why didn't every
| corporation switch to Firefox? Why did Chrome end up
| winning for desktop web browser even though it came so much
| later (2008)?
|
| The answer is simple, chrome advertised on media that
| stakeholders watched.
|
| Chrome eventually won, but it got there through deep
| pockets and advertising. If there's anything that will
| topple atlassian, it will have to be through the same
| route. That product/product set has to be better AND they
| have to spend a lot of capital advertising so that other
| shareholders find out they exist. Without doing both those
| things, toppling atlassian will be a long nearly impossible
| slog.
| spc476 wrote:
| It depends upon how SVN is used, and for the team I'm on,
| it's going to be painful. SVN allows you to checkout a
| subdirectory of any given repository, and because of our
| history, we have everything my team writes (10 programs)
| in two repositories, with a lot of sharing between the
| two repos. This is something that is ... not easy ... to
| replicate with git [1].
|
| As far as Macs go, the company I worked for was 50/50
| Mac/Windows, with the majority (if not outright all) of
| the developers using Macs. We got bought out, and our new
| corporate overlords were purely Windows, and didn't know
| what to do about our Macs. Personally, I ended up with a
| fully manged Windows laptop that I never used [2] for
| three years before I could send it back and send me a
| "semi-managed" Mac laptop.
|
| As for Jira, eh. I didn't mind it that much, except when
| management mandated that every team use the same queue
| for everything. That queue didn't match our preferred
| method of working, so we kept our old queue purely for
| internal stuff. Our time tracking system is way worse
| than Jira by far.
|
| [1] Not to say I love SVN---I hate it actually, and would
| prefer to use git. But having used SVN for over a decade
| on these two repos, and given their structure, it's going
| to be interesting.
|
| [2] Except to turn it on to have it autoupdate when I got
| "the email". What a colossal waste of resources. My team
| kept on using the Macs.
| spullara wrote:
| We start new companies all the time and nothing has been able
| to replace JIRA past the 5-10 engineers who know exactly what
| they are supposed to do stage.
| bragr wrote:
| >Because it's really hard to kill off the market leader when
| the market leader is embedded into the core of how a company
| works.
|
| eh. I've experienced a number of painful tool and platform
| shifts in my career that basically came down to "it's
| cheaper" so I don't buy that companies are unwilling. If
| someone provides the feature set that is some combination of
| cheaper and better, then the only thing you really need is a
| migration path (Jira import tool in this case), and you'll be
| able to make some sales. Make enough sales and you start
| looking popular and that can provide its own inertia. The
| fact that this has not happened is, to me, evidence that
| nobody has done it better so far.
| cogman10 wrote:
| > Jira import tool
|
| This is the problem. Jira is so highly configurable that
| without recreating a good chuck of the Jira feature set, an
| "import" tool will be pretty hard to make.
|
| Any competitor in this marketspace will have to invest a
| considerable amount of their time creating and maintaining
| such a tool, which I imagine if they ever became a serious
| contender, Atlassian would put up some anti-competitive
| road blocks. (For example, forcing everyone into their
| cloud offering so they can more easily control endpoint
| access....)
| shagie wrote:
| I'll note that most other competitors that are engineer
| (rather than management) focused don't use a jira
| workflow approach and instead tend to be more of an adhoc
| "apply labels" and "we trust you to apply the correct
| labels".
|
| The Jira complex state table tends to be something that
| isn't replicated as its part of the "we're not Jira"
| value proposition.
| cogman10 wrote:
| I don't disagree, but just to point out the issue with
| transitioning, even in a basic sense, is that Jira allows
| and can invisibly create new states for pretty critical
| pieces.
|
| Your case might be in a "Closed" state on the UX, but
| internally that can be "custom state 48083232" because
| some wingus decided to first start by naming it "to be
| closed" and then changed it to just "Closed". That can be
| different for every project.
|
| This is why an import tool is a complex thing to figure
| out. You have to translate all the potential custom
| states into the "we're not Jira"'s states that make
| sense.
| shagie wrote:
| Yea... I wrote a redmine to Jira importer. That was...
| interesting. I'm familiar with Redmine and its table
| structure. I was able to reverse engineer the json
| schemas (there are examples at
| https://support.atlassian.com/jira-cloud-
| administration/docs... but little in the way of actual
| schemas and DTOs to work from) and successfully imported
| everything including a number of custom fields in Redmine
| and comments and attachments.
|
| The only "oops" part of the Great Import was that the
| users that were in Redmine but not in Jira (people who
| left the org and thus were never imported into Jira) had
| entries created as the sysadmin who ran the import.
| axlee wrote:
| You mean as hard as when Git obliterated every other VCS
| within the span of a few years? If products are better, they
| get adopted. How do you think every single company in the
| world started to develop for iOS between 2008 and 2010? When
| the upside is obvious and the path to transition is well-
| defined, there is very little friction.
| wizofaus wrote:
| I still don't understand how git won the source control
| battle so decisively. I respect git for what it's good at
| and its power, but from what I've observed it's far from
| clearly being the obvious choice of source control for
| closed source software shops. JIRA I can take or leave, it
| does the job - it's hard to imagine anyone being driven to
| hate it, but I can believe having it badly configured would
| be a serious drain on productivity.
| MaxBarraclough wrote:
| > I respect git for what it's good at and its power, but
| from what I've observed it's far from clearly being the
| obvious choice of source control for closed source
| software shops.
|
| At this point git is the incumbent, which is self-
| sustaining: developers already know git, so you'd need a
| really compelling reason to use anything else and take on
| the burden of training your developers to use it.
|
| It helps that git is freely available and is by far the
| top choice for Free and Open Source projects.
|
| Of course, SVN used to be in the same position, but git
| is such a great improvement that it was able to win out.
| I imagine git's origins in Linux kernel development may
| also have been a factor in its early success.
| ecuzzillo wrote:
| I can only speak to the comparison with hg, but for large
| repos, git's performance is literally 10x better in our
| case (we have two parallel copies, one in hg and one in
| git, so as to smooth the transition to git). hg seems
| more usable, but certain decisions are poor (e.g. baking
| the branch name into each commit); overall I have no
| strong preference between the two except for the speed.
|
| But the speed pretty much drowns out any other signal.
| dijit wrote:
| Migration was easy, it was decentralised, had a famous
| original author & a huge famous project using it _and_
| had a lot of "hip" source code platforms such as github,
| gitorious, bitbucket (pre-atlassian) and gitlab.
|
| I'm not surprised it won tbh.
|
| Game companies are still using Perforce though.
| andybak wrote:
| > Game companies are still using Perforce though.
|
| Maybe the ratio of text to non-text assets?
| cogman10 wrote:
| > You mean as hard as when Git obliterated every other VCS
| within the span of a few years
|
| There's not a concept impedance mismatch going from
| CVS->SVN->GIT. The concepts are so similar that git-svn
| exists to convert a SVN repo into a git repo (and a similar
| conversion tool exists for CVS->SVN)
|
| Jira is so flexible and configurable that no such tool
| could exist. Migrating to a new tracking system requires
| that you either lose all currently tracked issues and their
| history OR you spend the money and effort handcrafting for
| your org a Jira->Foo translator to preserve some semblance
| of history. The larger and more diverse the org, the harder
| such a tool will be to craft.
|
| > How do you think every single company in the world
| started to develop for iOS between 2008 and 2010?
|
| Because ignoring a company that commands 30% of the market
| is a bad idea? How do you explain the flop of WebOS which
| was, IMO, a far better UX and OS compared to either IOS or
| Android?
| axlee wrote:
| How about when every single company rewrote their
| frontend stack in React after angular.js was done, circa
| 2015? Or when everyone moved to k8s within 2 years around
| 2017-2019? Hell, now even companies that definitely
| wouldn't benefit from anything related to k8s are diving
| into it.
|
| What I am trying to show by these examples is that things
| can move fast, very fast, and that in our industry there
| are no such thing as well-entrenched tools. Yarn got
| adopted within a year above npm, the "default node
| package manager". Everything is always up for grabs, if
| you can show the benefits, however small they are. And
| the history aspect of Jira isn't an unsolvable problem,
| pretty much every single issue tracker in the world
| offers a Jira import, and losing issue history is far
| less damaging than it was losing "commit" history when
| everyone was moving to git back in the days. If a company
| can show that their alternative to Jira solves a
| percentage of common complaints against Jira, while
| offering the same capabilities of scaling that Jira does,
| people will follow. Nobody wants to deal with crappy
| products. Especially since the ones suffering the most
| from Jira are usually the ones in charge of setting up
| the very processes that Jira is supposed to help with,
| and to procure the tooling.
| cogman10 wrote:
| > How about when every single company rewrote their
| frontend stack in React
|
| God I wish that were the case. My company is still
| rocking Angular unfortunately :(
|
| > Or when everyone moved to k8s within 2 years around
| 2017-2019
|
| That did not happen. k8s got a good share of the market,
| but it's far from "everyone moved".
|
| > What I am trying to show by these examples is that
| things can move fast, very fast, and that in our industry
| there are no such thing as well-entrenched tools.
|
| The tools you are listing are all dev tools picked, used,
| and curated by development. Jira isn't a dev tool, it's a
| product management tool. There's a major difference
| between tools that devs can pick and choose and tools
| that an organization gets to pick and choose.
|
| Even with your "yarn" example, while it took over it
| didn't replace "npmjs" as the centralized repository
| server. Just like gradle still gets it's artifacts
| primarily from maven central.
|
| I'll go back to something I said elsewhere. If it's so
| easy to move and change why is C++ still being written?
| Why does it remain one of the most popular programming
| languages even though most people are VERY quick to point
| out it's major flaws. Even though other better
| alternatives exist (Rust, Nim, D, etc).
|
| > losing issue history is far less damaging than it was
| losing "commit" history when everyone was moving to git
| back in the days.
|
| Assuming you like everyone else went from svn->git I
| don't see how you'd have lost commit history. I
| personally converted a BUNCH of repos to git and didn't
| see any cases of lost history.
| wheresmycraisin wrote:
| Migrating very large SVN repos to Git is far from
| trivial.
| oneplane wrote:
| > embedded into the core of how a company works.
|
| Doubtful. Unless you are working for a shitty company in the
| first place, bad tools essentially just get skipped and
| disused by autonomous teams and none of this matters. If the
| company 'embeds' a product in place of a workflow, that's not
| something a product is ever going to fix, that's an
| organisational problem.
| BlargMcLarg wrote:
| >The problem I have with the incessant Jira bitching is that I
| rarely feel that bitchers have a true understanding for the
| extreme difficulty of the organization-wide problem Jira is
| trying to solve.
|
| This is a lot of hearsay which tends to devolve into a debate
| of "we absolute need this!" vs "no you don't, see X".
|
| >Obviously some of the complaints (speed, stability) are very
| valid
|
| I don't think people defending it fully grasp just how
| important speed and stability are, or at least live in a
| corporation where Jira was optimized better than the average
| corporation does. Given not everything is the fault of Jira,
| but when Jira is expected to be the place you go to all the
| time and it is that slow, it becomes _very_ impactful to
| morale.
|
| >"Jira is the worst project management tool, except for all the
| others".
|
| This doesn't work until big corps actually try something
| different, but pretty much all of them push back on the mere
| _idea_ of trying alternatives. If you can 't invest a few
| months trying a different system, you can't judge it. And since
| those few months are seen as a "great risk", no manager is
| going to push the issue any further, even if Jira's costs per
| developer could easily run into the hundreds (or thousands, for
| 6-figures) a year on morale loss and time loss alone.
|
| And this is the crux of the matter. Management likes concrete
| numbers. Management likes mimicking what other successful
| companies do. Management does not like fairly abstract things
| with great risks. Management does not like big risks with
| abstract rewards.
| steve918 wrote:
| I feel like a lot of great programming talent has been wasted
| by very smart engineers who felt the pain of their current
| ticketing system and spent years building countless startups
| only to end up with something occasionally marginally better
| than Trac (2004).
| oneplane wrote:
| Back in 2008-ish a lot of projects I came across tried to use
| Redmine because their company had a sucky JIRA or sometimes
| even Mantis implementation. Redmine turned out to be highly
| unsuitable in a matter of a few months and after trying out a
| few options that are mostly just tickets+kanban boards, it
| turned out that the simplest 'fix' was just setting up an
| individual JIRA just for the team so it could be used
| properly instead of some heavy handed top-down "use this tool
| in this specific way" approach. Once more teams started to do
| it, the 'company-wide' JIRA essentially just contained
| managers and a few product owners and it got deleted in a
| year or so.
|
| Afterwards, all the 'team JIRAs' got merged into a normal
| JIRA again, but this time everyone had full control over
| their own projects and boards, problem, solved.
| djur wrote:
| What necessary features did Jira give you that Redmine
| and/or "tickets + kanban boards" didn't?
| chillingeffect wrote:
| >why don't you think some other company has come along and
| toppled the Jira crown?
|
| Why haven't cowboys found a different way besides horses to get
| around? _They 're not interested in what those under their
| asses think or feel._
| travisgriggs wrote:
| I don't use Jira. I'm aware of what it basically is. We're
| small, we use a pin board, 3x5 cards, and a drawer.
|
| Do open source projects of any size use Jira? If not, do they
| use a basic knock off? The few not-so-big ones I've contributed
| to seem to get by without it, but maybe I just don't have
| enough exposure with these. If the open source world can be
| semi-productive without Jira, I think that's telling. The
| interested student can decide the details of what it's telling.
| rightbyte wrote:
| Jenkins uses Jira. Only one I know of.
| [deleted]
| stack_framer wrote:
| > "Jira is the worst project management tool, except for all
| the others"
|
| I came here to say precisely this. In addition to Jira, I've
| used Clubhouse, Trello, monday.com, and GitHub Issues. Jira
| sucks slightly less than the alternatives I've used.
| CSMastermind wrote:
| > I do think they've made significant improvements with "new
| Jira" (I think they call them team-managed projects now).
|
| I feel totally the opposite. If you've ever had to administer
| Jira at a large company than team-managed projects are the bane
| of your existence. If you think, there's even a small chance
| that your company will grow to 300+ engineers any time in the
| next several years then do yourself a favor and turn off team
| managed projects entirely or else you'll face a painful
| migration away from them.
|
| Though I will generally defend Jira as a product for many of
| the reasons you said.
| hn_throwaway_99 wrote:
| I upvoted your comment because I believe it's a perfect
| example of what I was trying to point out: it is _impossible_
| to please everyone with a company-wide project management
| tool, but the fact remains that it is a necessity.
|
| For all the people bitching about how Jira makes it hard to
| work like they want to work, their are folks like you who
| will complain that Jira makes it to easy to get around a
| company-wide standard.
|
| To emphasize, I'm not saying either side is right or wrong,
| I'm just saying it's impossible to build a project management
| tool where large subsets of people won't complain about the
| exact same set of features that another subset of
| stakeholders likes.
| marcosdumay wrote:
| > but the fact remains that it is a necessity
|
| I am interested on why people think that.
|
| It doesn't look like a necessity to me. Ok, in a medium
| company, with dozens or maybe a hundred or two people,
| centralizing all the workflow is probably cheaper and more
| productive than siloing teams. But in a large company the
| inverse can very easily be true.
| thfuran wrote:
| What fails to scale?
| halostatue wrote:
| We added a team-managed project a while back, and built a
| _really good_ workflow around it that satisfied the needs
| of everyone who works in that project.
|
| We can't easily replicate that workflow anywhere else. This
| isn't the end of the world, but I should be able to create
| a new team-managed project based on another team-managed
| project and then modify its workflow _separately_. So far,
| I can't figure out how to do that.
|
| I'd love to take the team-managed workflow and _promote_ it
| to a company-managed workflow now that we've experimented
| with it. So far, I can't figure out how to do that.
|
| Don't get me wrong, I _really_ hate JIRA. I've written my
| own bug tracking system. I've tried lots of other tracking
| systems. JIRA is wrong on so many levels, but eventually
| you hit something in one of the other tools that you cannot
| address with those tools, but is _possible_ (but painful to
| configure, and it might cost you extra money) in JIRA.
|
| The only other tracking system I really like is GitHub
| issues, but it _also_ has problems and limitations. And
| then you have things on GitHub that actively make things
| much worse (the autoclose bots; forms like the ones that
| Vue puts up, etc.).
|
| I've never seen any organization need the level of
| complexity that they end up using in JIRA ( _especially_
| the access permissions, which _consistently_ get borked
| sideways), but most organizations eventually need something
| better than Bugzilla, Trac, or Github Issues.
|
| The other difficulty is that switching bug tracking systems
| is _tough_. I want to really try Tara, or ClickUp, or
| Monday or a few different ones, but adding another tool is
| literally _adding another tool_. This is the same reason
| we're using Confluence, even though it's objectively the
| worst wiki in existence.
|
| I hate Atlassian products with a passion. There's nothing
| better, and the cost of switching is too high.
| lewispollard wrote:
| Yeah. My employer has company managed projects on by default,
| and there are several features which still haven't been re-
| implemented from OG team-managed Jira, particularly around
| workflow automation, that have tickets from 4 years ago
| saying "we're looking into implementing this in the next
| year!"
| TheMagicHorsey wrote:
| I think the issue is that because Jira offers the hope of a
| tractable customizable management process, it invites
| management to put in more process to improve their visibility
| of a project. This should not result in micromanagement, but it
| usually does. From a programmer's vantage point this is lose-
| lose, because your day to day tasks are weighted down by Jira-
| related bureaucracy, and your mastery of your schedule is
| continuously threatened by managers peering down from above to
| ask questions about this and that individual item on your work
| list.
|
| I suppose its a necessary evil for an organization of a certain
| scale, but for whatever reason, I've chosen to work in teams
| that are small enough that we can dispense with JIRA all
| together.
| DRW_ wrote:
| I'm on the same page as you, I don't love Jira either, it's not
| something I think about in the conversation of
| "software/services I enjoy using" - but I think it's _fine_.
|
| Jira cloud in our organisation is also reasonably fast, the
| front end can be a bit janky sometimes, but overall considering
| the complexity of the application, it's not too bad.
| tomohawk wrote:
| The problem with Jira is that it is checkbox software, designed
| to sail through the checkbox procurement processes that large
| organizations have. "It checks all the boxes!"
|
| Because of this, it is basically jello. It is everything, and
| it is nothing.
|
| It makes nothing simple, and encourages people to overachieve
| with the tool. If you overachieve with the tool, you will
| underachieve on what it is you're really trying to do.
|
| This is why much simpler tools are better. They are usually
| free, or at least a lot less expensive, and they come with
| constraints that you have to live within. Usually those
| constraints prevent you from going tool crazy, and guide you to
| actually focus on getting work done instead of doing
| performance art with Jira.
| NonNefarious wrote:
| You need SOME kind of tool to provide a repository of issues
| and assignments, and Jira could probably be fine.
|
| But the simplest things are baffling in Jira. Any issue-
| tracking system that requires the users to learn some obscure
| syntax (or even to use SQL to refer to its internal data
| structures is a failure.
| markshead wrote:
| > "Jira is the worst project management tool, except for all
| the others"
|
| This is key. The problem with Jira is less about Jira as a tool
| and more about how we approach project management.
|
| I've seen some teams thrive with Jira. I wouldn't say they
| "loved" Jira but they had a light weight project management
| structure that let them get work done and enough control over
| Jira to set it up to stay out of their way. They didn't give
| Jira credit for their ease of working because it was their
| _processes_ that were good. Jira just gave them a way to not
| have to write everything down on paper.
|
| I've seen other organizations create a horrible project
| management structure and then use Jira to "enforce" those
| structures in ways that magnify all the worst aspects of what
| they are doing. In those situations it is usually more
| politically palatable to blame Jira rather than the management
| processes. Those type of organizations usually blame the tool
| while hoping that a different tool will force the
| organizational changes that are needed to make life better.
| vosper wrote:
| Yeah I've been defended Jira here in the past, too.
|
| My opinion is that Jira reflects the organisation that manages
| it. It's basically a whole lot of customizable UI and
| permissions hanging off a user-defined state machine. You can
| set it up so that individual teams can fully administer their
| own projects, or you can go all the way in the other direction
| and have centralized, locked-down management where you beg some
| internal specialist Jira admin(s) to make your changes.
|
| Also, in the last couple of years it's got a lot better. It's
| faster, there are options for simpler configuration, and more
| stuff out-of-the-box (assuming you're on Cloud, but isn't
| everyone these days?).
|
| In detraction: configuring it can be a huge PITA. So many
| screens, concepts, and so much clicking. But when it's done it
| works, and I think most of the hassle is just inherent
| complexity from such a configurable tool (if you haven't
| Admined Jira: you can change almost anything).
| judge2020 wrote:
| > It's faster, there are options for simpler configuration,
| and more stuff out-of-the-box (assuming you're on Cloud, but
| isn't everyone these days?).
|
| My understanding is that the Cloud offering is the slower
| one, assuming you can dedicate a beefy server (but probably
| under $200/mo on hetzner or ovh for most businesses) to
| running your Atlassian stuff.
| colechristensen wrote:
| Jira doesn't just reflect, it drives convoluted unhelpful
| bureaucracy. The tool drives the organization to look like
| the tool wants it to, which is disorganized half broken
| "organization" with silly overcomplicated rules that give
| people something to discuss enthusiastically instead of the
| actual work that needs doing.
|
| Jira is organization poison, not just a reflection of what an
| organization is.
| oneplane wrote:
| No, it isn't. We have plenty of setups in multiple
| organisations where even within the org only the
| administrative settings of the server are locked down and
| everyone else is free to do whatever they need. Lots of
| teams just use it as a kanban board, while others setup a
| state machine-based funnel to process user/business input
| into usable tickets.
|
| JIRA in its default configuration essentially lets you
| create anything, anywhere in any state. Anything beyond
| that is just bad product configuration. Now, there are
| plenty of products out there that suck no matter how you
| configure it (looking at you, ServiceNow).
|
| Especially the comments about "I would rather use trello"
| seem extremely uninformed as you pretty much *are* trello
| when you just stick to one kanban board and one project.
| Ensorceled wrote:
| > JIRA in its default configuration essentially lets you
| create anything, anywhere in any state. Anything beyond
| that is just bad product configuration.
|
| That's kind of the point, JIRA has been made into
| monstrosity at many organizations because the "create
| anything" mindset.
| oneplane wrote:
| How does that make it a monstrosity? Unless we're talking
| about things that are shared across multiple teams, does
| it really matter how people use it? Nobody is going to
| care what someone else does in JIRA when they aren't
| touching that part anyway. Even with 1000 differently
| configured projects, your 1 or 2 projects you actually
| work with and configure are the only ones that matter.
| colechristensen wrote:
| Because it attracts somebody 4 layers up to tell somebody
| 3 layers up to come up with a common Jira platform for
| everybody and then you don't control how your project is
| run and then Jira becomes the enemy, a faceless
| micromanager driving your work life that has strong
| opinions on how you do everything, a dozen steps that
| need to be done "right" or you get your half a dozen
| managers asking if you read the memo about TPS reports,
| er, Jira tickets.
| oneplane wrote:
| So that is not a JIRA problem since you can do a
|
| > it attracts somebody 4 layers up to tell somebody 3
| layers up to come up with a common
|
| with pretty much everything, including a spreadsheet or a
| plain text file.
|
| Conflating bad business practises with tool configuration
| or products in general doesn't help anyone. If a business
| is very stiff and scared of its employees, they will try
| out all sorts of useless control methods hoping it will
| somehow make some metric 'better'. You can do that with
| Trello too. Doesn't make Trello a bad product, and it
| doesn't make JIRA a bad product.
|
| At the same time, pretending a larger organisation with
| many teams can function without any form of state
| tracking is a nice dream but not a reality either, so
| it's not like you can do without anything at all. But
| like reposted a bunch of times, how you do it and who is
| responsible for it is pretty important.
| colechristensen wrote:
| The point is that there are tools that enable and
| encourage bad behavior. The kinds of organizational
| toxicity simply aren't possible with some tools, sure an
| ambitious executive could try but the attempt would fail
| very quickly. Such attempts to do the broken overburdened
| nonsense that frequently comes with Jira don't fail, they
| are enabled and encouraged. What is technically possible
| and what is likely are two very distant things.
| oneplane wrote:
| JIRA really doesn't encourage anything in any direction
| except writing down what you are up to in a reasonably
| friendly way. Anything beyond that is up to the
| implementors, and there is nothing in the world that can
| prevent bad top-down behaviour within a company.
| msla wrote:
| "The tool can't do it" is an excuse. Excuses aren't
| tolerated. Now, make it happen.
|
| Tools can't prevent bad management because bad managers
| don't care about tools. They care about getting what they
| want, and if the tool doesn't enable it, that's their
| underlings' problem, not theirs. Jira doesn't stand in
| their way because _nothing_ stands in their way.
| colechristensen wrote:
| And how long is this going to last before someone further
| up decides that Jira needs to be unified for reporting
| purposes?
|
| Eventually somebody with the organization obsession is
| going to get hired and put somewhere important and their
| goal is going to be making something complicated and
| unified and dissent will be "discouraged".
| oneplane wrote:
| Depends on where you work I guess. In reality, reporting
| really has nothing to do with SWE state tracking. You can
| also just write a report in a letter and mail it to the
| board. It's not like they are going to log in to JIRA or
| even have an account or SSO-allowed credentials since
| they don't need to be there.
|
| On the other hand, like almost copy-pasted here, if a
| top-down 'unification make it worse for everyone' effort
| is started, no vendor or tool is going to stop that and
| your work will get worse.
| geraldwhen wrote:
| This happened to me!
| femiagbabiaka wrote:
| "Data needs to be unified for my executive use case"
| sounds like an org problem not a JIRA one. I've
| encountered it at companies that didn't use JIRA at all
| asfhagsdf wrote:
| It amazes me how much hate Jira gets compared to
| ServiceNow. My last two roles have been heavy on the
| ServiceNow, and I'd take a fresh breath of Jira any time.
|
| My guess is it's because Jira actively targets SMB, while
| ServiceNow is almost strictly enterprise, and folks in
| enterprise have already resigned to their fate.
| blacksmith_tb wrote:
| Well said. I have to deal with both of them in my current
| role, and while Jira is... not great, ServiceNow is next-
| level-clunky.
| oneplane wrote:
| I think the comparison mostly stems from the legacy
| enterprise where badly configured tools are pushed top-
| down and workers are told to 'deal with it'. Either
| you'll be a developer mostly using JIRA or a non-
| developer mostly using ServiceNow, and if you're really
| unlucky in such an organisation you'll be using both.
|
| Having a Service Desk that actually provides usable and
| composable tooling is a benefit for all. Having a random
| contractor "implement" ServiceNow because Gartner said so
| is a pain for all. This is of course a bit of opposing
| extremes, but the same applies to JIRA and AD and pretty
| much anything else. Hard-pushed bad implementation will
| ruin your workday.
|
| Teams that are capable and allowed to self-steer and
| deviate from company policy if they come up with a good
| enough reason seems to be the sweet spot of attainable &
| realistic.
| mathattack wrote:
| And try to get a straight answer on pricing from the
| ServiceNow rep...
| _jal wrote:
| The answer is "way more than is sensible, even factoring
| in how absurd pricing on crap like this has gotten."
|
| We dropped SN a couple years back over this. They were
| charging us about 6-7x what we pay for Jira, and we still
| use the on-site enterprise version of Jira.
| oneplane wrote:
| We have a few of those around as well. While they work
| fine, I don't really get why anyone would want to self-
| host JIRA or any COTS product like that anymore. Most
| instances now seem to be just a case of "our hosting
| company is fully responsible for it and it's pretty cheap
| and reliable" and until it starts failing or falling
| behind the cloud offering it'll probably stay like that.
|
| Usually, if it isn't better from a staff-perspective or
| better for the customer, self-hosting or self-building is
| less likely to be the answer these days.
| shagie wrote:
| Self hosting is sometimes easier to do than to argue with
| data governance about putting the information out a
| system that is offprem. The additional precautions for
| HIPAA or PII data that may show up in the comments or
| attachments can problematic. There are far too many users
| of all stripes that copy and paste data that they have
| access to without doing a check on it to see if it really
| _does_ belong there (and if it does belong in the issue,
| then applying appropriate permissions to the object).
| colechristensen wrote:
| I have only ever seen servicenow used for... well,
| service requests. Reset my password, grant access, create
| this resource. Always administration, never product
| development.
| bragr wrote:
| Jira is highly flexible and customizable, almost to a
| fault. One Jira can look and operate almost totally
| different to another with enough customization. If Jira
| feels inflexible and bureaucratic to you, I'd argue that's
| only a reflection of how your Jira admins operate or the
| rules they are forced to implement.
| Redsquare wrote:
| Jira admins....says it all
| colechristensen wrote:
| >customizable, almost to a fault
|
| Customizable, absolutely to a fault. It is the infinite
| customizability of a tool targeted towards middle
| management which is why Jira can go to hell.
|
| It is indeed possible to not be in Jira hell, but
| inflation of complexity is inevitable and almost entirely
| irreversible. It encourages and accelerates the path
| towards bureaucratic hell. Any avoidance of this is a
| temporary aberration.
| lmm wrote:
| It's not a neutral tool. Jira makes micromanagement easy and
| trusting people hard; you _can_ use it for good, but you 're
| working against the grain of it the whole time. Everything is
| default deny (issues can only go through approved
| transitions, by default regular users can't change the
| available transitions), the default issue forms have way too
| many mandatory fields, and a bunch of reports that only
| micromanagers want or need are front and center in the UI.
| arcticbull wrote:
| I find Jira isn't a tracker, it's a tracker construction
| kit.
|
| You can make it be pretty much anything you want - except,
| you know, fast.
| Frost1x wrote:
| I view Jira as the embodiment of the misguided software
| engineering practice of trying to generalize and abstract
| too high level of a task of something like "project
| management" and distill it down into one tool.
|
| While the Golden perfect abstraction handed down for the
| heavens by the gods is what you seek, it ultimately
| passes down complexity to end users through its generic
| approach. You need to create opinions within the generic
| world and then your team needs to understand Jira's
| abstraction combined with the opinion your company builds
| around it that's probably not documented.
|
| The end result is unless you're running a large project
| that really requires the functionality possible in Jira
| where creating the overhead or overloading something
| simpler isn't practical, then you're probably better off
| using something simpler and more opinionated--a nice
| simple solid framework to keep everyone on track.
| tharkun__ wrote:
| Almost none of that is true depending on which version of
| Jira we are talking about and what type of project you have
| chosen.
|
| I'm in the Jira is actually pretty good camp. I've
| administered Jira instances from the ground up, including
| installation, integrating it with directory services,
| customizing workflows or just as a user in large and small
| organizations.
|
| The defaults even way back when actually made quite a bit
| of sense. The default workflow for many project types were
| very workable. Some transitions make more sense than
| others. It was also quite tedious to create transitions
| from "all other states" to some state. So admins were
| incentivized to only allow transitions that immediately
| made sense to them and not bother with the others. From the
| end user perspective this obviously looks like draconian
| overlordship. While in reality in many cases its just too
| tedious. Atlassian has heard user complaints though and an
| "all states can transition here" option is available since
| some time ago and the default workflow for some types of
| projects are basically just a few workflow states that all
| have this transition as the only possible one. That's
| pretty open.
|
| If your organization chooses to instead use this very very
| configurable tool to lock things down you can't blame Jira.
| Locked down workflows and transitions, restructured
| editability etc do have their place in many valid use
| cases. A simple one being as a customer facing tool where
| you need to enforce certain things directly because your
| customer is not first going to learn your conventions and
| then self apply these.
|
| The same goes for mandatory fields. The only mandatory
| field you have to choose yourself really is the issue
| summary. Everything else if mandatory by default has
| default values. I have used many a Jira instance where
| Priority (a default mandatory field that also has a default
| value though) was all but ignored by everyone even if it
| was still on screen.
|
| Can you elaborate on the reports that only micromanagers
| would ever use? I agree that some of them can be used by
| micromanagers as can a lot of Jira functionality. There are
| many that can also be very useful directly in the hands of
| teams.
|
| Team managed projects are awesome because sharing Jira
| admin rights in a large org was hard. Because things are so
| configurable a good set of naming rules were essential. It
| was usually easier to set up individual instances for
| projects instead of having a shared instance for large
| orgs. And if you centralize administration too much then
| changes grind to a halt. I have shared admin right with
| many others successfully though where these standards were
| adhered to by everyone and changes to work flows, issue and
| custom field definitions and such were easy to get through.
| Just required discipline.
| vosper wrote:
| If you sign up to Jira today and start a new project,
| you'll get the options of a simple workflow with a minimum
| of fields. The beginning statuses are basically "to do",
| "in progress", and "done". There's a fair amount of trust
| in those steps, IMO.
|
| > by default regular users can't change the available
| transitions
|
| I can't imagine allowing this. This would be a recipe for
| chaos. The transitions are supposed to indicate agreed-and-
| defined steps that work goes through. They're supposed to
| reflect your team/org process, to the granularity that you
| want to capture it in Jira. Letting anyone edit them ad-hoc
| is akin to saying there is no process at all for doing
| work. How would anyone be able to interpret the state of
| work if everyone has their own ad-hoc process that they can
| change on the fly?
|
| If that's okay on a team then that team probably shouldn't
| use Jira. I also would not want to be the team-lead, or
| anyone else trying to figure out what's going on or keep
| track of work!
| xedrac wrote:
| I realize company-wide planning is extremely hard,
| especially when there are many inter-dependencies that can
| block entire departments if a single deadline slips. But in
| my experience, the only thing that Jira brings to the table
| is the ability to document, in a centralized place, the
| pieces of work that need to be done, and what stage they
| are currently in. In my field, anything software related is
| really hard to estimate accurately, which makes the whole
| aggregate estimation in Jira not only worthless, but
| actively harmful because management will treat it as truth.
| We could replace Jira with a big whiteboard of TODOs and
| we'd likely get things done faster, and with higher
| quality.
| pid-1 wrote:
| > the default issue forms have way too many mandatory
| fields
|
| I only fill points and name for my issues. My company never
| customized anything.
| throwaway3l2ff wrote:
| Yes, we switched to Jira from a piece of abandonware (simple
| php based bug tracker) several years ago. Jira is kinda slow
| sometimes, but not horrible. And yes, like you said, once you
| get it configured it works great.
|
| Overall, we are very happy with Jira and it's worth the cost
| for the value it brings to the organization (still hurts the
| wallet, but it's at least justified).
|
| ...and then Atlassian comes along and rug-pulls on-prem Jira.
|
| We only have ~80 users, so 1000-user-minimum data center
| isn't going to cut it for us. And there is an on-prem
| requirement, so no cloud option either (wouldn't want to
| anyway). And for that, I bitch. Fuck Atlassian and everything
| they do to appease their shareholders before the customers.
| madmax108 wrote:
| "My opinion is that Jira reflects the organisation that
| manages it."
|
| Came here to say EXACTLY this. I've used Jira across 3
| companies, and in the first 2, I always felt like folks
| complaining about Jira were just being picky developers
| wanting the sun, moon and the stars, because Jira worked
| perfectly fine for me and my team (in fact, it was the
| backbone of our process).
|
| Then in the third org, I felt like I was hit with a brick
| wall of every single issue folks complaining about jira point
| out. Needless workflows, Middle Managers wanting to "control"
| how stories/epics get closed, multiple levels of convoluted
| manual configurations, automated processes creating Jiras
| that for trivial non-issues which clogged notifications and
| team backlogs and brought jira to a crawl etc. Heck, at one
| point, the mess got so bad, that the company considered
| hiring a third party to "fix" our Jira workflows. And note
| that this was a <100 person startup!
|
| On introspecting, I completely felt that in the first 2
| companies, the organization was structured around "getting
| stuff done" and "keeping stuff as simple as possible, but no
| simpler" and that naturally flowed into how Jira was set up
| as well, while in the latter, the focus was entirely on top-
| down "process", and that showed in the Jira setup as well.
|
| Honestly, I now think I can say a lot about a company's
| engineering/product culture just by spending 15 minutes on
| their Jira ;-)
| SamuelAdams wrote:
| This applies to all enterprise software. It's also called
| Conway's Law:
|
| Any organization that designs a system (defined broadly) will
| produce a design whose structure is a copy of the
| organization's communication structure.
|
| https://en.wikipedia.org/wiki/Conway's_law
| msbarnett wrote:
| The central problem with JIRA is that, once you've gotten
| beyond the overly customizable functionality and difficult-
| to-reason about permissions, and once you've managed to avoid
| organizations that go too far off of the deep-end and once
| you've finally found a happy simplicity in a kanban-ish
| board,
|
| once you've done all of that, it is _still_ unbelievably,
| unjustifiably, just incredibly and amazingly so very very
| _goddamn slow_.
| andy_ppp wrote:
| There's a screen in jira if you change multiple items with
| a progress bar. I looked once and the operation seems to
| happen instantly and the progress bar is just there because
| of some bad designers ego...
| plonk wrote:
| As someone who uses both, let me recommend to you Microsoft
| Teams, the only enterprise software that manages to be
| slower.
| ketzo wrote:
| Additionally, people's associations with Jira are not strictly
| related to the software itself.
|
| Jira is often the domain of PMs, management, and other
| leadership; if you have bad people / product leaders, you're
| used to Jira being a source of great stress.
| thedougd wrote:
| I was asked during a merger, which work management tool do you
| think we should keep/use? I replied, don't ask me, I'll hate it
| anyways.
|
| It's not because I hate Agile, Scrum, or even Waterfall
| (although I do hate SAFe). I just know these tools all suffer
| from similar drawbacks, and somebody will ultimately codify all
| our organizational problems into the tool. Then, rather than
| spend an hour a week of their own time, they'll create a new
| mandatory field and ask thousands of people to spend an hour a
| week each populating that field.
| lmm wrote:
| Sounds like a strong argument for using a tool that doesn't
| have custom mandatory fields. They do exist.
| ZainRiz wrote:
| > why don't you think some other company has come along and
| toppled the Jira crown?
|
| Jira is the way it is because Jira ISN'T built for developers.
|
| Devs may have to use Jira, but they're not the ones who have to
| pay for it.
|
| I wrote about this a while back:
|
| "Who is Jira's target customer? It's certainly not the poor
| developer who struggles to add a link to his bug report. (I'm
| still mad at them)
|
| Take a look at Jira's site and see what they emphasize:
|
| Those pages glamorize having an overview of what work your
| employees are doing. It's a tool made for managers. Especially
| higher level ones. The VP won't be filing work items, but
| they'll be very interested in the insights those dashboards
| offer.
|
| Jira spends all their software cycles building new features for
| that VP, ignoring what you and I might consider critical user
| bugs."
|
| Source: https://www.zainrizvi.io/blog/never-focus-on-the-
| user#jira-s...
| bamboozled wrote:
| Which is funny because 99% of what project managers seem to
| be about is making sure work gets done. So the first thing
| they do is deploy a hurdle to this by ensuring they use a
| tool which is time consuming and confusing for the people who
| do the work (usually developers to use).
|
| JIRA is so slow and the UI so clunky the project managers
| where I work use some type of spreadsheet upload mechanism
| with XML spreadsheets to automate the cruft creation. It's
| fun to watch.
| ratww wrote:
| Yep. We often talk about enterprise software, and how it's
| often bad and, has superfluous features and almost no UX
| design because it is made for buyers rather than for the real
| users. Well, guess what. We're the users now.
| colechristensen wrote:
| >The problem I have with the incessant Jira bitching is that I
| rarely feel that bitchers have a true understanding for the
| extreme difficulty of the organization-wide problem Jira is
| trying to solve.
|
| I think the core problem with Jira is organizations trying to
| use it to solve complex organization-wide problems. It is an
| enormous time sink, and using Jira to rule the workdays of
| employees is the problem.
|
| Anything much more complicated than a checklist is wrong. Jira
| is an attractor for middle management growth that gives people
| who don't need to be doing anything something to do, and adding
| complexity gives more opportunities for more people to not do
| very much and generally get in the way of execution. It is also
| a way to give people who aren't very necessary or very good at
| understanding the big picture something that they _can_ do _to_
| do.
|
| Take away Jira and _tools_ that you can order other people to
| use and you end up with middle management that literally doesn
| 't know what to do because they couldn't organize or ease
| productivity to save their lives. Jira becomes the thing being
| managed instead of whatever is actually to be done.
| oneplane wrote:
| If a company is trying to use JIRA for more than state
| communication they are doing it wrong IMO. Planning goes into
| calendars, ephemeral stuff goes into chats and calls, and
| code and code-level issues goes into repositories. I have
| seen plenty of attempts to make a product like JIRA the
| 'interface' between some management person and 'the
| subordinates' and it never works, simply because trying to
| place an 'interface' there in itself doesn't work.
| ryanbrunner wrote:
| I think what other tools miss that JIRA did well is giving
| engineering managers _tools_ to communicate with upper
| management. You 're right that actually attempting to use
| JIRA as the medium of communication with people outside the
| product org is hopelessly, fatally flawed, but being able
| to visualize an issue like an unmanageable backlog, or team
| productivity, or quality issues is invaluable, and a lot of
| simple tools throw the baby out with the bathwater by
| completely failing to give any tools to analyze how your
| team is doing.
|
| If it's configured properly, JIRA can be a fairly effective
| tool that mostly stays out of the way of developers but can
| help team leads and managers communicate things about the
| team.
| oneplane wrote:
| That is indeed what happens with the simpler JIRA clones.
| On top of that, usually the org has no idea what is going
| on, who is working on what or what is still waiting to be
| looked at by anyone.
|
| Normally those issues would be handled with a simple 5
| minute meeting (DSU or some variant thereof) where
| everyone shares their current state, and then a few times
| per month some form of "where are we and where are we
| going" type of planning. (Be it a sprint planning or
| something like it) Combining that with a state tracker
| seems like a fairly obvious thing to do, and having the
| tools to then report on that over time (graphs can be a
| helpful visualisation that simple tools usually lack)
| gives everyone some context as to how healthy the team
| is.
|
| But even that last bit, the concept of periodically
| having a bit of a check up to see how things are going is
| often lacking in "we can do it better and simpler" types
| of setups. In then end, it gets reduced back to the
| manager walking around with a whip shouting "work
| harder!" instead of teams having some autonomy and
| figuring their own state out themselves.
| colechristensen wrote:
| >If a company is trying to use JIRA for more than state
| communication they are doing it wrong IMO.
|
| This is why tools that _don 't allow_ this kind of doing-
| it-wrong are significantly superior to Jira.
| oneplane wrote:
| That's a nice theory, but in practise people have been
| mailing to Slack, using meetings to read emails and using
| JIRA to track Git commits.
|
| Tools are just slaves to reality, not the other way
| around. If a legacy top-down organisation wants you do to
| a certain thing a certain way, and you have no recourse
| but to do as you're told, that's your organisation's
| fault and nothing else. You can either gain a position
| where you can make changes, or leave the company.
| Complaining about a tool that has no influence over your
| work process really doesn't change anything.
| lmm wrote:
| > Tools are just slaves to reality, not the other way
| around. If a legacy top-down organisation wants you do to
| a certain thing a certain way, and you have no recourse
| but to do as you're told, that's your organisation's
| fault and nothing else. You can either gain a position
| where you can make changes, or leave the company.
|
| That's naive; tools influence the way they're used. When
| a tool defaults to having manager accounts that can
| change how things get done and developer accounts that
| can't, it nudges the organisation in that direction.
| synu wrote:
| Agreed, it's like a big flashing neon sign that promises
| middle management a stage on which to act out all their worst
| impulses. It's the exact opposite of "keep it simple and
| communicate with each other like humans."
| bamboozled wrote:
| 100% agree, in my current role it's used this, if what
| you're working on doesn't have an issue, you're a naughty
| person.
| matwood wrote:
| I agree. I routinely explore JIRA replacements b/c of various
| JIRA annoyances, but none of the ones I find will hook into our
| process as neatly as JIRA.
|
| JIRA is a lot like agile though where everyone is using a
| different version ranging from this works fine, to this is a
| dumpster fire.
| Ensorceled wrote:
| > The problem I have with the incessant Jira bitching is that I
| rarely feel that bitchers have a true understanding for the
| extreme difficulty of the organization-wide problem Jira is
| trying to solve.
|
| No, I have a really good understanding of that. My problem is
| that Jira, in actual implementation, tends to be how some parts
| of the organization (often Product) tries to exert fine grained
| control over other parts of the organization (design, qa,
| development, operations, etc.) by micromanaging the process.
|
| Also, sometimes your organization is just not that complicated.
| I've been in startups using Jira with dozens of states, with
| complicated transitions and approval steps, that would have
| been over kill in medical companies I've worked at.
| mixedbit wrote:
| Issue tracking is difficult in general. Any piece of software can
| be improved or extended in an infinite number of ways. Ideas for
| improvements are often too eagerly turned into issues, which
| looks like an easiest way to quickly deal with an idea, but soon
| issues management becomes an overwhelming activity.
| ngvrnd wrote:
| Ooh ooh! Now do git.
| lisper wrote:
| 29athrowaway wrote:
| I fucking hate JIRA because it encourages people to create and
| abandon tickets for years, creating an alternate dimension of
| irrelevant trash that gets in the way of doing things.
|
| If your team has an append-only doctrine to information, like
| most tech debt mills in the industry have, JIRA will become an
| extension of that ever increasing pile of unmaintained,
| disgusting, revolting monolith of excrement that captures every
| activity in software development.
|
| Nothing can be done about the gigantic monolith of soul crushing
| chaos therefore we need to embrace it, at the expense of our
| sanity. Nothing can be done about the hopeless hoarding of
| irrelevant, duplicate tickets that distract people from work.
|
| JIRA makes it very easy to create new tickets, and much harder to
| close them. So naturally it becomes a virtual sewer. JIRA is
| about being able to present a large amount of information to
| easily impressionable people so that so some people can justify
| their job.
| amerine wrote:
| One word: GUS. IYKYK
| Jach wrote:
| The worst part about it is that it's actually not the worst,
| proved if only by getting worse over time, but also that Jira
| can easily be configured by management to be worse...
| [deleted]
| s0uthPaw88 wrote:
| Jira works well for my organization. I think the simplicity of
| our setup is the key. We have just 4 issue statuses: Not Started,
| In Progress, QA, Done... also no restrictions on state
| transitions. Any status can move to any other status. Each team
| gets their own project so that they can easily manage their own
| issue backlog. That's pretty much it. My team also uses a plug-in
| for async planning poker which is useful.
| EastSmith wrote:
| I use Jira for 10, 20 minutes a day every day, and it almost
| always works just fine. Not spectacular or anything, but just
| fine.
| teilo wrote:
| This is not a rant about Jira. This is a rant about doing Agile
| in the enterprise.
|
| I can rant about Jira, but it's about the horrible UI. It's
| buggy. The settings system is a mess. It's not intuitive. Even
| clever people need hand holding to figure out what's going on.
| Things randomly break for no apparent reason.
| gladed wrote:
| Jira does for software engineering what software engineering does
| for everything else.
| mm007emko wrote:
| After spending some time with Trac, Redmine and IBM ClearCase, I
| have to say that Jira and MS AzureDevOps are not THAT tragic.
| However it's a tool targeted at managers, not us, developers. At
| my previous company one of the KPIs was a number of closed Jira
| issues. Total BS, needless to say.
| khalladay wrote:
| Where I work got rid of Jira and switched to some other,
| ostensibly better(?) competing product. I never had strong
| opinions about Jira before the switch, but now, after nearly 2
| years of a Jira free existence... I miss Jira dearly. The grass
| is always greener.
|
| Does Jira suck? sure maybe, but my personal experience suggests
| that everything else sucks equally as bad if not worse, and I
| know where all the buttons are in Jira.
| cosmiccatnap wrote:
| Yea yea yea...but you still use it because the alternatives while
| better performing and even more secure...are not as feature rich
| or as well known.
|
| I feel like this thread comes up in one way or another every few
| months but in a place where people almost have a hellbent desire
| to reinvent wheels nobody has reinvented this one in say...go or
| rails or whatever.
|
| Why? Because for all of the hate jura actually does what it does
| pretty well when it's working and for most people and most
| businesses that aren't your homelab it works just fine provided
| you pay someone to maintain and administer it.
| gboss wrote:
| Jira drives me crazy. Why do I need to mark an epic as closed two
| different ways? Why is it really difficult to see what tickets
| were in a closed sprint? Why is it so slow or why does it
| sometimes get in infinite reload loop? Features randomly break
| like the ability to create tickets from confluence. My company is
| locked in and I doubt we would change, I just wish Atlassian
| focused on performance and consistency
| CivBase wrote:
| I'll start complaining about JIRA when I find a reasonable
| alternative for my organization. Until then, I'm just glad we're
| not using IBM Rational ClearQuest anymore.
| dvtrn wrote:
| I wanted to make a site very similar to this but for Jenkins.
| Even bought a domain for it.
|
| And never built the thing.
|
| Some of these made me chuckle.
| givemeethekeys wrote:
| The two people who drove our company to Jira from other tools:
|
| - One of them resigned soon after the migration.
|
| - The other barely uses it today - in fact, he found other tools
| for his team because Jira is too cumbersome.
|
| The rest of us are left holding the bag because "Jira is the
| industry standard".
| hinkley wrote:
| Struts was an industrial standard for longer than most things,
| and everyone hated using it for most of that time.
|
| A quarter pounder with cheese is an industry standard too, but
| that doesn't mean you should give it preferential treatment.
| Industry standards are often more like consolation prizes than
| a special experience.
| arnvald wrote:
| I've used Jira in my last 3 jobs. I tried to like it, I tried to
| tolerate it, now I just try to spend as little time using it as
| possible.
|
| I'm an engineer, I'm a problem solver. I want to add a task, move
| task to "doing" and then "done" and that's it. But Jira is not
| created for me. Jira is created for SAFe expert who wants to
| create workflow so complex nobody understands it. Jira is created
| for Scrum master who wants to create 25 reports to show their
| boss how beautifully our burndown looks sprint after sprint. Yes,
| Jira doesn't force anyone to do this stuff, but it enables it,
| because Jira is created for process managers, for people who just
| report things.
|
| But that's not me. Jira is not for me and the best I can do it to
| use it as little as possible.
| lizardactivist wrote:
| Edgy.
| derelicto wrote:
| Not affiliated but linear.app looking good
| akamaka wrote:
| I'm starting to wonder if one of the best features of Jira is
| that it directs all of the developer hatred away from management
| and toward the task-management software. I've worked on projects
| that used Jira very effectively, so I'm convinced that all of the
| complainers actually not fully aware of how bad their managers
| are.
| alephxyz wrote:
| JIRA configs are usually the visible manifestation of your
| organisation's processes. It's Conway's law applied to task
| management workflows.
| sshine wrote:
| I don't remember Jira as being that bad.
|
| It was mostly the Scrummy culture that seemed like a bit of a
| waste of time.
|
| I wasn't a big fan of the wysiwyg editor. This seems to address
| mostly non-technical people. I would always go for "Markdown with
| preview" (HackMD split-screen, or GitHub issue tabs, or Discord
| apply-formatting-to-codes).
|
| I also don't like that it isn't an integrated part of a pull
| request system. GitHub/Gitea issues inter-linking with PRs in the
| same namespace is... golden. With the right habits, you can
| become an effective time-traveler.
| lazyant wrote:
| Meh Jira is OK and people who hate Jira I feel like they really
| hate any process. I've used other tools and they are mostly the
| same.
| rsstack wrote:
| I was one of the Jira admins two jobs ago (in additional to more
| normal responsibilities of product management & engineering). I
| finally got back to Jira at my current company and I texted an
| ex-colleague who was also an admin of the same Jira server (also
| part-time):
|
| "We're starting the migration to Jira. The next sprint will be
| entirely in Jira. Honestly, I kind of missed it."
|
| She replied: "That's the real test of a tool. Not 'would you
| recommend it to a friend?', but 'if you were to start a company,
| would you use it again?'"
|
| And - I would and did with Jira. If you know the tool well, and
| your company doesn't have stupid technical workflows and human
| processes, it's just great. Too many people suffered from using
| it wrong or suffered from using it with the wrong colleagues.
| lolc wrote:
| What's the secret of making it acceptably responsive? Asking
| for a friend.
| wizofaus wrote:
| From what I've read it's the cloud hosted version that's
| slow. Seems to be fine locally hosted, and probably if you
| host yourself with another cloud provider. Unless by
| "responsive" you mean works well on tiny screen devices...
| plorkyeran wrote:
| The self-hosted version is discontinued and you can't buy
| it any more if you aren't already a customer.
| originalvichy wrote:
| Incorrect. The cheapest license version is discontinued,
| "server". Data center license is not.
| tormeh wrote:
| I suspect issue tracking software is one of those domains where
| if a piece of code hangs around for long enough it will become a
| mess due to incentives. Which begs the question: What are y'all's
| opinion on the open source competitors? Redmine, OpenProject,
| Apache Bloodhound, and whatever else exists?
| ch_123 wrote:
| Jira is a product which serves two masters - one are development
| teams which use it to track bugs, tickets, projects, etc. The
| other one are middle management types who use it for project
| tracking, reporting to upper management, tracking metrics of
| different teams (no matter how dubious) etc.
|
| The people who decide which software gets adopted internally
| generally care about the latter, and thus Jira is selected, and
| thus Jira grows to their needs - where complexity is often a
| bonus, and poor day to day performance a minimal concern.
| system16 wrote:
| Examples escape me at the moment, but there have honestly been so
| many times I've hit a wall trying to do - what seem to me like -
| basic things in JIRA; I couldn't comprehend how such a complex
| tool could not accommodate them.
|
| And the stuff that can be done is often so comically painful it's
| mind-blowing. Trying to do something as seemingly simple as
| create a useful saved search in JIRA is so painful I can't
| imagine its creation was not an act of sabotage.
| MediumFalse wrote:
| Due to the slow loading, I ended up writing some simple Jira API
| wrapper scripts for submitting bug reports quicker in our
| systems. I don't see our organisation switching anytime soon.
| smileybarry wrote:
| I _used_ to like JIRA, back when it was _only_ issues /tickets.
| It was essentially a nice, organized database for humans that you
| could sift through with precise filters & searches. Bug applies
| here, workflow describes where handling it is in the pipeline,
| issue _types_ meant you could filter by "what is this", etc.
|
| I loved using "basic" JIRA, mentioning issue IDs in places to
| clearly reference a web of "why this bit of code is the way it
| is", so someone digging into source code can self-answer stuff
| like "why not do X". (e.g.: because it caused a bug for Y)
|
| Now there's _stories_ , and _boards_ , and _sprints_ , and
| _agile_ , and the worst part is that they all interact like crap.
| Why do "tasks" and "stories" exist? Why not the old: New Feature,
| Bug, Improvement? At least with those you could always see at a
| glance _what_ that issue is.
| Graffur wrote:
| Wait until you try Microsoft DevOps boards
| janaagaard wrote:
| I agree that Jira isn't wonderful, but I can't think of any of
| any task management system that I have used, that I would
| recommend.
|
| Are GitHub Issues the answer? I have only tried those for small
| open source projects and not big enterprise projects.
| nlh wrote:
| I promise I am not a shill: Our team is on the verge of switching
| 100% to ClickUp. Are we crazy?
|
| Nobody really loves Jira, and we've gotten our Product, Design,
| Sales, and Customer Success teams using ClickUp and everyone is
| really happy so far (especially with the speeeeeeeeeeed. OMG
| coming from Jira it's a breath of fresh air).
|
| We are chasing the dragoon of having a single tool and everything
| in one place. So far the eng team seems amenable to give it a
| shot (although we're going to transition slowly).
|
| Are we crazy?
| antux wrote:
| Not surprised that many are having a bad user experience with
| Jira. The interface design and usability is atrocious because
| it's a tool designed by developers. Developers lack the UX
| training and thinking that's needed to make the tool intuitive
| and easy to use.
| ChrisMarshallNY wrote:
| Reminds me of this classic piece of Internet lore:
| https://www.internetisshit.org
| throwaway787544 wrote:
| I don't. I use it every day and rarely ever have an issue. It's
| well integrated with Confluence. There's even some decent CLI
| tools now (still young but have promise) that mean we could
| automate away the interface.
|
| All the reviews I see on that site seem to be upset that it might
| require training, or that their project's admins have made it a
| nightmare. It's not a nightmare out of the box.
| shadowtree wrote:
| The people hating on JIRA never worked in a shop without it.
|
| If you're old enough to remember before Atlassian came along -
| just how was it better? Spreadsheets? Trax?
|
| You don't want structured workflow? Don't work in a company with
| more than 5 people.
|
| "I am an accountant and hate ERP" .. tough shit, for real.
| 01100011 wrote:
| For the first 20 years of my career I worked with organizations
| that used Gantt charts and MS project combined with a dedicated
| project manager to keep things in sync with actual progress. It
| was minimally invasive to engineers and didn't require them to
| do the soul-sucking JIRA dance. It also generally delivered
| dozens of projects on time or with reasonable delays and
| surprises.
|
| Even when working on 'buckets of tasks/bugs' where Gantt charts
| don't make sense, a locally customized version of Bugzilla or
| other bug tracking software(i.e. Phabricator or whatever)
| worked very well.
|
| There is a generation of engineers that has only known Agile, 2
| week sprints, and shitty software to manage it. After having
| used Jira at two companies for the last 4 years I can say it is
| one of the worst pieces of software I have ever been forced to
| use and lowers productivity from multiple angles.
| [deleted]
| djhaskin987 wrote:
| > Also LOL to SourceTree. The git command line commands aren't
| exactly rocket science.
|
| This one caught me off guard. I know of no other free GUI for git
| that's as easy to use or install.
| oneplane wrote:
| Ironically, most of the stuff seems to be about Confluence. And
| almost all of the commentary is about bad company workflows and
| bad company processes and not really about the product itself at
| all.
| Nextgrid wrote:
| What I really hate is not Jira itself, it's the company behind it
| and its engineering practices. Their mediocrity goes beyond Jira.
|
| They've had server-side-rendered features that while slow,
| contained the slowness to the backend and bundled it into one
| single slow request - once you waited for that, you had a fully-
| working page in your browser. Since it was all on the backend,
| your browser remained responsive while waiting.
|
| Nowadays however there's no longer a single operation to wait for
| - they've split their pile of shit and offloaded it to your
| browser. You have to wait for the backend which is slow, but then
| you _also_ have to wait for megabytes of JS to load & execute in
| your browser, all while the page moves around and your CPU is
| pegged at 100%. And God help you if you click on something by
| accident, as "undoing" that means waiting for another load. To
| add insult to injury, _everything_ is clickable and triggers some
| actions, even elements that represent content and that you wouldn
| 't normally expect to be clickable (nor would want to - let's say
| you wanted to copy the text).
|
| Recently they've added another annoyance - in Bitbucket they've
| done some changes with regards to diff rendering and obviously
| have to let you know. They do so via a _persistent_ floating
| popover in the bottom-left of the screen that you have to
| manually dismiss and the dismissal status seems to be contained
| to the browser - if you switch browsers or use private mode you
| have to deal with it continuously.
|
| My experience with Atlassian products has actually deteriorated
| _despite_ CPU speeds, browser performance & network connections
| improving. I used to have a mostly positive opinion of the
| company 5 years ago but that's no longer the case.
| lordleft wrote:
| What are some alternatives to JIRA? Also, how much of the hate
| directed towards JIRA buried resentment towards Agile and other
| project management paradigms?
| CookiesOnMyDesk wrote:
| Backlog by Nulab is pretty much all the good features of Jira
| distilled down into a simple product. I've used it and been
| very happy with it. https://nulab.com/products/backlog/
| ibiza wrote:
| I had no issues using YouTrack from JetBrains. It's fairly
| lightweight w/ a focus on ticketing (MarkDown + images), good
| search, and Kanban views, if that's your thing.
|
| https://www.jetbrains.com/youtrack/
| chillingeffect wrote:
| >Agile >resentment
|
| Yup.. at least fake agile... where every "sprint" is the same
| length and features aren't customer-oriented.
| alluro2 wrote:
| We switched to Quire (https://quire.io) - it has a generous
| free plan, it's simple yet very flexible, and, most importantly
| for us, quick enough to not be a chore to update (Jira was
| horrible). Some small UI bugs here and there, but
| inconsequential.
| trhway wrote:
| > Also, how much of the hate directed towards JIRA buried
| resentment towards Agile
|
| it is kind ironic, yet pretty typical and very telling, that
| the slow as hell Jira is tightly associated with Agile
| t3e wrote:
| Shameless plug for Constructor[1], we're early (new website on
| the way) but have a bunch of happy customers, many of whom came
| from Jira, the rest mostly from Trello (to which we're most
| often and justifiably compared, we keep it simple!)
|
| 1. https://constructor.dev
| jamal-kumar wrote:
| If self hosted is your thing I like taiga for kanban integrated
| with gogs for the issue tracking/VCS integration side of
| things. Didn't take me more than a day to get working and
| everyone signed up on it, isn't a lot of maintenance, just
| works, costs nothing.
| Ancalagon wrote:
| Highly recommend ClickUp
| ianbutler wrote:
| PivotalTracker, GitLab has pretty great project tracking and
| ticket management if you're on them. These are the two I can
| think of off the top of my head. Personally I really like
| Pivotal.
| halostatue wrote:
| Pivotal Tracker is only good if you buy into the way that it
| works and are willing to lose all knowledge that your tickets
| represent.
|
| Pivotal is really only good at a particular _type_ of project
| tracking (mostly building greenfield features and projects),
| and absolutely _godawful_ at issue tracking.
|
| I'll use JIRA over Pivotal any day.
| bsuvc wrote:
| I like shortcut and use it whenever I have a say in the matter.
|
| https://shortcut.com/
| mattpallissard wrote:
| Shortcut is pretty stripped down and lacks several features
| conducive to cross team collaboration. In particular I
| dislike shortcut's lack of internal comments. It's a much
| bigger annoyance than anticipated.
|
| I dislike atlassian products in general, but having some
| discipline with the config/workflows was much better than
| shortcut.
| jtcruthers wrote:
| > lack of internal comments
|
| What do you mean by this? There's a section to comment in
| each card/epic/milestone and you can ping team members.
| Comments also sync with slack so you can get notifications
| there if you'd like. I don't have a ton of JIRA knowledge,
| so there's a chance I'm missing something.
| casion wrote:
| Slightly more than a +1, the team I work on switched to
| Shortcut and the quality of our tickets went up, more tickets
| were resolved, and fewer ended up lingering in backlog hell.
| Why? I'm sure there are many possible reasons, but the
| results stand on their own.
|
| There was no directive other than "Ok, we're going to use
| this tool for now". Everything was self-organized within the
| bounds of the business/stakeholder goals.
|
| I'm sure you can use either Jira or Shortcut in a manner
| which makes either tedious, but at face value we found
| significant improvements simply through adopting Shortcut.
| typeofhuman wrote:
| https://ora.pm
| nightwatchinc wrote:
| Linear.app
| RedShift1 wrote:
| Depending on what you use it for, Gitlab springs to mind
| y0ssar1an wrote:
| https://monday.com
| SigKill9 wrote:
| For something less task-focused and more customer-oriented, we
| built https://www.kitemaker.co :)
| bobbygoodlatte wrote:
| Linear https://linear.app/
|
| It's a joy to use
| imdsm wrote:
| <!-- Atlassian, please don't sue me.
|
| -->
| kerbs wrote:
| I can't take credit for this, but I also don't recall where I
| heard/read it from:
|
| "Most teams would be better off using a shared spreadsheet for
| task management than they would using Jira"
|
| Rings true to me to this day.
| imdsm wrote:
| "<!-- Atlassian, please don't sue me. -->"
| therufa wrote:
| part of the hatred has to come from the fact that it's a tool
| used for hidden micromanagement. Whenever I experienced Jira
| being introduced into the workflow, human connection vanished,
| work became laboring and many times the better devs left the team
| due to lack of autonomy. Who remained were the people who didn't
| mind to just work and never question, like factory workers of the
| 1900's.
|
| I don't mind using Jira as a verbose platform which aims to map
| project state and helps communication BETWEEN all participants,
| but this is rarely the case, especially with all those pseudo-
| agile practices that are part of mainstream software development.
|
| Another part of the hatred may come from the fact that it's an
| overcomplicated tool for a moderately simple task. This
| complexity is standing in the way most of the time. I just want a
| simple board for a simple project with simple issues/user
| stories/whatevers and update their state which gets reflected on
| the board. For additional features i want to install/write a
| plugin and that's it. If I need a manual for software in 2022
| it's either trash or something far from mainstream (in which case
| complexity and/or lack of ux might be acceptable).
| t43562 wrote:
| It appeals to companies that think they only have to pay for one
| tool. It's awful for agile work but your boss sees the "agile"
| tickbox and says "fine"
| linsomniac wrote:
| One real benefit of Jira is that almost everything else out there
| has an importer for Jira. We chose to move from FogBugz to Jira
| ~3 years ago, in part because we knew if it didn't end up working
| for us, it would be relatively easy to move to another platform.
|
| Many of the competitors don't fully understand this. They offer
| importers for Jira, but not an *exporter to* Jira. It's a pretty
| hard sell to even consider something else if I know I'm going to
| be stuck there. I wrote the tools for FogBugz to Jira migration
| and it took a stupid amount of time to do.
|
| FYI: FogBugz provided a Jira exporter but it was abandoned (much
| like FogBugz as a whole), and was totally unusable for the
| migration.
| chillingeffect wrote:
| I also hate:
|
| The gray text. Cmon, we have a roomful of ppl and 1 monitor.
|
| Subtasks fuck up the whole layout. And appear _above_ everything.
|
| Suggestions that only include the 1st N values from a list. You
| have to know what youre searching for.
|
| Can't preview fakeSprint until it's started.
|
| No easily-available view of each developer's workload.
| monkeybutton wrote:
| All the confluence hate speaks to my soul. It's where ideas go to
| die. If you want to start a successful internal project and
| someone tells you to start documenting your ideas there, you
| might as well just move on to something else. Whatever you were
| going to do is already dead. It's just so ignorable. Nobody gives
| a shit about a confluence doc. Write up your thoughts and send it
| as an email to your boss, your peers, whoever. That demands a
| response and you'll get one, for good or ill! Getting outright
| rejected is still better than the sad withering away that is
| putting it into confluence. Anyways, what's the most common
| signal that people hate confluence? When they use it as a link
| repository to docs stored elsewhere.
| Sebguer wrote:
| The real problem with Jira is that every company adopts it
| without sufficient support. It needs dedicated admins. You can't
| just let every single team YOLO things.
|
| Unfortunately, what happens is a company adopts it from the
| start, and then it grows into an impossible-to-use forest where
| there's no meaningful way to bring things back to actually
| usable, and everyone is miserable.
| thomaslord wrote:
| Even with zero customization, just using it for a Kanban board
| is incredibly slow and frustrating. My 2-person team was using
| the free version of Target Process and needed to migrate to
| something else since we hit the entity limit, so we went with
| Jira because it seemed like the industry standard. What we got
| was the slowest initial page load and slowest interactions of
| any webapp I've ever used.
|
| After struggling along for 2-3 months, we moved over to
| Clubhouse (now called Shortcut) and the difference in speed and
| overall experience is night and day.
| sanderjd wrote:
| I honestly can't imagine trying to hire someone for such a
| terrible job.
| jokethrowaway wrote:
| If a tool needs this level of support it's not a good tool and
| not even a tool - it's the no-code equivalent of a framework.
|
| I'd rather pick any other ticketing system which has things
| done in one way than waste my life configuring jira
| Pasorrijer wrote:
| Just about every enterprise tool requires a proper
| implementation and system admins and business process
| analysis and change management to get setup.
|
| A lot of enterprise tools are "crap, why would the company
| ever use this", and 90% of that is in the implementation (or
| lack thereof)
| Sebguer wrote:
| Yep! It also comes down to a difference between the people
| the tool is primarily targeted at, and who actually has to
| interact with it. Salesforce's CRM (and its various sub-
| products) is very similar.
| Sebguer wrote:
| This is an inane take. Almost every system we use in a
| business requires support, and management to be used
| effectively. You wouldn't fire the people responsible for
| maintaining your other services.
|
| You can either have something incredibly powerful, like Jira,
| with a lot of sharp edges, or you can use something
| incredibly similar. The latter would be more like 'no-code'
| since it's going to be drastically limited in terms of
| adapting to how your business does work, versus Jira which
| can be transformed into just about anything.
|
| That 'just about anything' is the root of the problem, since
| over years a business will let dozens of people alter
| configurations and do special little bespoke things on their
| projects until it's unsustainable.
| AnimalMuppet wrote:
| > You can either have something incredibly powerful, like
| Jira, with a lot of sharp edges...
|
| It's powerful. But I think a bunch of the dislike is
| because the edges are _not_ sharp. They 're very dull.
| That's why it's so clumsy to use. (Sure, it's still easy to
| cause damage, but that's not the same thing...)
|
| Disclaimer: I have never actually had to use Jira. This is
| just my impression from listening to others complain.
| Sebguer wrote:
| The point of something being sharp is doing damage with
| minimal effort, which I think fits here! Though, I won't
| disagree that a lot of parts of the Jira UX are more
| blunt-force.
| zippergz wrote:
| Dedicated admins make it even worse, because they have the
| bandwidth and inclination to do all kinds of crazy
| customization, which is what takes jira from merely bad to
| terrible. The worst jira instances I've ever seen are the ones
| that had full-time people customizing them.
| Sebguer wrote:
| You've clearly not worked in places where it's people part-
| time customizing them, because I guarantee the outcome is
| worse!
| WorldMaker wrote:
| You are both right! What you really want is a place that
| doesn't customize Jira _at all_ , and if you find such a
| place you'll find out that they eventually switched to
| something else because everyone also hates Jira's default
| out of the box behaviors.
| outworlder wrote:
| I don't know, because the part-time customizers are
| scratching some itch. Maybe they are messing up because
| they don't know any better.
|
| The full time customizers need to justify their salary.
| more_corn wrote:
| The worst thing about jira is it leaves the door open for
| confluence which is the actual worst thing.
| kerblang wrote:
| In my experience, Jira is the dog that begins to resemble its
| owner. If you are working in a toxic, dysfunctional organization,
| Jira will reflect that:
|
| - Giant forms with dozens upon dozens of nonsensical fields
| (preferably with abbreviations as names, like "IFE App.") half of
| which are required so you just stuff random words in them to make
| it shut up
|
| - Thousands of tickets that would probably take 30+ software devs
| 100+ years to implement
|
| - Can't find your project because your project's name is nonsense
| (also preferably with abbreviations)
|
| - Task descriptions have hundreds of words of nonsensical
| boilerplate but don't actually say anything at all
|
| - 50 different ways each to say "Finished", "Started" or
| "Abandoned"
|
| - Workflow state transitions reminiscient of the outdoor maze in
| The Shining (crazy man with axe optional)
| alephxyz wrote:
| One I found particularly annoying was having too many
| hierarchical levels for taks. Something like : Client,
| Contract, Deliverable, Product, Release, Change Request,
| Requirement, Task, Sub-tasks
| audunw wrote:
| > - Thousands of tickets that would probably take 30+ software
| devs 100+ years to implement
|
| I feel like the company I'm working for has a reasonable
| attitude towards Jira, and they recently just batch closed all
| tickets that were older than some date in many projects. So
| you'd have to actively re-open tickets you had created to keep
| them alive, if needed. Great decision IMO.
|
| It's an interesting exercise to be forced to deal with old
| tickets you've created. It gets you thinking.. "well, this
| thing should probably be done at some point, but then if it's
| actually important we'll probably think of it again and can re-
| create the ticket then". Might give you experience that
| encourages you to be careful when creating new tickets too.
| EnderWT wrote:
| We've automated this in our propriety system. After an amount
| of time with no activity, change requests expire and someone
| can resubmit if they're still valid, otherwise they close
| after a number of days. They also get a notification in
| advance in case they want to investigate validity before
| expiration. Has worked well for us since our software is
| decades old and the number of change requests are
| substantial.
| dboreham wrote:
| I've probably said this before here but I just don't see what was
| wrong with Bugzilla. We spent years getting it honed to suit a
| good bug lifecycle model. Everything since has been fubar one way
| or another.
| kstrauser wrote:
| I don't hate Jira. I strongly dislike working with people who
| love it. From https://honeypot.net/post/jira-is-a-code-smell/ :
|
| > A useful task manager will be somewhat opinionated. It will
| almost, but not quite, do what everyone wants, and will annoy
| everyone equally with the few things they think it does wrong. A
| tar pit of a task manager will claim to be everything to everyone
| after customization, meaning that a few people will think it's
| heavenly and everyone else will despise it with the heat of a
| thousand suns.
| stevebmark wrote:
| Tehchops wrote:
| Jira is bad, but the worst part about it is that it makes it non-
| trivially more likely you'll also be using Confluence, which is
| an absolute blight upon the software landscape.
| apocalyptic0n3 wrote:
| Jira isn't perfect, but it fit our agency's needs well enough and
| the short comings haven't been bad enough to cause us to rethink
| it.
|
| The truth is that there's very few project management tools out
| there that offer the flexibility to run individual projects the
| way an individual team wants to. When you're an agency with
| hundreds of projects in the system, that's invaluable. I
| researched 2-3 dozen competitors to find a better solution and
| there just wasn't. Other than maybe Redmine and its derivatives,
| which the team basically dismissed for being too outdated.
|
| ETA: I should clarify that I'm using Jira Cloud and we don't have
| many issues with speed (at least today, anyway. Maybe in a few
| years, who knows)
| blowski wrote:
| OK, so what don't I like about Jira?
|
| 1. It's extremely slow.
|
| 2. It's difficult to predict the effect of making any kind of
| change.
|
| 3. The permissions system is so convoluted, I can be the admin of
| a board, and yet not have permission to see a ticket on it.
|
| 4. It relegates the conversation to a second-class UI element,
| when this is the most important part of any project management
| system.
|
| 5. Trying to operate on a bunch of tickets all at the same time
| (e.g. move all tickets in this status into some other status)
| requires a lot of time.
|
| 6. Every Jira setup is so different, trying to compare a piece of
| work from one area of the organisation to a similar piece of work
| elsewhere is useless.
|
| 7. The UI is extremely buggy. I can add a mandatory field to a
| ticket, then when I try to use a shortcut to create a new ticket,
| it won't work because I can't fill out that mandatory field.
|
| 8. There are random side-effects when one person does something
| on one bit of the system, and VOILA everybody's workflow is
| broken, with no obvious warning that would happen.
| rsanek wrote:
| > Trying to operate on a bunch of tickets all at the same time
| (e.g. move all tickets in this status into some other status)
| requires a lot of time.
|
| Have you used the bulk issue change tool? The UI isn't
| necessarily very user-friendly but I would not label it as
| requiring a lot of time, I actually feel it works quite well
| for this use case.
| slaymaker1907 wrote:
| In defense of complex permissions, this often ends up being
| necessary to avoid single points of failure. For example, if
| someone can turn off the setting preventing force push to the
| master/main branch, that person should not be able to commit
| code thereby requiring more than one person for a commit to be
| force pushed in practice. Even better would be to require a
| config change like that to be approved by more than one person,
| but that can be difficult to implement compared to adding in
| narrow permissions. Even if you just prevent force pushing in
| general, another common bypass would be disabling CI for
| certain commits (such as in cases where the CI infrastructure
| is down and the commit is necessary to fix some ongoing
| incident). Yes trusting developers is always going to be
| necessary to some degree, but that doesn't mean absolute trust
| is required all the time.
|
| For your specific example of not being able to see tickets as
| admin, I imagine that feature was added for teams where
| sensitive information is stored in the ticketing system for
| things like user reported issues. User reported issues often
| has PII or other personal data and while developers need to see
| that information, admins often don't. When I worked at a bank,
| any remotely sensitive columns in the database were either
| inaccessible to developers by configuration or by encrypting
| them to and from client code when the DB didn't support column
| level permissions (while Sybase could manage column level
| permissions, Mongo and Elasticsearch didn't at the time).
| blowski wrote:
| That's the thing about Jira.
|
| I don't understand why I can't see a ticket on my board
| because some team in another company once requested a
| seemingly unrelated feature. It's trying to be too many
| things to too many companies all at the same time, and thus
| ends up as an unusable mess of complex settings.
| bamboozled wrote:
| Awesome list and objective.
|
| I'd like to add another point:
|
| #. There are too many "views" or ways of visualizing the work
| that needs to be done, ie the plan view and the kanban view, my
| issues etc.
|
| If I'm not looking at the 'right' view I'll miss something and
| maybe get in trouble from project management.
| meibo wrote:
| 9. The text editor is still busted and I just don't understand
| why. It's one of the most important parts of the UX, please
| please fix it. Writing any kind of nicely formatted long form
| posts is a lost cause.
| macintux wrote:
| At the very least, use the _same markup language_ for both
| Confluence and Jira.
| yamadapc wrote:
| Jira/Confluence Cloud use the same markup and editor.
| eikenberry wrote:
| But neither supports a markup language AFAIK. They used
| to support Markdown but they dropped that long ago and
| never replaced it. Now the only choice is their garbage
| WYSIWYG editor.
| jedberg wrote:
| Amusingly, it used to be great! When I first started using
| JIRA, it was just markdown. Then they introduced their
| WYSIWYG editor, but at least they still had the button to see
| the raw markdown and you could still edit the raw markdown
| (but the GUI made terrible markdown so if you wanted to use
| markdown you better start with that and never touch the GUI).
|
| And then I guess at some point they just removed the markdown
| part?
| geysersam wrote:
| It boggles the mind. Who made that call? What were their
| reasons?
| pm90 wrote:
| This is my biggest gripe.
|
| I make an effort to write detailed comments about what I did,
| what I discovered etc. This is really helpful to reproduce
| the issues, and a few months down the line it helps to
| clarify exactly what happened.
|
| JIRA text editor is FUCKED. Try adding bullet points after a
| code insertion. Does not work. I have to first create all the
| bullets, then step through them and write out whats on my
| mind. For more complex stuff, I just write in my code editor.
| How can you fuck up the most basic functionality?!
| ericbarrett wrote:
| My gripe for the text editor--if you navigate away from the
| page, by an accidental click or keypress, all your text is
| lost. This kind of thing was solved 15 years ago; it's table
| stakes!
| shrikant wrote:
| My favourite gripe about text editing in Jira is that the
| ticket body and ticket comments require subtly different
| formatting mark-up, and the wysiwyg widgets for formatting
| are also ever-so-slightly different.
|
| This results in a fun game of me trying out single
| backticks, triple backticks, braces, double braces, other
| miscellaneous punctuation symbols, and various indents
| before giving up and trying the formatting toolbar, only to
| waste another couple of minutes clicking around to see what
| works.
|
| Somehow I can never remember what worked either, so I find
| myself repeating this ridiculous dance on at least a weekly
| basis.
|
| Although IIRC, there was a recent update that at least
| harmonised the code formatting syntax between editors,
| although I can't remember if it actually worked....
| fmakunbound wrote:
| Definitely this 100% I proposed for company game night:
| Predict where the Jira cursor goes next in response to right
| arrow. There's so many possibilities: right left up down,
| teleports, disappears. My favorite is when the cursor splits
| into two at two different seemingly unrelated locations. Two
| cursors?? How do you even do that in a text area?
| devoutsalsa wrote:
| I still can't figure out how to search it
| exyi wrote:
| I just wrote the search query to our PM, since I was unable
| to find anything myself... I don't understand why just
| couldn't use, IDK, a shared spreadsheet, even that would be
| more productive (from my perspective)
| cuteboy19 wrote:
| Find the person in your organization who knows JIRA. After he
| doesn't manage to find it, open outlook and search for it in
| the notifications@jira folder, where you would most likely
| find it
| sophacles wrote:
| This is a solved problem. The most efficient way to search
| Jira is to type random characters into the search bar until
| you find the ticket you were looking for on page 3 of the
| results.
| brailsafe wrote:
| I'm fine with Jira now. As long as I don't have to use it that
| much. I agree about conversation being a second class citizen. I
| wish I could get integration with my mac notification system more
| easily. But the positive is that I can do a screen recording and
| drag and drop that video straight into a comment which is cool
| hansoolo wrote:
| I don't really get the hate to be honest. Maybe it's just me, but
| our DevOps team seems to have squeezed the best out of Jira. They
| organized the workflow very well, the Bitbucket Integration is
| seemless and I can easily get to the builds of my current issue
| and see what happens there. The only gripe I have about Atlassian
| suite is confluence. It's a mess.
|
| I think it really depends on how Jira and the overall workflow is
| taken care of. For our part, it has been a pretty good experience
| and the DevOps team used the APIs pretty well and wrote their own
| tools.
|
| To be honest, I don't have used many other tools, but it seems
| like our company has made a good choice in configuring the whole
| system "just right".
| hkgjjgjfjfjfjf wrote:
| tdgs wrote:
| Wait until you use notion. I've been forced to use it for the
| last year, and I miss jira. I never thought I'd say this, but I
| really do miss it.
| bitwize wrote:
| Just be glad you don't have to use VersionOne.
|
| Anyone who's coped with VersionOne will nope back to Jira in a
| hot second.
| SilverBirch wrote:
| Shout out to the programme manager at my old company. His
| attitude was "Use jira in the way that works for you". He could
| set up and modify workflows for me, he had good useful advice,
| and in total I probably spent 20 minutes a week dealing with
| jira. Which as a manager of a decent sized team I think is fairly
| good. As one of the comments on that site said "I'd rather use
| trello" I disagree, it was much better for having multiple views
| on things and by standardising across the company it was much
| easier to just get an informal view on what other teams were
| doing.
|
| Most of the problems with jira are the people using it.
| newobj wrote:
| So say we all
| Tade0 wrote:
| My Jira experience improved a lot when I wrote a tool that parses
| and serves the content of HTTP Archive files - not having to wait
| for all those panels, menus etc. was a huge boon, even if this
| view was necessarily read-only.
|
| Also I'm pretty sure Jira saved my friend's marriage because he
| used the free version to coordinate finishing up their house.
|
| Lastly while JQL has limited capabilities, it's better than
| having a bunch of API endpoints.
|
| That being said it still baffles me how badly some UI elements
| are done there. Especially the menus would benefit greatly from
| some caching or preloading.
| amelius wrote:
| Ripe for disruption.
| kringo wrote:
| JIRA is the definition of building everything for everybody and
| let them customize it, it's got complex and to a point highly
| productive engineers don't want it anymore, it's a OVERKILL!
| mberning wrote:
| These people are pampered brats. Try being forced to document all
| your time and projects in Rally or Version1. You will beg to get
| Jira back. Software "engineers" are such divas. "I don't play
| other people's song." As if they are some kind of celebrity.
| vjust wrote:
| Its like you can't be fired for buying Microsoft (as an IT
| purchase decision). You can't be fired for buying JIRA. JIRA
| makes everything, the most broken or dodgy processes look
| respectable. It keeps Managers and scrum masters busy. They have
| a toy to play with, and why not?, why should only devs have toys.
| I'm not saying I hate JIRA, or that it doesn't work. Its just
| that sometimes the tail wags the dog.
| sto_hristo wrote:
| I've seen absolutely ridiculous workflows on Jira. Things like -
| "i'm gonna make the most ridiculous workflow out of spite and
| boredom just to troll you."
|
| From that perspective it's easy to hate it, but you hate the
| actual use of the tool not the tool itself.
|
| Currently i enjoy more sane use of it. Simple workflow. You get
| in, read the ticket, clicky a button, get out. Slowness in that
| regard is very tolerable.
| easytiger wrote:
| Wait till you hear about servicenow
| Maakuth wrote:
| Single letter hotkeys are pretty bad. If it's not an input field
| you've focused but the page itself, you might assign the ticket
| to yourself and set it to some crazy state before you realize the
| focus is all wrong. Ask me how I know...
| iso1631 wrote:
| I do believe I managed to disable those in preferences or
| similar
| AtNightWeCode wrote:
| Not going to read this rant because of time. But let me guess.
| Jira is a giant time waster. My main problem with Jira though is
| that it takes a lot of effort to configure it in good way. Jira
| is a piece of software that comes with plain horrible defaults.
| [deleted]
| phendrenad2 wrote:
| Not using Jira is a red flag for me, and I won't work for any
| company that doesn't use Jira. The reason is, Jira is so standard
| at this point, if a team uses a non-Jira product, they must have
| an overly powerful CTO or team lead who rules with an iron fist.
| Sure, it sucks, but working under such conditions is worse.
| cptcobalt wrote:
| I came from Apple (and their excellent Radar issue tracking tool)
| to a company that uses Jira.
|
| Jira is the _worst_. I routinely lose data in jira, like saving
| errors. Dragging and dropping attachments sometimes causes the
| page to crash and reload. Everything in the UI moves around or
| obscured behind some tabs. I want to be able to file a network of
| issues all at once, something Radar did great. Jira workflows are
| much to complicated, and their flexibility just increases your
| administrative hell. I can go on and on.
| NonNefarious wrote:
| Also ex-Apple here. Radar does suffer (to a lesser extent than
| Jira) from a profound defect, though: Searches are "exact
| match" for whatever text you put in the title. To find a bug
| YOU filed, you have to remember the exact words and sequence
| you used in the title. Did I say "resize window" or "resize a
| window?"
|
| I filed a bug against Radar for this behavior, and developers
| from other teams added comments expressing surprise that the
| tool was crippled in this manner. I think a year later, someone
| said, "Yep, our team got bit by this today again. We assumed
| this was fixed years ago."
|
| This fundamental flaw may explain why some widely-encountered
| bugs in Apple products don't get fixed, or at least fixed in a
| timely manner. A dozen Radars could be filed for the same
| defect, but if they aren't phrased the same way you'll never
| find all the dupes. So dumb.
|
| Still... I could construct queries based on status and product
| more easily in Radar than in Jira.
| phist_mcgee wrote:
| Well it's obvious then. Apple needs to create a new and
| bespoke issue tracker just for radar.
| hancholo wrote:
| Thankfully my company built its own internal tool similar to
| Jira. Unfortunately this is not the case for other companies or
| smaller companies since it can be cost-prohibitive.
| zaphar wrote:
| Jira's web interface I can live with. I've internalized the
| workaround for the UI bugs and I've learned to live with the
| slowness. Sure it reflects all the worst aspects of your
| organizations structure and process but that's not really it's
| fault.
|
| What _is_ it 's fault is their REST API. In theory it's a well
| architected API. Follows REST principles. You can tell they read
| the whitepaper. But you have to jump through a _ton_ of hoops to
| get any data beyond surface details.
|
| Example: Want to find what epic a User Story is part of? It's a
| custom field. Which one? depends on how your instance has evolved
| over time. You'll have to scan through all the fields to find the
| field id.
|
| This is what happens when an API isn't designed to fulfill a
| particular need but instead is meant to be infinitely
| customizable. Ergonomic APIs are impossible.
| irusensei wrote:
| Good. I'd also like one of these but with Citrix.
| meowface wrote:
| I'm sometimes kind of surprised at how often I see people say
| they don't mind it. It's by far the tool I like the least out of
| everything I've used at any job I've ever been in.
| wyldfire wrote:
| I only use Jira for defect tracking and not project planning.
| In that regard it seems to be only slightly worse than
| Github/Gitlab's issue tracking. It'd be kinda nice if it
| supported Markdown but it's not a big deal.
|
| The only things I need it to do are: (1) record an archive of
| comments describing the progress on the issue's resolution, (2)
| be able to store attachments, (3) be able to cross-reference
| other issues. Maybe I have a really low bar? But it seems to do
| those without much problem and in my case it doesn't seem to be
| slow.
| tormeh wrote:
| There's lots of worse shit here:
| https://en.wikipedia.org/wiki/List_of_version-
| control_softwa.... I remember IBM ClearCase in particular as
| vile.
| jrib wrote:
| What tools do you like the most?
| bpodgursky wrote:
| The UX is annoying as hell but I am almost never unable to do
| what I need to do. I can't say that for all SaaS tools.
| pydry wrote:
| It's quite easy to have a minimized exposure to jira as a
| developer. I hate its guts but if my interactions are limited
| to writing a few tickets and changing statuses then its
| awfulness is more somebody else's problem and it doesnt bother
| me nearly as much.
| happytoexplain wrote:
| If it's set up properly, it's easy for developers to browse the
| tickets, log work on them, and update their status - and that's
| all they will need to do. So, from their perspective, it's
| fine. However, getting to that point is unnecessarily
| difficult, and if you fail, that difficulty spills over into
| the developer experience.
| hinkley wrote:
| I would fight you about how Bamboo is the worst tool I've had
| to use, but since they're both from Atlassian that feels a bit
| like splitting hairs.
| 2OEH8eoCRo0 wrote:
| It's a tool for the boring part of software engineering- I
| don't expect it to spark joy. I wish it were faster, scaled the
| full width of my monitor, allowed external editors, etc.
| Overall it gets the job done well. Everything else that I've
| used is horrible which makes it the best in my experience but
| that's still not saying much.
| tommoor wrote:
| But what if it _did_ spark joy... https://linear.app/readme
| camer0 wrote:
| We use Linear at my job too - it's very smooth and easy to
| use and certainly does spark joy
| jbluepolarbear wrote:
| I use linear and I hate it more than jira. It's jira with
| all the useful production features removed, making it
| useless for large teams and qa teams. Beyond simple task
| tracking it has been a chore to use.
| 2OEH8eoCRo0 wrote:
| This looks really nice but it scares me to think of what my
| large (60,000+ employees) employer would do to it. Thanks
| for sharing though- I'm going to check this out.
| conradfr wrote:
| We use it at my current work and I'm not impressed. We even
| moved back some workflow steps to Notion because of lost
| work in the editor.
|
| Frankly, I miss the limited GitHub PM tools we used at my
| previous job.
|
| Even their one true limitation, no sub-issues, is very meh
| on Linear.
| kzrdude wrote:
| I don't mind it. Maybe because I only peek into it about once
| per week or so, so we don't really drive daily work using it.
| codebolt wrote:
| Same, I check into Jira once per day, max. It's useful to
| give an overview of what everyone is working on in the
| "Kanban" meetings twice weekly. I use quotes because we
| really don't follow any strict rules or structures, everyone
| just kind of does what needs to be done to keep things moving
| forward.
| hinkley wrote:
| Maybe a couple times a day for me, but mostly if I somehow
| have two things going at once.
|
| Meanwhile I'm battling Bamboo regularly, and I hate
| everyone who has ever worked on that crime against
| humanity.
| Tao3300 wrote:
| I don't love it, but I sure hate it less than just about
| everything that came before it.
| RadixDLT wrote:
| if you hate jira try Trello, "the baby version of jira"
| felixgallo wrote:
| Jira is the worst possible choice, except for all the others.
| labster wrote:
| I was honestly really pleased when we moved to Jira at a
| previous job, having lived through three other worse ticket
| systems. It's just more powerful, and has ways of keeping
| tickets from falling into a black hole. None of that is an
| excuse for the slow, terrible frontend for Jira, or the
| complete lack of discoverability in Confluence.
| bko wrote:
| Has anyone tried to use something like notion? Depending on
| your size you don't necessarily need all the stuff around it.
| Whats the difference between a story and an epoch? Most people
| don't really care. They just need something to track stuff
| being done, like a glorified to-do list with rich text.
| jitl wrote:
| Disclaimer: I work at Notion.
|
| I think Notion works well for tasks if your organization is
| small, or you are happy with lightweight process. There is no
| way to ensure all updates to a Notion page follow a strict
| state machine like Jira. Notion just doesn't have those kind
| of validation / restriction tools yet.
|
| For our 100ish engineers it works well especially because
| planning docs flow seamlessly into project specs and then
| tasks... but we suffer a bit from loosely defined workflows
| around 2-week sprints that take more clicking than anyone
| wants.
| djur wrote:
| Shouldn't these tools be used primarily at the team level?
| Large organizations don't necessarily have larger teams.
| I'm not sure why it should make a big difference if you
| have 2 or 200 teams of 5 using the tool.
| TLadd wrote:
| Yep. Jira is far from perfect, but I've not had any better luck
| with anything else.
| cowmix wrote:
| g_delgado14 wrote:
| Have you tried Linear [0]?
|
| ----
|
| [0] - https://linear.app/
| originalvichy wrote:
| I read some of those rants and almost 50% of them were not rants
| but people ignorant of features and how they work getting angry.
| I'm not saying they deserve to be angry, but if a passionate rant
| can be dismissed by a "you're holding it wrong" it isn't really a
| rant.
|
| There are tons of real issues like ages old bugs or weird design
| decisions years ago that make something that feels very sane feel
| impossible to deliver.
|
| All in all my point is that most of these rants are against
| knowledge of features/design and misuse by colleagues.
| anonytrary wrote:
| Jira was supposed to help us do the work, not become the work.
|
| We have at least three people employed who's sole responsibility
| is to pester people about ticket status, apply bulk changes in
| Jira, define conventions, and ultimately make life harder for
| individual teams who wanna follow their own processes. As an EM,
| my higher-ups would rather have me ensuring ticket status is
| perfect to the T instead of pairing with and assisting my
| engineers.
|
| I kid you not, we have directors of engineering who spend half
| their working day making bump/nudge comments on tickets.
| airfishey wrote:
| I'm curious what other people's thoughts are when comparing CA
| Agile Central (formerly known as Rally) to Jira. Which do you
| like more and why?
| 7357 wrote:
| I fucking hate software.
| wly_cdgr wrote:
| I think Jira development is secretly supported by Microsoft to
| make sure there's always at least one enterprise software product
| that developers hate more than Windows
| avignome wrote:
| I hate BitBucket more!
| pyrolistical wrote:
| Jira is practically called out in the phoenix project. Their
| solution?
|
| 1. Don't use it
|
| 2. Do a manual process
|
| 3. Get buy in and deliver actual value
|
| 4. Run into scalability issues
|
| 5. Now automate which could be Jira but now you know what value
| your process is achieving
|
| 6. Don't let Jira be the end in itself. Focus on the value of the
| process and tune that
|
| https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
| simonbarker87 wrote:
| I've used it at three companies and thought it was fine. Maybe my
| tastes aren't refined enough or something but I thought it was
| fine.
|
| Confluence is terrible but that's a different product.
| BitwiseFool wrote:
| For me, the worst part is how the search feature naturally
| defaults to searching over the entire organization and there is
| no setting to preserve space preference. I'm sure a product
| manager or sales person pitched this as a wonderful thing, but
| in a massive organization I really only want to search within a
| small number of spaces, over and over again. I rarely, if ever,
| want to access the _entire_ company 's confluence but that's
| what the search bar does.
| Minor49er wrote:
| The problems with Jira can be extended to the rest of Atlassian
| and all of their offerings. Their company culture is very much
| one of "we're right, no matter how many people bring up the same
| issues." Things like:
|
| - Shoving political messaging into git terminal messages -
| Renaming "blame" to something else without notifying the userbase
| ("annotate"? It's been a while) because, despite "blame" being a
| git term, its usage hurt someone's feelings (yes, seriously, even
| though no proof or elaboration has ever been provided) - Not
| fixing a bug for 6+ years where, if someone's typing a comment
| and accidentally hit the escape key, the entire post gets deleted
| with no option to recover it (I'm not sure if this ever actually
| was resolved)
|
| That said, for a while, Jira had a lot of good things going for
| it. But by now, enough competitors have popped up with similar
| offerings that are easier to use without all of the unnecessary
| self-importance buried within it.
|
| For a Jira alternative specifically, I've been using Linear.app
| for the last 8 months and enjoying it overall
| eterm wrote:
| Annotate was the SVN term, have you considered it might just
| pre-date git?
| Minor49er wrote:
| That's interesting. This change certainly came post-SVN. I
| don't recall that ever being used as an explanation, though.
| Still, quite a silly thing to do based on the presumption
| that a benign word hurt a hypothetical person's feelings
| avh02 wrote:
| I tried giving atlassian some feedback recently when they asked
| for it (via email). Unfortunately the very end of their survey
| had some fancy widget to upload a recording (which was absolutely
| unnecessary). The widget didn't load, and because of that the
| form didn't allow a submission - so I didn't bother figuring out
| how to give them my feedback, even after i had done a 3 page
| survey.
|
| I hope it was a widespread issue.
| sefrost wrote:
| I wish the comments were more specific about which features they
| don't like.
|
| For me a particularly frustrating aspect is the way the UI moves
| around a lot. I'm quite anxious to click anything until all the
| loading spinners have stopped in case I click the wrong thing.
| Then I could be taken to a page or feature I've never seen
| before.
|
| Also it's really annoying when I try to copy something from a
| ticket description but it starts editing the whole description
| field.
|
| EDIT - I'd also like to add that as a developer, once I finish my
| ticket I assign it to a QA. Then I can never get back to the
| ticket. I'd like a really easy way to see all of the tickets I've
| ever completed. But completed tickets aren't assigned to me,
| they're assigned to QA.
| bryanrasmussen wrote:
| Jira has JQL (Jira Query Language)
| https://www.atlassian.com/blog/jira-software/jql-the-most-fl...
| you can search for a lot of different things, it is possible to
| construct queries for items you have touched in the past.
|
| on edit: once you have a query you like save it as a personal
| filter and it will show up somewhere in the UI, because Jira
| sucks who knows where (changes all the time), but you can of
| course also make personalized dashboards and place the filters
| you have made on to that dashboard with a widget that runs the
| filter.
|
| on second edit: evidently I earned someone's downvote by not
| being adequately anti-jira despite having put in that Jira
| sucks, but really the comment to which I'm replying ends with:
|
| " I'd also like to add that as a developer, once I finish my
| ticket I assign it to a QA. Then I can never get back to the
| ticket. I'd like a really easy way to see all of the tickets
| I've ever completed. But completed tickets aren't assigned to
| me, they're assigned to QA. "
|
| which, using JQL, is real easy.
| outworlder wrote:
| > I wish the comments were more specific about which features
| they don't like.
|
| I have a very specific complaint: the ease which all sorts of
| custom fields can be added for _everyone_. Sales will want to
| add a field to hold their contract status. Lo and behold,
| engineering now has it. It can be done in the proper way, but
| it seems that doing it at a global level is easier since that's
| how multiple Jira installations at multiple companies were
| configured.
|
| All I want is a ticket, with a title, description, assignee,
| the current status, an easy way to transition, and comments.
| That's it. Let my project _opt out_ of any global customization
| if making global stuff is unavoidable.
|
| Also, the newest Jira UX is... terrible. Tickets should not be
| THAT easy to edit. How often do we want to change a ticket's
| description, or title? I'd say, not often. If we do, there's
| really no harm in having an "edit" button. Old Jira versions
| had one.
| rozap wrote:
| Every time I'm highlighting and ctrl+c'ing something out of a
| ticket and it turns into edit mode, I tense up a little bit.
| Ugh.
| Buttons840 wrote:
| I had a similar thought: Jira is very customizable; if people
| hate something that is so customizable then part of what
| they're hating is the organizations customization of it.
|
| I've seen the same thing at multiple companies. Someone comes
| up with a Jira workflow, it doesn't match the needs of some
| people, but the company wants to standardize on that
| workflow, so now people are stuck using a stupid workflow
| that doesn't work for them. I've also seen a bunch of stupid
| custom fields on every single ticket. Is this Jira's fault or
| the organization's fault? You complain but the word from your
| immediate manager is that the team is already in hot water so
| escalating complaints about the Jira configuration isn't
| going to help, etc.
| lmm wrote:
| If only one organisation did that, it would be that
| organisation's fault. When every organisation using Jira
| does that, it's Jira's fault.
|
| Why does everyone standardize on a company-wide workflow
| that the developers can't change with a bunch of stupid
| mandatory fields? Because that's what Jira nudges you to
| do. Workflow editing is for managers only, fields are
| mandatory by default...
| lp0_on_fire wrote:
| > Tickets should not be THAT easy to edit. How often do we
| want to change a ticket's description, or title? I'd say, not
| often. If we do, there's really no harm in having an "edit"
| button.
|
| It's very useful for when the user submits a ticket with "My
| computer isn't working" as the title and "excel is broken" as
| the description.
| exyi wrote:
| I'd not mind to press edit to change it.
| cogman10 wrote:
| What I hate about jira is it's flexibility.
|
| The biggest issue I have with jira is it's so dead simple for
| braindead process zombies to cram another field, another label,
| another required text box, 4 new transition states, 20
| difference confusing priorities, etc. Then, require everyone to
| follow through with this (with 90% of the time putting some
| form of "not applicable" in the boxes they added).
|
| It is built for anal retentive "rule enforcers" to jump in and
| chastise you because you checked box 4a but didn't fill out sub
| box 3c.
|
| FFS, I have an easier time filling out my taxes than some
| project's jira setups. (And I live in the US).
| midasuni wrote:
| Isn't there problem the people cramming those things in?
|
| We use jira as a way to track ongoing tasks, we use subject,
| description, comments/attachments, and assigned to.
| cogman10 wrote:
| > Isn't there problem the people cramming those things in?
|
| Yes.
|
| However, the feedback loop for "that's a dumb mistake" both
| takes too long and is easily ignored.
|
| Even with CRs, spaghetti code still gets written. There's
| no CR for a Jira workflow change. Further, the people
| making such changes are frequently unimpacted by them (or
| they like them because they are the aforementioned anal
| retentive process zombies)
| pydry wrote:
| It's such a bloated mess that it's hard to point to a specific
| thing.
| Lammy wrote:
| The composer in general. I often have to intersperse log/code
| lines with prose, and there's no telling what the Formatting
| menu will do. Some times selecting a formatting will apply to
| selected text, sometimes not. Sometimes it will apply when
| choosing a formatting then pasting text, some times not. Some
| times it seems to apply to a selection as well as everything
| after it. It does support Markdown with backticks for
| monospace, but that's a lot of manual editing I would rather
| not do.
|
| I also get annoyed at the subtle ways the top-level Issue
| composer is different from the comment composer, most
| frequently with the top-level composer's refusal to allow image
| embedding/positioning. You can only add images to a new Issue
| as file attachments displayed as a row of tiny thumbnails under
| all the Issue text, so I will frequently create a mostly blank
| Issue and then write what I want to say as the first comment
| where I can embed images and talk about them inline.
|
| In the interest of also saying something nice, I think it's
| cute how the JIRA logo seems to be a Jera/"j" rune :)
|
| https://wac-cdn.atlassian.com/dam/jcr:e348b562-4152-4cdc-8a5...
|
| https://en.wikipedia.org/wiki/J%C4%93ran
| nikanj wrote:
| It's like trying to describe why a McDonalds $1.99 burger is
| bad, to someone who just lists ingredients and insists it has
| just the same mayo, cheese & patty as a $12.99 burger does.
|
| It's not about any single feature being missing, it's just
| terrible the same way Vista was terrible
| efortis wrote:
| How do I find an old story in Jira? *Without searching my
| email.
| daigoba66 wrote:
| > I'd like a really easy way to see all of the tickets I've
| ever completed.
|
| Can be solved by creating a custom person field called
| "Developer". Then you can customize the Status transition for
| your In Progress status to automatically set that field to the
| current user or maybe the issue assignee.
|
| For better or worse, Jira is quite powerful and flexible. But
| it's not always simple to setup.
| monkeybutton wrote:
| Everything turning into an edit action when I just want to
| click a link or copy a bit of text is super annoying! Also is
| thinking you're in a text field, typing out something and
| realizing you've done a whole bunch of random actions because
| of all the hotkeys.
| corrral wrote:
| The #1 thing I want out of every project management thingy
| I've used is the ability to have direct links to a
| ticket/issue or list of tickets/issues load as a basic HTML
| page, that's either read-only or uses a "save" button rather
| than persisting edits instantly. Provide a link to the full-
| fat version of the page, on the off chance I want that.
|
| I just want tickets to load instantly (trivial, if you're not
| loading an "app" with it), not use hundreds of MB of memory
| and tons of background processor cycles (ditto) so I feel
| like I can't just leave it open, and not to have to worry
| I'll click in the wrong place or accidentally trigger some
| hotkey thing and screw something up.
|
| Let the PMs have their version of the site with live-edited
| everything and janky (because Web) drag & drop galore and a
| whole universe of hotkeys and combos. I just want a fucking
| web page with the info I need.
| heretogetout wrote:
| I can't help but wonder what PM tools Atlassian developers use.
| Surely it can't be JIRA? Maybe they have some browser
| extensions that make the interface less frustrating.
| servercobra wrote:
| I assume they do use JIRA, hence the mess.
| JackFr wrote:
| > Also it's really annoying when I try to copy something from a
| ticket description but it starts editing the whole description
| field.
|
| +1. Absolute garbage interface.
| YetAnotherNick wrote:
| The hate is not for JIRA the tool, but JIRA the way of managing
| things.
| mnd999 wrote:
| No, the tool is shit too.
| cassianoleal wrote:
| Yes, but also Jira the tool with it's horrendous UX, janky
| markdown (which is also different from Confluence's wtf),
| memory foortprint, slow loading, slow everything, controls
| moving from under your cursor just as you're about to click
| them...
|
| Honestly, it's a horrendous piece of software however you
| look at it.
| deathanatos wrote:
| - For a while, we had tickets in done states that just roll
| over to the next epic, like they were still open. Nobody knew
| why, and it went away with nobody making any fixes to anything.
|
| - For a while, the side pane when you open an issue would just
| be blank.
|
| - Setting a ticket's epic makes me want to tear my eyeballs
| out. The button has the tiniest hitbox, the suggestion list is
| always wrong.
|
| - Bulk operations are just a PITA
|
| - the search box is always description. I'm almost always
| filtering on other criteria, and so, have to suffer a page
| load.
|
| - and every page load is long and slow. Loading my backlog page
| is 186 requests, 4.4 MiB _on the wire_ , and takes 9.4s. For
| one page.
|
| - UIs that have drag & drop, but don't support simultaneous
| scroll are annoying. I have to wait for the view to move at
| JIRA's speed, which is ofc., slow.
|
| - it encourages "sprints" and "agile", which in turn encourage
| "process" over just getting shit done.
| dfcowell wrote:
| All valid criticisms, especially the slowness and heavy page
| sizes. Another perspective on 3 of your points though (and a
| free quality-of-life tip!)
|
| > For a while, we had tickets in done states that just roll
| over to the next epic, like they were still open. Nobody knew
| why, and it went away with nobody making any fixes to
| anything.
|
| I almost guarantee someone forgot to set the resolution field
| when creating a workflow transition, noticed and went back
| and fixed it.
|
| > Bulk operations are just a PITA
|
| Agreed that the UI is jank AF, but it works reliably on the
| order of tens of thousands of tickets at a time.
|
| > UIs that have drag & drop, but don't support simultaneous
| scroll are annoying. I have to wait for the view to move at
| JIRA's speed, which is ofc., slow.
|
| Almost every operation you want to do this for can also be
| done by right-clicking and "move to." There's "move to top of
| backlog", "move to sprint x", "move to top of column", you
| can also ctrl/cmd click (or shift-click) to select multiple
| issues.
| hkgjjgjfjfjfjf wrote:
| tacostakohashi wrote:
| > I'd also like to add that as a developer, once I finish my
| ticket I assign it to a QA. Then I can never get back to the
| ticket.
|
| That's not JIRA, that's your organization's crappy
| workflow/customization. That's the problem... JIRA is a tool
| that encourages setting up elaborate yet dysfunctional
| workflows.
|
| Regarding your actual problem, just create a tickets.txt in
| your home directory and store your list of completed JIRAs and
| whatever else is important to you there.
| ortusdux wrote:
| We are looking at switching vendors, but the fact that they
| EOL'ed the server version makes JIRA a non-starter for us.
|
| https://www.atlassian.com/migration/assess/journey-to-cloud
| MetaWhirledPeas wrote:
| > For me a particularly frustrating aspect is the way the UI
| moves around a lot. I'm quite anxious to click anything until
| all the loading spinners have stopped in case I click the wrong
| thing. Then I could be taken to a page or feature I've never
| seen before.
|
| This is a common antipattern that doesn't get talked about
| enough. It's very common in the era of interactive ads,
| websites with 3rd party web UIs layered on top, lazy loading,
| and just "rich" UIs in general. A user needs to be able to
| trust what they are about to click. This is fundamental.
| macintux wrote:
| The Vera functionality in Jira likes to move me ahead in a
| test sequence, so each time I touch something in a long test
| sequence I have to make sure I'm on the right test step.
|
| Absolutely trash.
| ectopod wrote:
| This is something browsers should solve. If the thing you
| clicked on wasn't there 0.2s ago then you didn't intend to
| click on it, so just ignore the click. And add an API for
| twitch games to turn this off.
| heretogetout wrote:
| I'd probably support a page similar to the one used to warn
| you about certificate problems. "This page is using a user-
| hostile interface that may cause you to interact with
| unintended elements. Do you want to proceed?" But, you
| know, worded better.
| [deleted]
| balls187 wrote:
| Came to the comments hoping to find some solid Jira alternatives
| "the community" recommends. Sadly not the case. Instead this is
| my take-away:
|
| * Jira sucks big time, and people hate it.
|
| * There are no other tools that do what jira does, that doesn't
| also suck.
|
| * After trying Jira alternatives that suck worse, folks move away
| from the Jira sucks camp to no-longer minding using Jira.
| andreime wrote:
| You should try VersionOne :) That tool made me appreciate JIRA.
| wiremine wrote:
| Jira is bloated. Full stop.
|
| It feels like there isn't a strong unified product vision for
| Jira. It's just trying to solve everything. It's all "just
| configurable." That likely is a selling point into Enterprises
| who need some level of flexibility.
|
| But for a lot of situations, people just want something that
| works well out of the box.
|
| I often wonder what the 37signals guys would do if they ever
| decided to tackle this problem. They don't always hit the mark,
| but I give them a lot of credit for self-curating and having a
| strong product vision for what they ship.
| blowski wrote:
| > I often wonder what the 37signals guys would do if they ever
| decided to tackle this problem.
|
| Wouldn't they build Basecamp?
| awad wrote:
| Isn't that what Basecamp from 37signals is meant to be? Perhaps
| I'm missing something as I've only used it a bit.
| baal80spam wrote:
| Is there a way (setting?) to completely disable keyboard
| shortcuts (hotkeys) on Jira sites?
| etchalon wrote:
| Once a JIRA shop, we moved everything to Asana years ago, after
| trying literally everything else. Our design team just could not
| get on board with JIRA. It was too much "work", in their words,
| to track their efforts.
|
| Asana seems to be a good balance between the depth of data
| developers want to track and the high-level task management every
| other team wants.
| scotty79 wrote:
| Jira should just start configured out of the box to look and work
| like Trello.
| yamadapc wrote:
| This is the experience team-managed projects should have out of
| the box in Cloud if using kanban.
|
| You create a kanban team-managed project and it'll pretty much
| be a Trello board. If you want sprints or a backlog or reports
| you can go into the project features page and flip a switch.
| greatgib wrote:
| I used to hate Jira, and then, I had to use Asana...
| yAak wrote:
| Yeah, I've yet to use something that doesn't make me sad and
| aggravated at the same time.
|
| On my "hate" list: Jira, Asana, Zenhub &/or Github Issues,
| Trello.
| pcthrowaway wrote:
| Wow, I like Asana _much_ more than Jira. We 're using Linear
| now, which I know is a favourite here, but I actually think
| Asana is pretty close in quality (better in some ways)
| GoOnThenDoTell wrote:
| Jira need to fix their loading times
| snowstormsun wrote:
| This
| jarek83 wrote:
| Part of our company started using Click-up. If JIRA is really
| bad, Click-up is levels worse than it. I hate JIRA too, but maybe
| there is no a better thing out there?
| FpUser wrote:
| I fucking do not hate Jira. Cause I do not use it.
| geekamongus wrote:
| I like Jira because it hides the crap I don't want to do or think
| about in this thing called the backlog, which I can point to as a
| "see, it is something in the works but we don't have enough
| resources" thing, and then I can focus on the things I need/want
| to do by putting them in the Will Do Soon column.
| epalm wrote:
| Ok, it's slow, and navigation sucks, and lots of other things.
| Workflows are easy to get out of hand, but as long as you keep
| your workflows lean/tame/flexible, it's mostly "good enough". I
| suspect a sizable portion of the "Jira sucks" crowd are under the
| thumb of a maniacal administrator creating intense workflows.
|
| That said, which competitor has a visual workflow editor, to
| which I can add custom statuses/transitions, which are applied
| based on various conditions/validations? And custom screen/field
| configurations? And custom resolutions? And time tracking? And
| apply security/permission schemes across all these things?
|
| I get it, Jira sucks, I agree, but what's the go-to competitor?
| tannhaeuser wrote:
| An ad-hoc Excel sheet coded by an anal retentive management
| assistant to show em all ;)
| jrockway wrote:
| Linear is much nicer. Very quick issue entry and very nice
| looking sprint summary/status and roadmap tabs. It's everything
| I want. Most importantly, it's fast. I work with issues a lot,
| so a slow tool like jira just isn't acceptable.
|
| Jira exists to check every checkbox so you feel serious remorse
| if you pick anything else, but in terms of day-to-day
| productivity, it doesn't do too well. "Nice to look at" and
| "Fast" aren't checkbox items for managers. They're eventual
| problems for someone to solve when they notice engineers never
| touch the bug tracker.
|
| At my current org, my advice to use Linear was overruled in
| favor of jira, and I'm pretty sure I'm the only engineer that
| regularly touches jira.
|
| (I intentionally write "jira" in all lowercase because I like
| to call it JIRA, but jira's built-in text editor unconfigurably
| autocorrects "JIRA" to "Jira". That's the feature they spent
| engineering time on? Fuck them.)
| epalm wrote:
| I looked at Linear and it's very software-specific. The
| features page says it's "the new standard for modern software
| development".
|
| I do use Jira for software, but also for generic state
| tracking of non-software processes. E.g. some projects have
| no use for sprints, or code integration, or user stories.
| zmxz wrote:
| > I get it, Jira sucks, I agree, but what's the go-to
| competitor?
|
| You started to ask hard questions but you hit nail on the head.
|
| Jira is bad because it's slow and doesn't telepathically adjust
| itself to everyone's needs.
|
| Perhaps the author can buy ifuckinglovejiragotocompetitor.com
| to provide us with the answer.
| greenthrow wrote:
| Jira is as good or bad as you configure it to be. It's a tool. We
| long ago learned how to use JavaScript effectively despite its
| numerous flaws. If you're at an organization where you have to
| use Jira, surely you can find a way to make it work.
|
| That said, it's certainly not the Right Answer for everyone. But
| unilaterally hating on it is just kinda childish.
| snowstormsun wrote:
| You cannot really configure Jira so that the interface is free
| of lags and loads faster, though. Or that it does not make tons
| of network requests in the background. It's a tool, but there
| are bad also tools.
| gjvc wrote:
| Maybe the web is/was shit for this kind of application which has
| caused it to become the beast it is.
| bradwood wrote:
| Gitlab Enterprise.
|
| It's _far_ from perfect, but Gitlab Issues is a damn sight better
| than JIRA IMHO...
___________________________________________________________________
(page generated 2022-06-20 23:01 UTC)