11 ms·

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

by tyre 6y ago

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 piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better! But I don't think it really solves the problem. For most organizations, tracking tickets is a solved (by many products) problem. Starting with a new tool has the appearance of making things better, but leads to the same place. The problem is not the tool, it's the structure of the organization.

tbrock 6y ago
I tend to agree but I have a anecdotal counterexample. We recently switched from JIRA to Clubhouse by importing our history and backlog wholesale. Due to the substantial performance bump we have definitively leveled up as a team. Status updates that used to happen in slack channels are now captured in Clubhouse, people log in to check on progress, stories get love and details. JIRA cloud was unusably slow and as a result we didn’t want to use the tool. We hated it even though it technically “worked”.
- ryanisnan 6y ago
  > JIRA cloud was unusably slow and as a result we didn’t want to use the tool. We hated it even though it technically “worked”. - every JIRA customer ever
  - magicalhippo 6y ago
    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.
    - ithkuil 6y ago
      Cloud or self-hosted?
      - magicalhippo 6y ago
        Self-hosted, as mentioned.
        p_l 6y ago
        A lot of issues can be mitigated when you self host vs using JIRA Cloud, not just because you might have beefier hw and better network link. While I suspect it got better, periodic reindexing and similar cron jobs were a hell on a team separated by 9 hour timezone difference, because time chosen for convenience in San Francisco meant many Mondays of "Atlassian Cloud is down" for team in Warsaw.
        magicalhippo 6y ago
        Wow, that sounds horrible. While we're all in the same timezone in our company, we're also programmers... so that doesn't always matter. I've been using our JIRA in the middle of the night on several times, and it's just... there. edit: so yeah just highlights the self-hosting vs cloud...
    - munchkinship 6y ago
      you are self-hosted, which is different from cloud.
      - magicalhippo 6y ago
        But we're still JIRA customers, which was the point I was trying to make.
    - m_eiman 6y ago
      Same here - went from MantisDB to Jira and it's a big improvement in so many ways.
- ahnick 6y ago
  I haven't noticed JIRA cloud being that slow, but maybe that's because the team is small. Did you start to experience performance issues as team size increased? Did you have a lot of issues or data held in the issues? Or was there another issue that you think led to the slowness? I'm interested in your insights as we went with JIRA initially, since it was pretty much the gold standard and we thought it would scale nicely as we added team members, but if it is not going to do so, then it may not be worth the JIRA premium.
  - icegreentea2 6y ago
    I don't want to put words in OP's mouth, but I suspect that OP was referring to just like... "you click and something and then wait" type of slow. Something like, taking several seconds to load an issue. In my case, we were a small team (<10 users, <1k total issues split in maybe 8 projects), and were running into random load time slowness irritations. It never stopped us from doing what we needed to do, but it sure did make it more frustrating to do it. We are using a cloud instance.
    - hinkley 6y ago
      It’s a documented phenomenon in UX that if an activity involves a quantity of small pauses in a short enough time span, that the user perceives them as a single, long pause. If your app is fast but your workflows are terrible, people will call you slow because everything takes four interactions. If you have a bad workflow and a slow-ish app, people will talk about you on the Internet.
- ChrisMarshallNY 6y ago
  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 the information we need up front. I have found that the basic GitHub model works well for me. When someone reports a bug, they are doing me a favor. It's in my interest to ensure there are as few roadblocks as possible to them sending a report. If they give contact info, then I can contact them with specific questions. In my experience, a simple email form is the best way to solicit reports. It may have a workflow hidden behind it, but I have found that the simpler the workflow is, the more likely it is that the issue tracking will work. JIRA basically starts off complicated, and it's possible to make it much, much worse. It's also slow, but that wasn't really the problem we had. The workflows and forms were where it fell down for us.
  - jnwatson 6y ago
    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.
    - Twirrim 6y ago
      All the extra plugins etc. that people bolt in to get those extra features really slow it down too.
    - _Qeomash_ 6y ago
      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.
- ghshephard 6y ago
  Not sure what happened to you - but speaking anecdotally, but from someone who logs into Jira Cloud every day, and spends 20-30 minutes interacting with the interfaces over 8-10 hours a day, and has done so for the last 3 years - it's had a handful of outages, nothing that really rose to the level of being memorable though (and less than any internal issue tracker I've worked with) - and the performance is, fine? I mean, it's not <50ms twitch fast, so, I guess I'm losing a minute or do wall-clock time + whatever larger blocks of time that occur when I get distracted waiting for a ticket to come up - but it isn't at all what I would call "unusably slow". In our case though, we only have about 50 engineers and a few hundred thousand issues. Jira has performance issues in the 500 engineer / 100mm+ issue space - or it used to, perhaps they've resolved those issues by now.
  - tbrock 6y ago
    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.
    - CraigJPerry 6y ago
      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
      - tbrock 6y ago
        We must have been using it incorrectly then, oh well. Good riddance Atlassian.
        hinkley 6y ago
        Almost everyone is “using it incorrectly”, but it’s like the aphorism about assholes. (If you meet assholes all day long, you’re the asshole.) If your software encounters idiots all day long, you’re the idiot.
immy 6y ago
Boo to this take. Not all tools are the same and “Good tools obviate bad processes.” is a mantra I saw once in a talk that has stuck with me for 15 years. You’re not wrong that it’s a people problem, but tools shape human behavior. That’s Design. The quote is attributed to Michael B. Johnson, aka wave, Software Director at Pixar.
- kevmo314 6y ago
  API design is a great example of this. Good API design incentivizes the right choices and clean integration. I often argue that it's not just "oh this API matches the spec better" or "this API is lower maintenance" but rather that I've found certain APIs can almost trick developers into writing good code. It's a neat experience. That being said, there is some necessary internalization that a tool is solving a people problem which is maybe what OP is trying to get at. No matter how good an API is, if a developer is dead set on writing bad code, it'll be bad. So just deploying a new tool, no matter how clever, won't fix an organization that doesn't want to be fixed.
robotresearcher 6y ago
I'm genuinely interested: is this really true? Is Jira necessarily slow when there's a lot of stuff in it? I'm not sure I believe it. There are graph-of-objects-plus-metadata applications out there that are pretty fast. I'm not an expert in this domain, but I bet an issue tracker can be made that doesn't feel painful at real scales.
- elithrar 6y ago
  I didn't interpret the OP to mean slow from an "application performance" perspective - instead, as slow from a "process" perspective. The ticket needs to be filed in the right queue. It needs the "right" tags. It needs to traverse the "approved" workflow correctly. It didn't get assigned to the right epic. etc, etc, etc. It's all of that - the process built up over time, in response to organic needs - that makes things "slow" and drives such a rejection of these tools by developers and their teams. We (collectively) rarely step back and say "what process can we cut?" - only when we use a new tool do we have the chance to address that.
  - dpc_pw 6y ago
    It's both. JIRA can often be terribly slow. Each page loads about 10 seconds for me, and I don't know why. Other people say it is ~2s for them. I suspect it has something to do with networking and amount of requests being made, etc. Then, on top of it the flows in Jira can be super slow, which is another story.
- fredfjohnsen 6y ago
  No, it is not really true. It is completely false & you are correct to question it.
- jayparth 6y ago
  What's your question here? The premise of the OP is that they created a fast issue tracker. People complain about Jira being slow (me being one of them.) No one has claimed that all issue trackers are slow. ClickUp, Hive, Linear, are all snappy.
enra 6y ago
Thanks for the feedback and trying it out! I do agree that lot of the process issues often reside in the organization itself. In ideal world, you don't need any kind of tracking or process. Right things just happen. However, in reality is that companies often have goals and roadmaps they have to deliver. Things move fast and teams need to know what is being worked on. We've worked in 5 and 5000 person engineering organizations and need for coordination is always there. And personally, I just need to know what I need to do next. We spent the past year talking with our our early users. New startups and even teams of very successful companies, struggle with the process. They might know how they should improve things, but it's hard to find the time or energy to actually implement it. We want to help with this. So in addition to the tool, we are developing the understanding and practices software help the team to focus and reduces some of the bad habits we might have. The tool will then help teams implement and maintain these practices going forward. We ourselves also been working with this "Linear Method" which we shared here: http://linear.app/linear-method http://linear.app/linear-method
Benjammer 6y ago
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 limits, even for backlog. But, since backlog is now the primary output of "product orgs" at many (less-than-great) companies, you now have an entire org whose jobs depend on not learning that lesson. I don't know what the answer is, but I really am starting to hate this entire "product org" concept in general. It feels like we used to be able to just engineer our way around many of these challenges ("here, look what I built last week to justify my case"), or just get people into a room and talking. But once the decision channels become explicitly siloed off into a separate org with C-Suite-level autonomy, I'm not sure how you effectively bridge the gaps that form. Any engineers who feel like having a separate product org has been a benefit to your company's product quality and delivery speed want to comment on how you see this sort of thing working effectively?
- lifeisstillgood 6y ago
  By product org do you mean a silo of an organisation dedicated to one particular product (so if a company has five "apps" they have five siloes and five marketing teams five engineering teams and five board members ?
  - LukeShu 6y ago
    I understand it to mean that there is a part of the org (separate from the engineering team) that shapes the direction of the product; decides "these are the features we're going to implement, these are the issues we're going to address"; one way of looking at it is that their primary output is putting things in to the engineering team's backlog.
    - Benjammer 6y ago
      Yeah, this is what I was talking about. Software product management as a separate functional org from engineering. Not like old-Dupont-style product orgs.
sriram_sun 6y ago
> The problem is not the tool, it's the structure of the organization. Nicely put! Also, it's probably more like how the organization ended up evolving - something no one knew beforehand!
sriram_sun 6y ago
> The problem is not the tool, it's the structure of the organization. Nicely put! Also, it's probably more like how the organization ended up evolving - something no one knew beforehand! Newer products should start their sales pitch addressing that last sentence in OP's post.
m0xte 6y ago
Nailed it. The other problem cycle is “we’ll get JIRA right this time”. This is followed by happy clicky people immediately shafting it, at least two years of suffering and then some PM selling some new clothes to the emperor. Everything degrades this way. Even GitHub the moment someone adds workflow automation. Intent versus causality are two very different things. My favourite problem is a JIRA instance that sets a resolution as incomplete immediately on a ticket, which is a valid resolution so all my tickets are closed as far as it’s concerned. Ugh. I’m slowly working on an OSS replacement for all of this hell which is designed for inflexibility from an organisational perspective. It’ll be open source. I’m sure no one will use it because it’s inflexible.
SAI_Peregrinus 6y ago
I haven't tried Linear, but my company uses Jira. It's abysmally slow. Not "there are too many tickets and it's hard to manage" slow, just the interface is slow. I opened an issue link in a new tab. It took about 7 seconds for the page to become interactive (able to click on the issue status and get a dropdown) and about 9 seconds for the loading to complete and elements to stop jumping around. This is in Firefox 78 on a Lenovo T480 with 8th-gen Core i7 CPU. Speed.cloudflare.com reports 28.5ms latency with 38.1ms jitter, 339Mbps down. Not a generally slow setup. At least in the case of Jira the interface speed is a huge issue.
- flarg 6y ago
  This. Jira used to be famous for it's ease of use and fantastic cross linking between artifacts, but now it's always just very slow.
- zerkten 6y ago
  Is there a site that lets you run performance profiles in browser developer tools and share the results? I could imagine that being really useful internally for devs troubleshooting and working with support. It'd be harder to pull off as a way to shame poor performance because of the need to compare like with like, but I think it's needed to get the attention of folks. Accessibility checkers are often rudimentary, but they are available to non-technical folks in companies and can be very effective at getting a conversation started.
  - SAI_Peregrinus 6y ago
    No clue. I'm an embedded dev, so my method for getting the numbers above was the stopwatch part of my phone's clock app. Thus the "about" qualifiers. But it's slow enough to use a damn stopwatch app manually. That technique shouldn't even enter the discussion!
mumblemumble 6y ago
It's not just speed, it's complexity. I've seen the cycle play out enough to know the real thing that drives how productive a ticketing system feels: How many distinct kinds of people are using it. The new one always seems great, because whatever team pilots it is the only team using it, so they're able to keep it nice and lean and closely adapted to their own needs. But, as soon as the decision to migrate is made, then you don't just have additional teams using it. You have additional teams wanting to use it as a communication and monitoring channel, and building up reports and metrics and dashboards on top of it, and imposing restrictions on the ticketing system that ultimately limit other groups' ability to streamline their own workflows, and by the time everyone realizes they're back on the same old pain train yet again, it's too late to do anything about it. It seems that developers are always the ones who get hit the hardest, because they end up with the largest number of outside parties who want to get involved in their business.
deleted 6y ago
[deleted]
dmix 6y ago
Is Superhuman any good for that matter? I refuse to have to talk to a sales person on the phone in order to use a mail app. Which is what their signup flow required last time I tried.
mikepurvis 6y ago
> Don't migrate your backlog, start with only a couple engineers in a new issue tracker... I experienced this in the wiki/documentation space some years ago when my org migrated from the trac wiki to Confluence. It seemed like such a boost initially, but it wasn't a boost at all, it was just the fact that for the first ~12 months after migrating, you could trust that everything you found in the wiki was freshly written and up to date (and the overall corpus was small enough that the search function actually returned useful results). The whole experience has given me the idea of making a Confluence plugin that slowly fades out each page to grey as a visual indication of its waning relevance. Anyone editing, commenting, or "liking" the page immediately freshens it again, unless they somehow indicate that the action is actually a vote against (like nofollow is for links). When a page is sufficiently abandoned, it goes on a candidate-for-deletion list, gets a warning box at the top, and is blacklisted from appearing in the default search results.
- hinkley 6y ago
  If it’s late afternoon and I’ve finished or am about to start a particularly challenging task, I’ll tend to take on other tasks like basic research or wiki maintenance. Essentially I treat the wiki like a B-Tree. When the landing page gets crowded, I move a bunch of related things down one level in the hierarchy, trying to retain keystone ideas within the first to levels (and letting related concepts be discoverable from those). Over time the oldest links and links of only temporary utility get pushed out to the leaf nodes, where you aren’t likely to encounter them accidentally. Really, though, we should be applying the same sort of version control we have in our source code. You should be able to track down how old a paragraph is in the wiki.
- jmarcher 6y ago
  https://www.getguru.com/ https://www.getguru.com/ has a so verification where each page, called cards, has an owner or group of owners and a set expiration period (1 week, 3 months, 1 year etc.). Past the expiration the page gets marked as untrusted (it's on top of each card) and require to be reviewed by the owner(s). Any user can also mark a card as untrusted, prompting a review. Every expired card owned by owner get displayed to their owners in a dedicated UI (page) and can be quickly reviewed. The editor in Guru is a bit clunky at time (worst than Confluence... if that's possible) and not really suitable for something like specs, but I have yet to find anything that actually tries to prevent wiki rot. We also evaluated Confluence with this https://marketplace.atlassian.com/apps/123/better-content-archiving-for-confluence?hosting=server&tab=overview https://marketplace.atlassian.com/apps/123/better-content-ar... but if the concept is not a first class citizen in the wiki, it does not work as well. I tried to convince the people at Clubhouse (with their Write app in beta) and Notion, but I don't think they get it.
thayne 6y ago
I think the issue with issue trackers is that every organization has it's own way of tracking issues. So issue trackers often try to do everything for everyone, and end up being at most mediocre for most users.
deleted 6y ago
[deleted]
divbzero 6y ago
> 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 piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better! Sluggish software can be more than just a data bloat issue. It can also be caused feature bloat, or software architecture that scales poorly. Anecdotally, I recently worked on a project using a fresh Jira Cloud account. It was still slow.
- noir_lord 6y ago
  Jira is so slow I installed plugins in both the devtools I use a lot to view tickets without having to use the web interface, it's just painful when you have to view a lot of tickets quickly.
- kschrader 6y ago
  We do a lot of work at Clubhouse to keep things fast. We have alerts set up that fire if the p50 or p95 of certain actions spike and we treat it as a bug if things are headed in the wrong direction. We still see a lot of random cases of things being slower though (shakes fist at random browser plugin upgrades). It's a hard problems, but if you don't design (and monitor) for this from the beginning things are going to slow down over time as you scale to hundreds of thousands of users.
littlestymaar 6y ago
> New issue trackers feel faster for the same reason switching browsers tends to feel faster It's not necessary about faster process, but Jira is agonizingly slow: each click triggers a cascade of HTTP requests in a synchronous way and it literally takes seconds every time you want to do something. Everytime I have to touch it, I feel angry for the next hour just because of the induced frustration. Any tool more responsive would be an improvement for me.
lonelyasacloud 6y ago
"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." Imagine what would happen if everyone in an organisation had to use the same tool for text and code editing, say for some reason the PhB inflicted Word on the organisation as the only allowed code editor. Would that be good? From my pov, most of the churn with ticket trackers is down to current solutions trying to own everything and apply a one size fits all model to everyone in the enterprise. The upshot being that the ticket trackers are invariably a sh*tty compromise for many/most individuals in the organisation. Think about the number of slides and reports that are hand generated for progress meetings in an enterprises. What about all of the various todo apps and systems people use? Why would so much effort be expended if the enterprise ticket tracking system was meeting requirements? Fixing the problem requires using systems based on common standards that allow _individuals_ to use what works best for them but still interoperates freely with each other. fwiw, another shiney issue tracker will not do that unless its basic unit of tracking is something akin to a text file that can be shared with the next shiney issue tracker.
fmajid 6y ago
It's the same with communications tools. "Our email is an INBOX-trillion mess because we use unstructured email rather than structured tickets to manage our processes. Slack is the answer!". Six months later, they have the exact same problem with Slack because the communications patterns haven't changed. That said, some tools are really just abysmal, and richly deserve the hate directed at them.

by tyre 6y ago

tbrock 6y ago

I tend to agree but I have a anecdotal counterexample. We recently switched from JIRA to Clubhouse by importing our history and backlog wholesale. Due to the substantial performance bump we have definitively leveled up as a team. Status updates that used to happen in slack channels are now captured in Clubhouse, people log in to check on progress, stories get love and details. JIRA cloud was unusably slow and as a result we didn’t want to use the tool. We hated it even though it technically “worked”.

ryanisnan 6y ago
> JIRA cloud was unusably slow and as a result we didn’t want to use the tool. We hated it even though it technically “worked”. - every JIRA customer ever
- magicalhippo 6y ago
  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.
  - ithkuil 6y ago
    Cloud or self-hosted?
    - magicalhippo 6y ago
      Self-hosted, as mentioned.
      - p_l 6y ago
        A lot of issues can be mitigated when you self host vs using JIRA Cloud, not just because you might have beefier hw and better network link. While I suspect it got better, periodic reindexing and similar cron jobs were a hell on a team separated by 9 hour timezone difference, because time chosen for convenience in San Francisco meant many Mondays of "Atlassian Cloud is down" for team in Warsaw.
        magicalhippo 6y ago
        Wow, that sounds horrible. While we're all in the same timezone in our company, we're also programmers... so that doesn't always matter. I've been using our JIRA in the middle of the night on several times, and it's just... there. edit: so yeah just highlights the self-hosting vs cloud...
  - munchkinship 6y ago
    you are self-hosted, which is different from cloud.
    - magicalhippo 6y ago
      But we're still JIRA customers, which was the point I was trying to make.
  - m_eiman 6y ago
    Same here - went from MantisDB to Jira and it's a big improvement in so many ways.
ahnick 6y ago
I haven't noticed JIRA cloud being that slow, but maybe that's because the team is small. Did you start to experience performance issues as team size increased? Did you have a lot of issues or data held in the issues? Or was there another issue that you think led to the slowness? I'm interested in your insights as we went with JIRA initially, since it was pretty much the gold standard and we thought it would scale nicely as we added team members, but if it is not going to do so, then it may not be worth the JIRA premium.
- icegreentea2 6y ago
  I don't want to put words in OP's mouth, but I suspect that OP was referring to just like... "you click and something and then wait" type of slow. Something like, taking several seconds to load an issue. In my case, we were a small team (<10 users, <1k total issues split in maybe 8 projects), and were running into random load time slowness irritations. It never stopped us from doing what we needed to do, but it sure did make it more frustrating to do it. We are using a cloud instance.
  - hinkley 6y ago
    It’s a documented phenomenon in UX that if an activity involves a quantity of small pauses in a short enough time span, that the user perceives them as a single, long pause. If your app is fast but your workflows are terrible, people will call you slow because everything takes four interactions. If you have a bad workflow and a slow-ish app, people will talk about you on the Internet.
ChrisMarshallNY 6y ago
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 the information we need up front. I have found that the basic GitHub model works well for me. When someone reports a bug, they are doing me a favor. It's in my interest to ensure there are as few roadblocks as possible to them sending a report. If they give contact info, then I can contact them with specific questions. In my experience, a simple email form is the best way to solicit reports. It may have a workflow hidden behind it, but I have found that the simpler the workflow is, the more likely it is that the issue tracking will work. JIRA basically starts off complicated, and it's possible to make it much, much worse. It's also slow, but that wasn't really the problem we had. The workflows and forms were where it fell down for us.
- jnwatson 6y ago
  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.
  - Twirrim 6y ago
    All the extra plugins etc. that people bolt in to get those extra features really slow it down too.
  - _Qeomash_ 6y ago
    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.
ghshephard 6y ago
Not sure what happened to you - but speaking anecdotally, but from someone who logs into Jira Cloud every day, and spends 20-30 minutes interacting with the interfaces over 8-10 hours a day, and has done so for the last 3 years - it's had a handful of outages, nothing that really rose to the level of being memorable though (and less than any internal issue tracker I've worked with) - and the performance is, fine? I mean, it's not <50ms twitch fast, so, I guess I'm losing a minute or do wall-clock time + whatever larger blocks of time that occur when I get distracted waiting for a ticket to come up - but it isn't at all what I would call "unusably slow". In our case though, we only have about 50 engineers and a few hundred thousand issues. Jira has performance issues in the 500 engineer / 100mm+ issue space - or it used to, perhaps they've resolved those issues by now.
- tbrock 6y ago
  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.
  - CraigJPerry 6y ago
    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
    - tbrock 6y ago
      We must have been using it incorrectly then, oh well. Good riddance Atlassian.
      - hinkley 6y ago
        Almost everyone is “using it incorrectly”, but it’s like the aphorism about assholes. (If you meet assholes all day long, you’re the asshole.) If your software encounters idiots all day long, you’re the idiot.

immy 6y ago

Boo to this take. Not all tools are the same and “Good tools obviate bad processes.” is a mantra I saw once in a talk that has stuck with me for 15 years. You’re not wrong that it’s a people problem, but tools shape human behavior. That’s Design. The quote is attributed to Michael B. Johnson, aka wave, Software Director at Pixar.

kevmo314 6y ago
API design is a great example of this. Good API design incentivizes the right choices and clean integration. I often argue that it's not just "oh this API matches the spec better" or "this API is lower maintenance" but rather that I've found certain APIs can almost trick developers into writing good code. It's a neat experience. That being said, there is some necessary internalization that a tool is solving a people problem which is maybe what OP is trying to get at. No matter how good an API is, if a developer is dead set on writing bad code, it'll be bad. So just deploying a new tool, no matter how clever, won't fix an organization that doesn't want to be fixed.

robotresearcher 6y ago

I'm genuinely interested: is this really true? Is Jira necessarily slow when there's a lot of stuff in it? I'm not sure I believe it. There are graph-of-objects-plus-metadata applications out there that are pretty fast. I'm not an expert in this domain, but I bet an issue tracker can be made that doesn't feel painful at real scales.

elithrar 6y ago
I didn't interpret the OP to mean slow from an "application performance" perspective - instead, as slow from a "process" perspective. The ticket needs to be filed in the right queue. It needs the "right" tags. It needs to traverse the "approved" workflow correctly. It didn't get assigned to the right epic. etc, etc, etc. It's all of that - the process built up over time, in response to organic needs - that makes things "slow" and drives such a rejection of these tools by developers and their teams. We (collectively) rarely step back and say "what process can we cut?" - only when we use a new tool do we have the chance to address that.
- dpc_pw 6y ago
  It's both. JIRA can often be terribly slow. Each page loads about 10 seconds for me, and I don't know why. Other people say it is ~2s for them. I suspect it has something to do with networking and amount of requests being made, etc. Then, on top of it the flows in Jira can be super slow, which is another story.
fredfjohnsen 6y ago
No, it is not really true. It is completely false & you are correct to question it.
jayparth 6y ago
What's your question here? The premise of the OP is that they created a fast issue tracker. People complain about Jira being slow (me being one of them.) No one has claimed that all issue trackers are slow. ClickUp, Hive, Linear, are all snappy.

enra 6y ago

Thanks for the feedback and trying it out! I do agree that lot of the process issues often reside in the organization itself. In ideal world, you don't need any kind of tracking or process. Right things just happen. However, in reality is that companies often have goals and roadmaps they have to deliver. Things move fast and teams need to know what is being worked on. We've worked in 5 and 5000 person engineering organizations and need for coordination is always there. And personally, I just need to know what I need to do next. We spent the past year talking with our our early users. New startups and even teams of very successful companies, struggle with the process. They might know how they should improve things, but it's hard to find the time or energy to actually implement it. We want to help with this. So in addition to the tool, we are developing the understanding and practices software help the team to focus and reduces some of the bad habits we might have. The tool will then help teams implement and maintain these practices going forward. We ourselves also been working with this "Linear Method" which we shared here: http://linear.app/linear-method http://linear.app/linear-method

Benjammer 6y ago

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 limits, even for backlog. But, since backlog is now the primary output of "product orgs" at many (less-than-great) companies, you now have an entire org whose jobs depend on not learning that lesson. I don't know what the answer is, but I really am starting to hate this entire "product org" concept in general. It feels like we used to be able to just engineer our way around many of these challenges ("here, look what I built last week to justify my case"), or just get people into a room and talking. But once the decision channels become explicitly siloed off into a separate org with C-Suite-level autonomy, I'm not sure how you effectively bridge the gaps that form. Any engineers who feel like having a separate product org has been a benefit to your company's product quality and delivery speed want to comment on how you see this sort of thing working effectively?

lifeisstillgood 6y ago
By product org do you mean a silo of an organisation dedicated to one particular product (so if a company has five "apps" they have five siloes and five marketing teams five engineering teams and five board members ?
- LukeShu 6y ago
  I understand it to mean that there is a part of the org (separate from the engineering team) that shapes the direction of the product; decides "these are the features we're going to implement, these are the issues we're going to address"; one way of looking at it is that their primary output is putting things in to the engineering team's backlog.
  - Benjammer 6y ago
    Yeah, this is what I was talking about. Software product management as a separate functional org from engineering. Not like old-Dupont-style product orgs.

sriram_sun 6y ago

> The problem is not the tool, it's the structure of the organization. Nicely put! Also, it's probably more like how the organization ended up evolving - something no one knew beforehand!

sriram_sun 6y ago

> The problem is not the tool, it's the structure of the organization. Nicely put! Also, it's probably more like how the organization ended up evolving - something no one knew beforehand! Newer products should start their sales pitch addressing that last sentence in OP's post.

m0xte 6y ago

Nailed it. The other problem cycle is “we’ll get JIRA right this time”. This is followed by happy clicky people immediately shafting it, at least two years of suffering and then some PM selling some new clothes to the emperor. Everything degrades this way. Even GitHub the moment someone adds workflow automation. Intent versus causality are two very different things. My favourite problem is a JIRA instance that sets a resolution as incomplete immediately on a ticket, which is a valid resolution so all my tickets are closed as far as it’s concerned. Ugh. I’m slowly working on an OSS replacement for all of this hell which is designed for inflexibility from an organisational perspective. It’ll be open source. I’m sure no one will use it because it’s inflexible.

SAI_Peregrinus 6y ago

I haven't tried Linear, but my company uses Jira. It's abysmally slow. Not "there are too many tickets and it's hard to manage" slow, just the interface is slow. I opened an issue link in a new tab. It took about 7 seconds for the page to become interactive (able to click on the issue status and get a dropdown) and about 9 seconds for the loading to complete and elements to stop jumping around. This is in Firefox 78 on a Lenovo T480 with 8th-gen Core i7 CPU. Speed.cloudflare.com reports 28.5ms latency with 38.1ms jitter, 339Mbps down. Not a generally slow setup. At least in the case of Jira the interface speed is a huge issue.

flarg 6y ago
This. Jira used to be famous for it's ease of use and fantastic cross linking between artifacts, but now it's always just very slow.
zerkten 6y ago
Is there a site that lets you run performance profiles in browser developer tools and share the results? I could imagine that being really useful internally for devs troubleshooting and working with support. It'd be harder to pull off as a way to shame poor performance because of the need to compare like with like, but I think it's needed to get the attention of folks. Accessibility checkers are often rudimentary, but they are available to non-technical folks in companies and can be very effective at getting a conversation started.
- SAI_Peregrinus 6y ago
  No clue. I'm an embedded dev, so my method for getting the numbers above was the stopwatch part of my phone's clock app. Thus the "about" qualifiers. But it's slow enough to use a damn stopwatch app manually. That technique shouldn't even enter the discussion!

mumblemumble 6y ago

It's not just speed, it's complexity. I've seen the cycle play out enough to know the real thing that drives how productive a ticketing system feels: How many distinct kinds of people are using it. The new one always seems great, because whatever team pilots it is the only team using it, so they're able to keep it nice and lean and closely adapted to their own needs. But, as soon as the decision to migrate is made, then you don't just have additional teams using it. You have additional teams wanting to use it as a communication and monitoring channel, and building up reports and metrics and dashboards on top of it, and imposing restrictions on the ticketing system that ultimately limit other groups' ability to streamline their own workflows, and by the time everyone realizes they're back on the same old pain train yet again, it's too late to do anything about it. It seems that developers are always the ones who get hit the hardest, because they end up with the largest number of outside parties who want to get involved in their business.

deleted 6y ago

[deleted]

dmix 6y ago

Is Superhuman any good for that matter? I refuse to have to talk to a sales person on the phone in order to use a mail app. Which is what their signup flow required last time I tried.

mikepurvis 6y ago

> Don't migrate your backlog, start with only a couple engineers in a new issue tracker... I experienced this in the wiki/documentation space some years ago when my org migrated from the trac wiki to Confluence. It seemed like such a boost initially, but it wasn't a boost at all, it was just the fact that for the first ~12 months after migrating, you could trust that everything you found in the wiki was freshly written and up to date (and the overall corpus was small enough that the search function actually returned useful results). The whole experience has given me the idea of making a Confluence plugin that slowly fades out each page to grey as a visual indication of its waning relevance. Anyone editing, commenting, or "liking" the page immediately freshens it again, unless they somehow indicate that the action is actually a vote against (like nofollow is for links). When a page is sufficiently abandoned, it goes on a candidate-for-deletion list, gets a warning box at the top, and is blacklisted from appearing in the default search results.

hinkley 6y ago
If it’s late afternoon and I’ve finished or am about to start a particularly challenging task, I’ll tend to take on other tasks like basic research or wiki maintenance. Essentially I treat the wiki like a B-Tree. When the landing page gets crowded, I move a bunch of related things down one level in the hierarchy, trying to retain keystone ideas within the first to levels (and letting related concepts be discoverable from those). Over time the oldest links and links of only temporary utility get pushed out to the leaf nodes, where you aren’t likely to encounter them accidentally. Really, though, we should be applying the same sort of version control we have in our source code. You should be able to track down how old a paragraph is in the wiki.
jmarcher 6y ago
https://www.getguru.com/ https://www.getguru.com/ has a so verification where each page, called cards, has an owner or group of owners and a set expiration period (1 week, 3 months, 1 year etc.). Past the expiration the page gets marked as untrusted (it's on top of each card) and require to be reviewed by the owner(s). Any user can also mark a card as untrusted, prompting a review. Every expired card owned by owner get displayed to their owners in a dedicated UI (page) and can be quickly reviewed. The editor in Guru is a bit clunky at time (worst than Confluence... if that's possible) and not really suitable for something like specs, but I have yet to find anything that actually tries to prevent wiki rot. We also evaluated Confluence with this https://marketplace.atlassian.com/apps/123/better-content-archiving-for-confluence?hosting=server&tab=overview https://marketplace.atlassian.com/apps/123/better-content-ar... but if the concept is not a first class citizen in the wiki, it does not work as well. I tried to convince the people at Clubhouse (with their Write app in beta) and Notion, but I don't think they get it.

thayne 6y ago

I think the issue with issue trackers is that every organization has it's own way of tracking issues. So issue trackers often try to do everything for everyone, and end up being at most mediocre for most users.

deleted 6y ago

[deleted]

divbzero 6y ago

> 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 piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better! Sluggish software can be more than just a data bloat issue. It can also be caused feature bloat, or software architecture that scales poorly. Anecdotally, I recently worked on a project using a fresh Jira Cloud account. It was still slow.

noir_lord 6y ago
Jira is so slow I installed plugins in both the devtools I use a lot to view tickets without having to use the web interface, it's just painful when you have to view a lot of tickets quickly.
kschrader 6y ago
We do a lot of work at Clubhouse to keep things fast. We have alerts set up that fire if the p50 or p95 of certain actions spike and we treat it as a bug if things are headed in the wrong direction. We still see a lot of random cases of things being slower though (shakes fist at random browser plugin upgrades). It's a hard problems, but if you don't design (and monitor) for this from the beginning things are going to slow down over time as you scale to hundreds of thousands of users.

littlestymaar 6y ago

> New issue trackers feel faster for the same reason switching browsers tends to feel faster It's not necessary about faster process, but Jira is agonizingly slow: each click triggers a cascade of HTTP requests in a synchronous way and it literally takes seconds every time you want to do something. Everytime I have to touch it, I feel angry for the next hour just because of the induced frustration. Any tool more responsive would be an improvement for me.

lonelyasacloud 6y ago

"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." Imagine what would happen if everyone in an organisation had to use the same tool for text and code editing, say for some reason the PhB inflicted Word on the organisation as the only allowed code editor. Would that be good? From my pov, most of the churn with ticket trackers is down to current solutions trying to own everything and apply a one size fits all model to everyone in the enterprise. The upshot being that the ticket trackers are invariably a sh*tty compromise for many/most individuals in the organisation. Think about the number of slides and reports that are hand generated for progress meetings in an enterprises. What about all of the various todo apps and systems people use? Why would so much effort be expended if the enterprise ticket tracking system was meeting requirements? Fixing the problem requires using systems based on common standards that allow _individuals_ to use what works best for them but still interoperates freely with each other. fwiw, another shiney issue tracker will not do that unless its basic unit of tracking is something akin to a text file that can be shared with the next shiney issue tracker.

fmajid 6y ago

It's the same with communications tools. "Our email is an INBOX-trillion mess because we use unstructured email rather than structured tickets to manage our processes. Slack is the answer!". Six months later, they have the exact same problem with Slack because the communications patterns haven't changed. That said, some tools are really just abysmal, and richly deserve the hate directed at them.