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

Linear – A fast issue tracker

linear.app

Post reply on HN
Print view View original

121–130 of 230 posts

Re: Linear – A fast issue tracker

#121

Post by tbodt »

enra wrote: post #9

Founder here. Here to answer any questions you might have. We built Linear as we’re frustrated the practices and the available tools when it came to managing software projects. On the product, we especially tackled the performance problem. Everything is synced to the client and we sync just delta packages between the cloud and client as changes happen. This way all actions a happen instantly and navigating around the…

The landing page seems to say that interactions take under 100ms. What computer did you measure this on?

Re: Linear – A fast issue tracker

#123

Post by _Qeomash_ »

jnwatson wrote: post #75
ChrisMarshallNY wrote: post #46

Earlier quoted context omitted.

I was a JIRA admin for a number of years for an organization that had a heavy QA workflow. It was all about making sure that every issue had an "owner," at any given time, a strict approval and verification process was followed, and that as much up-front data as possible was collected during the initial report. In my experience, unless the people entering the issues are paid, professional engineers, we'll never get t…

In my experience, it isn't Jira that people hate, it is the horrible rules and bureaucracy-ridden workflows that Jira allows an admin to implement. My team switched back to Jira after trying several other tools and we're pretty happy.

As a current Jira admin, I constantly have to fight this. A non dev team came into Jira and implemented a huge octopus of a workflow (despite my strong advice against it) and were shocked to find out it didn't really help them work better.

The handful of teams inside that department that I've gotten to switch over to a simpler To Do / In Progress / Done style workflow have been much happier.

Jira has many, many faults, but most of them are what the users do to themselves.

Re: Linear – A fast issue tracker

#124

Post by the_arun »

I still miss Bugzilla - which was relatively fast. Thought modern js libraries make parallel API calls and make it look fast. But JIRA is too slow and becomes slower with number of tickets and users. Any day, I would prefer speed over nice user interface.

Re: Linear – A fast issue tracker

#125

Post by magicalhippo »

ithkuil wrote: post #54
magicalhippo wrote: post #42

Earlier quoted context omitted.

We're a JIRA customer and we're quite happy. It's not slow, at least to any degree that matters. We're not a huge team, nor do use much more than tickets with FishEye integration though. We also have a self-hosted instance. But for us it has worked quite well, and I have better memories of JIRA than say MantisBT which I used before.

Cloud or self-hosted?

Self-hosted, as mentioned.

Re: Linear – A fast issue tracker

#126

Post by jiveturkey »

Benjammer wrote: post #48
tyre wrote: post #3

We've been using Linear for a couple months. It's kind of like Superhuman in that the primary benefit is hotkeys. Otherwise it is an issue tracker. I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems. New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you pil…

Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs: As we move more and more towards ubiquitous "Product Orgs," separate from engineering, I think we're seeing backlogs just explode in size at most places. People need to realize that a large engineering backlog has a lot of negative effects on the SDLC (& velocity) as a whole. I wish more people would embrace heavy-handed WIP…

yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers aren't product experts. and if the customer is an engineering team, then engineers mostly make mediocre decisions, typically because of poor incentives (gaming story points).

in every company i've been at that is larger than a handful of people that all know each other, a separate product org is a requirement if you want a product with broad appeal.

i'm not sure what your complaint about the product backlog is. product people should be generating a large backlog. that is literally their job, is it not? it's only through a large backlog that you can say, hey we need more engineers. or hey, our vision doesn't match our capabilities -- refine it. and so on.

How exactly does a large backlog have a negative effect on velocity?

Re: Linear – A fast issue tracker

#127

Post by sangupta »

I am usually keen to try new tools. However, with the limit of 250 active issues and hassles to archive old ones, not many open source projects will be able to use it. On the other hand, I can't recommend it in my BU/company unless I have evaluated it for full extent.

Consider, providing a free-tier for open source projects.

Re: Linear – A fast issue tracker

#128

Post by tbrock »

CraigJPerry wrote: post #104
tbrock wrote: post #78

Earlier quoted context omitted.

Ours JIRA instance took multiple seconds to load modals. Think 5+ seconds. It was miserable. I would have gladly paid more for faster speed but it turned out the APIs were blazing fast and it was the JS that was slow. Not sure how we have had such different experiences. Seems impossible that your JS was executed that much faster than mine. I was using chrome FWIW.

5+ seconds sounds wild. Our active users number is a multiple of the 5k max users for jira cloud and the only actions i can think of that are >2s are bulk edits and complex jql

We must have been using it incorrectly then, oh well. Good riddance Atlassian.

Re: Linear – A fast issue tracker

#129

Post by golemiprague »

jiveturkey wrote: post #126
Benjammer wrote: post #48

Earlier quoted context omitted.

Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs: As we move more and more towards ubiquitous "Product Orgs," separate from engineering, I think we're seeing backlogs just explode in size at most places. People need to realize that a large engineering backlog has a lot of negative effects on the SDLC (& velocity) as a whole. I wish more people would embrace heavy-handed WIP…

yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers aren't product experts. and if the customer is an engineering team, then engineers mostly make mediocre decisions, typically because of poor incentives (gaming story points). in every company i've been at that is larger than a handful of people that all know each…

You say it as if it is a fact, what are you basing it on? There are so many examples of start up companies where most of the team were engineers and they created very popular and successful products. It might be even the opposite, many times product people are not necessary really, a middle man between customer facing people and engineering that nobody really needs.

Re: Linear – A fast issue tracker

#130

Post by Benjammer »

mumblemumble wrote: post #98
Benjammer wrote: post #48

Earlier quoted context omitted.

Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs: As we move more and more towards ubiquitous "Product Orgs," separate from engineering, I think we're seeing backlogs just explode in size at most places. People need to realize that a large engineering backlog has a lot of negative effects on the SDLC (& velocity) as a whole. I wish more people would embrace heavy-handed WIP…

Depending on your company culture, this may be difficult to do, but I've seen good luck with moving toward a model where the product team doesn't push things into developers' to-do lists. The product folks supply a strictly prioritized wish list, and developers pull from it. Always one thing at a time, always the very first thing on the list. It's the only way I've seen to get the product people to shift their thinki…

What kind of scope level do you think works when talking about that list? Like project level instead of tasks, and then engineering figures out how to deliver the prioritized project? Otherwise it kinda just sounds like a backlog to me, just curious how you see the difference there.

Also, I've seen product orgs that focus a lot of energy on not being burned, regardless of the scenario. They use their position at the crux of many communication channels to subtly shift blame around. Which is relatively easy to do when your role is complex and many-faceted.

Post reply on HN