Hacker News Reader

Right. The idea that Jira has been replaced made me laugh.

There's probably a crowd of people that want to move on to the next issue tracker flavour and that's fine but I've got work to do that isn't tool shuffling.

I'll use the one that integrates with so many of our systems and, though flawed, does a great job.

That integration piece is key. The people who want to replace Atlassian tools usually focus one part of the suite (usually Jira or Confluence), but to replace them you all you need a set of tools that work together.

It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide traceability from any point to another. You can do the integration yourself, but it's a gigantic PITA, and as the number of tools rises, the number of integrations you need to set up is going to rise terrifyingly fast.

I have a litany of complaints about the Atlassian suite, but none of the competitors have even have the services we need.

On the other hand, I find the integration between Atlassian tools to be pretty barebones. It feels very clear to me that Atlassian tools are really developed separately, with a separate jira task to integrate specific parts. There's no "coherency" to them.

You are right that it's difficult to replace the entire Atlassian suite. The thing about Atlassian is that when there's if there's a box to check on a feature list, they've made sure to check it. If you go around the office asking everyone what features they want, Atlassian is going to check all those boxes. That's pretty hard to compete with.

    There's no "coherency" to them.

It's interesting to hear you say that. With the integrations we have with Slack and Github, I see previews, summaries, etc thrown at me when I link things

I recently had to upgrade Jira and Confluence at the workplace. It was clear from their configuration methods and how they respond to errors/failures, they are written by different development teams. One needs to be an admin to experience this, ordinary users will see no difference.

Take for example the admin UI. When adding "Application Links" to link Jira and Confluence with each other, Jira has a nice tabbed interface allowing you to configure it easily, whereas in Confluence, you have to scroll down a long sidebar with dozens of options until you chance upon the required link. Had similar experiences configuring various other options at the filesystem level.

Jira configuration was more coherent, fault tolerant and failed gracefully. Confluence configuration on the other hand was messy in comparison.

Or even just the wildly different text formatting syntax across tools

As a bamboo user who is not an admin, everyone on that team can fuck right off.

Whoever thought it was a good idea to build a CI tool on a concept of information hiding is a monster who should be banished back to whatever eldritch plane they crawled out of.

You can’t have a coherent conversation with anyone about the functionality of Bamboo versus other CI tools because Bamboo is constantly lying to you about what is available. You don’t even know to ask other people for help with something because you don’t know if Bamboo can do it. So people use the ugliest kludges that their privilege level allows to get things done, creating an unmaintainable mess in the process.

Second this. Even within JIRA itself the markup it accepts is inconsistent. Back ticks vs double brackets being the bane of my existence.

It is infuriating the extent to which Atlassians tools are only slightly more integrated with each other than they are integrated with third party tools. If they’d done a better job with their acquisitions then we would all be complaining about how they’ve not done enough for third party tools.

I kind of want a modern version of Trac. Trac is essentially a collection of integrations that just happen to have useful features.

> It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide traceability from any point to another.

Isn't Phabricator trying to do all of this? It seems to get quite a lot of fairly high-profile usage in both enterprise and community-focused/FLOSS contexts.

I wasn't aware of this, I'll have to check it out. Looks like it would especially good for companies that can't or won't the atlassian tax.

I don't think I've ever seen integration between confluence and jira that mattered.

The useful ones I've seen are where Confluence automatically indicates jira tickets that mention the page and confluence pages that link tickets that will have their status embedded.

It's just those two though, it's also the git branches, pipelines, and release integration from jira, being able to see the support ticket cases and / or alerts that were the cause of ticket/branch/release.

I'm in no way arguing that atlassian does a great job here, only that no one else offers that end to end integration. (Possible exception of phabricator mentioned in a sister thread)

Well, to add a counterpoint, never in my career I have encountered a place with a proper atlassian products integration. The most common integration I saw was using Jira and Confluence, which seems a little underwhelming to me. In all the places I have seen a mishmash of different products not really glued together and the workers had to navigate that mess. One of the places I’ve worked on had salesforce for customer sided issue tracking, and JIRA for software development tracking. Support engineers had to copy and paste tickets to raise defects and bugs, keeping track of all the interactions in both systems. Silly stuff.

That's my point though, the alternative is glueing all those tools together, and Atlassian promises (and frankly often falls woefully short on delivering) to give you an integrated out of box experience.

>Right. The idea that Jira has been replaced made me laugh.

It shouldn't though. Jira wasn't always here, and it wont be here forever.

And what's even more important, and is the point of the post, trends don't stay the same, whether a tool still maintains its existing userbase or even increases it.

In a changing market, a tool might hold or even increase its userbase, but still end up with much smaller marketshare.

If we add qualitative considerations too, then it's also very possible a tool to remain dominant even in market share, but still lose mindshare (and eventually be dropped by the next gen of developers).

Tons of people and companies use Visual Basic too, but it's not where things are happening (or what one should study to get a job in 2021).

> I've got work to do that isn't tool shuffling.

Is most of that work waiting for Jira to respond to your action so you can take the next action?

I don't know if it's possible to have an adequately fast installation of Jira (since I've never seen one in a decade of Jira use at various places), but I do notice that people who have to put a lot of things into Jira seem to mostly use text editors or word processors to actually plan, and then transfer it a piece at a time into Jira once the initial result is done. Yesterday I was in a planning session with two others, and we did that planning with headings, bullet points, and concurrent editing by all three of us in a Google doc.

> I don't know if it's possible to have an adequately fast installation of Jira

That's not my experience of Jira. The cloud version is the best, and our current on-prem installation is perfectly fine. I agree that Jira isn't the snappiest tool to use, but I don't sit there consciously waiting for it to do stuff.

> I agree that Jira isn’t the snappiest tool

It is forbidden in the ToS 3.3 to “(i) publicly disseminate information regarding the performance of the Cloud Products“.

https://www.atlassian.com/legal/cloud-terms-of-service

I also confirm that in my experience the performance of the JIRA Cloud installation has been mostly fine. It's not amazingly fast but only having used JIRA cloud, even with loads of projects and so on, I always thought it was weird to read all the stories of poor performance.

Compared to something like pivotal tracker, Jira feels like trying to swim in glue.

It just gets in the way. Individual actions are tolerable-ish. But it’s never setup right. Constantly hunting for the field that is blocking story creation. Permission issues all over the place.

Finding things is often nightmarish.

Management basically doesn’t care, and doesn’t want to put effort into making it work in sane fashion. Yet freak out if team wants to use something else. So we do all our planning and story tracking in google sheets instead.

It's like medieval doctors and hand washing.

Fast solutions clearly exist. But somehow everybody ends up using slow Jira.

Even if that clause is enforceable, you can just tell people about it instead. No company would try to prevent talk about their products' good performance.

Actually, I’m obviously not talking about Jira but imagine some made an issue tracker in cloud mode and programmed it using microservices, the speed of each microservice would vary a lot depending on workload, time of the day, location, time since last access of the document/attachment/screen/userdata, configuration of the instance, importance of this customer (maybe I would give privileged speed to a good customer, or to one whom I’ve had problems with on other features) and it would vary so much that performance for one person would be hardly representative of another person’s experience.

That would be one legit reason for thinking about writing this clause. Because it’s really curious to think about writing that.

Not that I disagree, although I feel the problem here is that this clause then can apply to all types of softwares. And even hardwares too. Just think if tomorrow Apple says that you cannot talk about degradation in performance in iPhones (because battery capacity reduces over time or something). We both know this, like we know that a user's experience will differ from the other. A company shouldn’t be adding a clause to prevent talking about this, it sounds like a malpractice to me. (I know it’s not that serious but still…)

Anytime I see similar language, I know I do not have to look very hard to understand why someone felt it worth producing.

They might as well say it:

Will be slow, we feel that does not impact the value proposition.

Our license revenue is super necessary and this is not a race.

Ya, slow now because we need users and features now, go faster later.

If you need it to be more performant, pay us more and make the hardware investments we tell you to...

I personally would respect those more than a blanket gag attempt.

No doubt it depends on how you use it, but I find it very slow.

For example, I just tested following a permalink to a comment on a ticket. After 1.3 seconds I see the ticket - but it takes more than 7 seconds until I'm scrolled to the right comment, all the ticket details are loaded, and so on.

And the slow-ass lazy loading means you daren't click something between 1.3 seconds and 7 seconds, because at any moment a new button or linked issue box or the addition of status icons next to links or something will reflow the page.

In my experience this shitty performance is baked into every single interaction with Jira. You want to create an issue? Two seconds to show up the form. You click the 'epic link' dropdown on that form? A full second just to display a dropdown menu. Oh, and you also want to open the 'label' dropdown? That'll be 1.8 seconds.

And all those are on Cloud Jira, at a weekend, on a <300 ticket project, on a powerful developer workstation.

I used to complain about Jira for similar reasons. Then we switched to Azure DevOps, and now I have tears in my eyes and cry "I want my simple and fast Jira back!"

> but I don't sit there consciously waiting for it to do stuff.

100% of the time I want Jira to do stuff is when I'm interacting with it, and thus absolutely waiting for it.

I use Jira a lot. Waiting three seconds per action makes me think that interfaces based on old-timey mainframes were probably faster.

I am so, so sick of Atlassian’s bullshit.

I remember when we used Trac on a project and it seemed so primitive in many ways, but as soon as I had to use something baroque (broke), I wanted to go back to Trac.

Not to say that Trac isn’t fancy, it just chose a very specific dimension of fancy to focus on and ignored anything else.

Org mode is easy to get started with if you’re an emacs user. I am one. But before I used emacs, there was no org mode in my life. And let’s face it, while emacs and vim allow you to craft your flow, most people are gonna use something like VSCode. Emacs and Vim have not been able to escape their old school image, even with all their awesomeness.

I’d argue that ease-of-starting also includes how visible something is, since you can quickly find it and find resources for it. Most text editors don’t have org mode or have a small, half baked subset of it at best.

A lot of amazing adjectives apply to org mode. Ease of use isn’t it until it climbs over the emacs wall.

Not trying to be combative. I’d love if more people used org. Would love to be educated here if something I said isn’t accurate.

I agree with you. I had used micro-emacs in the 80's and when, about 3 years back, I heard about org mode I wanted to become a big boy and start using emacs. It was a bitter struggle and for many months I regretted that I had even started down this path. But now I can do the basics and it feels much better. I know that I will be rewarded if I persist.

The post is not about what this or that place or person uses or "always have used".

It's well understood that some people have "always used" IDEs, and other people have "always used" Vim/Emacs.

The post is about general trends. What kinds of tools were trending/rising at some point, what at another at so on.

In that sense, counter-examples don't negate a statistical observation. Only whether the trends described in it is right or wrong matters, not whether some or even many buck them.

I agree that anecdotes don’t negate a statistical observation. The original article isn’t a statistical observation though.

Personally, I think there's generalizations both ways here. Your experience doesn't map one-to-one with the author's, and the author's won't map to yours. Neither of them are absolute when applied outside of one life. I'd judge its accuracy by how well it resonates overall with people, and judging by its position on the front page and the sentiment of your last paragraph here, it resonates quite well.

At least in my own specific case, I have neurological damage that has swiss-cheesed my memory. I get that not everyone needs nor wants smart tools, but I prefer to have at least a moderate safety net.

The fact that there's such a wide range of options doesn't hurt. I'm currently using Logseq for note-taking (yeah, I actually had to look up the name. That's how bad my memory is) and it's been a considerable help there. VSCode, well, I use it with custom task setups that script as much of the manual work that I'd be likely to slip up on as possible.

Not everyone needs that sort of thing. I didn't 20 years ago.

So, yeah, I agree with what you're saying-- different tools for different needs.

Jira still for the complex stuff, with many teams in enterprises. But maybe less than it was in simple projects, with one-to-one relationships between issues tracking and repository?

There's a bias in HN that favours the simple and clean. But the real world is full of bureaucracies and complications due to legacy and/or politics or some other factors (like momentum).

When HN users argue that certain tools (like Jira) is too complex, they imagine that a simpler tool following a simpler process would've worked. For them, may be it would, as a greenfield project, but not for the enterprise currently using Jira or is going to adopt it.

Is this complexity warranted? I mean could not the same goals be achieved by less formality and less complexity?

Most Engineering teams would probably work frictionlessly with any simple Kanban style board.

The pull force in JIRA is how much it gives PM's and other managers a feeling of air traffic control visbility. It ends up serving as a medium for less technical people to digest and participate in a project.

The features that in my opinion keep Atlassian profitable is all the automatic reports and analytics features more so than the daily work functionality.

I can't defend confluence for various reasons, but JIRA? HELL YEAH.

The problem is that JIRA is a powerful tool that is often misconfigured or otherwise made to suck more than it should.

For example on one of my current projects, both JIRA and confluence are put behind malfunctioning SSO meaning you have extra annoying steps that sap your energy and will every time you open them. And then you have to face that someone made a royal mess in it and we have to deal with it - without access to settings to fix IT. And the final nail is that effectively we can't use any external integration, because it's all blocked, including just using the API on your own.

Now, if I had the power of administrator there...

We would have better work flow, with automation supporting human overrides.

We could link issues with our Github Enterprise and use local clients (org-jira, gojira, etc) as well as a bit integration in MS Teams.

And I would fix login so that accessing JIRA or Confluence didn't feel me with annoyance of "where is that fucking RSAID" and "goddamn fix MFA already"

In some cases they could and in some cases they couldn't. For a particular example, in fintech development a bunch of formal ceremonies are non-negotiable, you need to track, document and query who ordered, developed, built and tested what and why and has a change request been formally approved by someone who has the authority to do so. In other cases, the formality is optional, but it's still a choice the organization has made.

However, in any case it's not a technical discussion about tools, that would be putting the cart ahead of the horse, it's about organizational change, which tends to be as slow and difficult as a rewrite of a technical product. If the organization chooses to have a particular process, then they'll switch tools if needed to support that process; and the fact that they could use a more conenient tool if they would choose less formality and less formality does not carry much importance, that choice is determined by other factors.

Conway's Law seems relevant here, but I don't think I've seen (or seen the desire for) it to be used aspirationally, like "we need to become the kind of company that operates with these complex tool systems).

We undertook a migration from not-JIRA to JIRA. Our previous issue tracker would let us have the same task in different columns on multiple boards. You could do your investigation, post your comment, reassign to the reporter, and move it into your "waiting" column. Then they would move it into their "in progress" column, do their piece, and get back to you. A complex cross-org issue might show this cycle 5+ times.

In JIRA it is completely impossible. A task has one project and one status. You're lucky to have view and comment rights on another team's task, forget about change-status or reassign. An admin can "move" an issue but then it's gone from your own world.

The net result: the issue tracker is no longer a communications medium, but a paper trail for the bean-counters, where you laboriously log conversations and decisions that actually occurred by email or Slack. There will be a JIRA corresponding to any give issue, but reading the JIRA will not tell you the story anymore.

That sounds interesting, what issue tracker did you use before?

It works well for simple stuff too. You can just _not implement_ a complicated workflow.