Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Return of Fancy Tools

macwright.com

Post reply on HN
Print view View original

101–110 of 224 posts

Re: The Return of Fancy Tools

#101

Post by pjerem »

bradknowles wrote: post #55
greatgoat420 wrote: post #37

Earlier quoted context omitted.

I have never used Jira, could you say more about your feelings towards it? Currently we use an old in-house solution and are thinking of shifting.

Jira is very sensitive to the configuration you build for it, and the hardware it is running on. The full configuration for Jira would make an Encyclopedia look small. Get that wrong (as many places do), and it is hard to use and dead-dog slow, at the best of times. But if you have a real Jira wizard who can configure things correctly, then it can easily be the fastest and easiest way to organize your development and…

> There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly.

This has been done wrong by Atlassian.

I’m sometimes really jealous when I see fast self hosted public JIRAs and by the meantime, the instance I have to work everyday on atlassian cloud is both snail-slow and airplane-heavy.

Re: The Return of Fancy Tools

#102

Post by p_l »

samat wrote: post #91
chii wrote: post #70

Earlier quoted context omitted.

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…

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

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"

Re: The Return of Fancy Tools

#103

Post by makapuf »

jes wrote: post #86
meierjo wrote: post #61

Earlier quoted context omitted.

Ahhh vi. I was reading the article hoping to see mention of vi… Emacs was cool too, but I never got hooked - was very comfortable in vi land as it was the first editor I used on the old time terminals (green/amber CRT and a keyboard you could kill with). Oh the power of vi/EMACs and regular expressions without ever lifting a finger from the keyboard!

Exactly. I well remember the green or amber 24x80 terminals. Televideo, Lear-Siegler, etc. Bundles of twisted pair cable for tty lines back to the machine room. Good times....

But wasn't vi the Fancy Tool then?

Re: The Return of Fancy Tools

#104

Post by Talanes »

porker wrote: post #82
dleslie wrote: post #16

Earlier quoted context omitted.

I happen to agree. I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth. Since last using Jira I've never felt nearly as aware of the state of a project as when I did.

Yes, dashboards are underrated by those who haven't used them. The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals. The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so t…

For some reason, plenty of people in management don't seem to realize that raking people over the coals over individual data-points just incentives your workers to avoid giving up data.

Re: The Return of Fancy Tools

#105

Post by Izkata »

danielheath wrote: post #18
breakfastduck wrote: post #11

Earlier quoted context omitted.

I'm lost now when it comes to project / dev / story etc management tools. No idea what the best option is, any recommendations for tools developers will actually use or do you just need to do a custom integration with github issues?

I've long wished for a tool that (for git) what fossil has built in: issues stored in the repository, where developers can use their full range of tools to work on them locally. A few additional things would be required to make this work for less-technical team members, and you end up building some of your own workflow, but it means that E.G. you have options like "update the description of a ticket as part of the pu…

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 couldn't delete without breaking it, to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker.

* At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view.

* The rest effectively ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues.

* Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker.

Sibling mentions git-bug, a few others I recalled/quickly found:

https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones)

https://github.com/dspinellis/git-issue

https://github.com/neithernut/git-dit

https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)

Re: The Return of Fancy Tools

#106

Post by jcelerier »

> Visual Studio was “disrupted” by Sublime Text and TextMate,

no it was not. people didn't migrate from VS to Sublime, they migrated from notepad++ to Sublime. I have never met anyone who stopped using IDEs once they started, except maybe for VSCode with a few hundred plug-ins to reconstruct an IDE piece-wise (but with much less "integration" between the different plug-ins)

Re: The Return of Fancy Tools

#107

Post by Kinrany »

runevault wrote: post #54
aflag wrote: post #4

Earlier quoted context omitted.

I don't think good tools are necessarily easy to approach. Some of the best tools I know have quite a steep learning curve. A good tool is one that gives you power. It makes difficult and complicated tasks easy and simple. It may come with the cost of getting good with using the tool, but once you master it, you don't know how you lived without it.

A good tool picks an audience and builds everything with them in mind. You can make a tool aimed at beginners of some discipline with the understanding it may not satisfy power users, but that doesn't make it a bad one, just bad for that audience. Same in the other direction, tools aimed at optimizing power users ability to do their task may seem completely impossible to a beginner, and that's totally okay.

Audiences change over time. Projects need something less ephemeral to aim for.

Re: The Return of Fancy Tools

#108

Post by Kinrany »

allset_ wrote: post #98
AlotOfReading wrote: post #51

Earlier quoted context omitted.

The biggest issue by far is how slow it is. I don't mean bubble sort slow, I mean deliberately engineered quantum bogosort. A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful. That leads to all sorts of avoidance because using it for anything takes long enough to be worth documenting…

I don't like Jira that much, but this is just blatantly false. > A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful I use Jira daily, it's nowhere near this bad. It's not fast, but pages load in about 5 seconds. > changing ticket status can't be done without opening separate pages You…

They probably meant seconds. A website that takes seconds to open is unusable.

Re: The Return of Fancy Tools

#109

Post by noobermin »

jcelerier wrote: post #106

> Visual Studio was “disrupted” by Sublime Text and TextMate, no it was not. people didn't migrate from VS to Sublime, they migrated from notepad++ to Sublime. I have never met anyone who stopped using IDEs once they started, except maybe for VSCode with a few hundred plug-ins to reconstruct an IDE piece-wise (but with much less "integration" between the different plug-ins)

Not to drag on the OP but I really wonder about people who are the subject of these articles who supposedly migrate from x to y to z, because at least for me I'm still using emacs like I did 10 years ago. The things I focus on is more about doing work than what tool I'm using.

Do people really migrate or is this more about growth in a user-base? A higher rate of growth of one user-base relative to another user-base is not strictly due to people migrating (as if it's zerosum) but could be due to a tool capturing more new users, like junior developers and such. How often do people really migrate wrt tools they actually use for work?

Re: The Return of Fancy Tools

#110

Post by morelisp »

Izkata wrote: post #105
danielheath wrote: post #18

Earlier quoted context omitted.

I've long wished for a tool that (for git) what fossil has built in: issues stored in the repository, where developers can use their full range of tools to work on them locally. A few additional things would be required to make this work for less-technical team members, and you end up building some of your own workflow, but it means that E.G. you have options like "update the description of a ticket as part of the pu…

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!

Post reply on HN