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

> yet it still is better than the alternatives.

Not in my experience. I'd much rather use GitHub issues or a range of similar products. Finding and searching works well. Performance is good. Organization is feasible. Labels work fine for customization.

> Jira is like democracy, it isn't perfect and is full of flaws, ...

Using a pithy cross-disciplinary metaphor to try to bolster support for an argument doesn't do much for me.

I would appreciate, on the other hand, if you elaborated on the details of other alternatives you've tried and what problems you've seen.



I mentioned on the previous comment, but it was labeled as Jira cult.

Developing software for 30+ years.

Before Jira came to be, in-house stuff based in Perl CGIs, Lotus, DOORS. ClearQuest, Bugzilla, among others.

After Jira came to be, Trello, GitHub, Azure DevOps, TFS.

None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.


> Developing software for 30+ years.

Cool. Similar over here, though admittedly not with source control or bug trackers for that long. :)

> None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.

I think I see where you are coming from. But Jira's cost (efficiency, complexity, confusion about how to use them, etc) for all these integrations is tremendous. It is easily to make a tremendously better user experience over Jira, even with a pile of integrations.

And yes, I understand that building software for enterprises can be demoralizingly painful and frustrating. To paraphrase another quote, I like everything about enterprise software except the enterprise part. I find the general claimed philosophy of "we are risk averse" often is insincere, a rationalization for inefficiency, and a confusion about what risk means over different time scales. Sure, constant churn is risky. But falling into a pattern of not trying new things inevitably leads to stagnation. Better to have some failures than never to try.


> None of them provides the same seamless integration between documentation, code changes, change requests, project management, build pipeline, in-house deployment and quite relevant in enterprise context, customization.

Indeed. Often less is more. Your comment may inadvertently be making my point for me. :)

For example, a hyperlink (implied is fine, added in a view is fine) between a commit message and a ticket in my view, is possibly the perfect level of integration.

Integration does not have to (nor should it) mean poor performance or usability.




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

Search: