Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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.


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.


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.


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.


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


That's precisely why Jira sucks: Because it doesn't stand in their way. And why you want simpler software, which by not being able to bend to their misguided will, does stand in their way.


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.


> JIRA really doesn't encourage anything in any direction

Given the amount of effort you devoted to replying to multiple posts, it feels disingenuous when you make an obvious and inaccurate statement as fact.

There is very little dependency graph organization (eg subtasks), which isn't reflected in most of the UI anyway as JIRA does push toward treating all tickets as a flat set. Work is a practical hierarchy of concerns and JIRA never made much progress away from a checklist (same as ASANA, Rike, etc).


> Anything beyond that is up to the implementors

"Implementors". Anything that needs to be "implemented" is either a) not finished, b) too big and complex, or c) both.

Dunno for sure how much less code Jira has compared to, say, MS Excel or Adobe Acrobat, but I could imagine it might be up to an order of magnitude. But you don't have to "implement" those; you just install them.


Better comparison product is MS Teams, not Excel.


Yes and no. Yes, it's more like JIRA.

But no, that's missing the point: That's what makes it an equally stupid "Enterprise product". Excel, OTOH, is arguably more essential to more corporations, and yet you don't see big international consultancies snap up contracts for six-year-long "Excel Implementation" projects with Fortune 500 corporations. You do see that for SAP, Oracle Business Suite (or whatever it's called nowadays), etc. They're products that you don't just install and use; they need to be "implemented". JIRA is more like that.

Or, IOW: I wasn't comparing, but contrasting. (Which, OK, is also a kind of comparison. But for this kind, it's Excel that is the better example than Teams.)


We're just talking past each other, I'm saying Jira is bad because "it's a foot gun, and bad people keep shooting me in the foot" and you're saying "they shot you in the foot because they are bad". We are both right, technically, but I don't like working with foot-guns for this reason.


JIRA empowers bad management to be so, so much worse. JIRA is the assault rifle of footguns.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: