Live data from Hacker News

The Return of Fancy Tools

macwright.com

191–200 of 224 posts

Re: The Return of Fancy Tools

#191

First, this is an interesting take, and I think there is some kernels to consider in it. However, the author is painting very broadly with a large brush and smudging a lot. I have been happily using PyCharm/IntelliJ since what feels like the dawn of time. It is a perfectly complex and rewarding Fancy Tool. People still use IDEs for C/C++ this whole time, etc. I think the author is taking their personal journey and ex…

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?

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.

Re: The Return of Fancy Tools

#192
post #79

Earlier quoted context omitted.

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 tr…

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.

Re: The Return of Fancy Tools

#194
post #105

Earlier quoted context omitted.

Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them: * Some of them make a mess of some part of git; one of them put its info in separate git branches you cou…

> a single issue could be in different statuses depending on which branch you were on To me this is the main point of storing issues in git!

Consider the "no overarching view" part: if you just cloned the repo, you'll see a bunch of open issues and no hint that they're already being worked on, because you have to check out each branch to see if that issue has updates.

Re: The Return of Fancy Tools

#195

Earlier quoted context omitted.

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?

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…

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

Re: The Return of Fancy Tools

#196

Earlier quoted context omitted.

Exactly. I'd guess that a majority of VS Code users are relatively new to programming. Not to say that there aren't experienced people who have switched, especially among the TextMate/Sublime Text crowd, but the incredible growth in users? I think that's largely a result of new programmers choosing the same editor, not old programmers switching.

Don't know if I'm representative, but I've been using Visual Studio for C++ stuff for about 20 years and switched to "mostly VSCode" a few years ago. I guess the reason is that I never used more than 2..3% of Visual Studio's features. Some features in VSCode are a bit too bare bones (especially the debugger), but somehow the user interface makes a lot more sense to me, and most of the times it feels faster and more l…

Is that that much of a shift? VSCode probably isn't Visual Studio but isn't it related obviously. It would seem different if you migrated from Visual Studio to sublime or xcode or something.

Re: The Return of Fancy Tools

#197
post #139
post #79

Earlier quoted context omitted.

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 tr…

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)

Re: The Return of Fancy Tools

#198
post #79

Earlier quoted context omitted.

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 tr…

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

Re: The Return of Fancy Tools

#199
post #79

Earlier quoted context omitted.

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 tr…

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…

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.

Re: The Return of Fancy Tools

#200
post #39

> JIRA was replaced by GitHub issues This is absolutely... not the case. Sure, for some kinds of projects Github Issues might do, but for anything "real" Github's issue and project management is a serious regression. --- These tools are not replacing anything, but addressing broader and broader markets. They lower the barrier to entry and bring more people into the fold (perhaps at the expense at having a lower ceili…

I’m not sure I agree, I think things like GitHub issues are actually replacing Jira for a lot of companies who either aren’t yet, or not too heavily invested in the atlassian approach. We did a comparison program with a sister city who uses Jira for their entire process because it had been a good time-tracking system at the time, and we found that their project managers and developers spend around 5 hours a week on s…

I work on a large open source commercially funded project, where we more or less have to use Github Issues in one way or another, because that's where community report issues, and I find it very difficult to plan projects on Github.

Github Issues/Projects falls down in a bunch of small and minor UI issues. It's things like being able to have a seperate list of "these are issues for our project, and these are the ones we've prioritised/organised/committed to" (having a backlog) or just easier filtering and sorting.

What I think Jira is really good at is having a backlog, and a project board, and being able to drag things between. It's such a simple set of features I used from Jira that I find valuable but is missing in Github Issues.

Post reply on HN