10 ms·

I don't understand the negativity in this thread. Or why people are using this post as an impetus to (ostensibly) move to gitlab. Or lament the decline and fall

by memset 8y ago

I don't understand the negativity in this thread. Or why people are using this post as an impetus to (ostensibly) move to gitlab. Or lament the decline and fall of github. Nobody is forcing anyone to use Jira. Nobody is forcing anyone to use Github. You can continue to use both without adopting any of the UX or design or workflows or whatever of the other. This blog post is just saying "now we have an officially-supported integration that we believe works better than the previous and here are some new features." Am I missing something here? Otherwise, congrats to the github team for shipping this! I've used github+jira integrations in the past, and if this is an improvement, then cheers to making things easier for folks who use both tools as part of their day-to-day!

kasey_junk 8y ago
It’s a sign of how bad JIRA is. The tool is so bad that people (including me) want the integrations to be hard simply to have a reason not to use it.
- zuern 8y ago
  Just curious, what do you think is so bad about Jira? I think it's miles ahead of other tools like Rally for example. What's your preference?
  - smokeyj 8y ago
    People who hate JIRA never had to manage other developers or coordinate work across teams. It's not a product that anyone loves but what the heck are you expecting?
    - jfoutz 8y ago
      With a pure jira approach, I would expect engineers to do what they think is best in the moment, and log something that vaguely matches the requirements laid out in the ticket. Essentially ineffective management of developer time.
    - deleted 8y ago
      [deleted]
    - sidlls 8y ago
      I manage developers and coordinate work across teams. Can't stand JIRA. I'm not expecting much. For one this is a space that many engineers sneer at ("product/sales/marketing/not-engineering" is beneath them) and don't really want to work in. Another thing is that many of the individuals responsible for deciding on project management tools are not qualified to do so but think they are and won't apply effort to doing a proper job of evaluating options.
  - kasey_junk 8y ago
    JIRA in its out of the box configuration is an adequate issue tracker. Thats never the problem. The problem falls into a few broad categories: - conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new products is fundamentally different than dealing with customer service items. Just as a specific, issues in JIRA are a terrible way to capture the vision and mission of a new feature. They are further a terrible way to capture requirements which in any other system would be versioned along with the software they define. - the customization of workflows encourages teams to think of every component as a fungible unit. If you don't define 'workflows' and instead prioritize around results, you can motivate teams to operate in their best ways. If you build complicated or bespoke workflows in JIRA you operate in a way that presumes that all teams and all situations can be put in the same box. - JIRA, especially in its most customized versions, implies that you can replace normal human communications, conversations, emails, chats, with a Platonic ideal of tickets. Yet tickets are a bad mechanism for spreading big picture ideals and an even worse mechanism for spreading specific details of a functional specification (no testability, no atomicity with software change, etc). - JIRA's customizability leads people to think that the right thing to do with their project management teams is to define standardized workflows, automated integrations, normalized schemas for issues, and the like. Instead of doing the hard work of aligning priorities Project Managers get caught up in the minutia of making sure tickets are in the proper form or that developers have moved tickets through the correct statuses. All told, this is one of those cases where worse is better. A title, a comment box and a set of tags largely allow you to systematically capture everything you need to capture and allow a qualified project manager to do their job. Github issues does this, JIRA out of the box does this, Bugzilla and FogBugz all do this. I only ever run into problems with JIRA, so I can only extrapolate from experience that it is something about JIRA that leads Project Managers to spend less time with legal pads and more times futzing with JIRA.
    - chii 8y ago
      all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it. Jira gets the flac, because but the problems isn't Jira.
  - paulddraper 8y ago
    JIRA Core is a good issue tracker. However JIRA Agile is a dumpster fire, partly because JIRA Agile reinvents JIRA. Summary field? Yes, but also "Epic Name" field. Status field? Yes, but also "Epic Status" field. Priority field? Yes, but also "Rank" field. Subissues? Yes, but also "Epic Link" field. And then boards and sprints are weird. Boards are supposed to be just views, but then access permissions for closing sprints depends on the view you were looking at when you created it. Plus the UI bad; the whole board gets really squished and becomes essentially unusable if I half-screen it.
    - TheGRS 8y ago
      My main gripe about JIRA, other than how abysmal it gets when you add a slew of custom fields and workflows all over the place, is that I can't sort on the boards based on all of these fields I've setup. I set priority and severity on every issue, yet I can't sort by those fields in the planner or board, that's infuriating to me.
      - seanjregan 8y ago
        Check out Jira cloud, you can filter with a single click in the Next-gen UI by issue ower, epic, or label, no JQL required.
        TheGRS 8y ago
        Not talking about the search or search results, talking about the Active Sprint board and Backlog.
    - p2t2p 8y ago
      I'll tell you a secret, there are no "subissues", there are only issue links and UI represents different kind of links differently ;-).
      - Cogito 8y ago
        Subtask issuetypes are a real thing, and are different to issue links. Different parts of the UI and some functionality works differently for subtasks than for linked issues. For example, you can set it up so that you can't close a 'user story' until all subtasks under it have been closed. Not possible out of the box with linked issues.
  - keithnz 8y ago
    I like YouTrack
  - leetcrew 8y ago
    yesterday i tried to drag/drop a single profile trace file to upload to a bug report. somehow JIRA uploaded it as ~100 different files, which i had to delete one by one, since JIRA doesn't have batch deletion for attachments. every single deletion sent out an email to everyone who was following the bug, which means i dumped 100 emails on five different people.
  - dyeje 8y ago
    That's not saying much. Rally is probably the most overpriced, awful tracking software out there. I prefer Pivotal Tracker personally.
    - mgoblu3 8y ago
      As someone who works at a place that just moved from Pivotal Tracker to Rally.... you're opening up some wounds :(
- bicubic 8y ago
  I think it's less a sign of how bad JIRA is, and more how bad project management and project managers are in software development. JIRA can be a decent tool. The issue is the way that 90% of all businesses big and small use it, is just so that managers can shrug off any responsibility for understanding the projects they're managing, and wall themselves off in JIRA bureaucracy. Engineers have not taken too kindly to it.
  - fnord123 8y ago
    How can it be a decent tool if any operation takes . . . . forever
    - subpixel 8y ago
      Exactly. Jira is horrible developer experience and it occupies a space in the developer workflow where it can create a feeling that the whole project or organization is off the rails.
  - dominotw 8y ago
    I've never seen a JIRA installation that isn't slow as hell. Project Manager types dont mind JIRA slowness for some reason. Prbly have too much time in their meetings to sit and wait around.
    - nojvek 8y ago
      JIRA is slooooooooooow. I don’t think any fancy integration can fix that slowness if their APIs are just snail slow. On the other hand JIRA UX and moreso Atlassian UX needs a lot of work. A number of common things take wayyyy too many clicks. It’s hard to discover etc. A good integration can definitely fix that mess. GitHub knows how to do good simple UX.
    - ascagnel_ 8y ago
      If you think JIRA is slow, you should check out tools like HP Quality Center. That thing was such a piece of garbage the last time I had it foisted on me (2015), it: - made JIRA look fast - only ran in IE6 - required a special MSIE shell to run in Win7 - despite running only in IE6/Windows, it had several places where it broke from the standard Windows UX
- braythwayt 8y ago
  I gently suggest that you examine this thinking, hard. You obviously don’t believe that you have a choice in the matter today. But you also seem to have a helpless belief that you won’t have a choice in the matter tomorrow, nor do you seem to believe there are things you can do to have a choice tomorrow. So instead, you are wishing that something else would force the universe to give you what you want, but without you actually changing your circumstances such that you can freely choose not to use JIRA tomorrow. I urge you to shift your thinking and make it your business to recognize that you actually do have a choice today. You can work somewhere else. That has some costs you may not care for, but it’s healthy to say, “Overall, I like the choice I’m making” and then to be happy with the outcome. Next, I urge you to believe that you can make choices today that give you even greater freedom to choose not to use Jira tomorrow without making difficult tradeoffs. When you have greater confidence in your own freedom of choice in these matters, you will be happier today and tomorrow, and you will let go of wishing that other forces will act to give you what you want in life. Summary: Working on your own agency is far, far better for you personally than hoping that the universe will conspire to make other people stop choosing to ask you to use Jira.
  - Spivak 8y ago
    This is all well and good but I don't think the thinking is wrong, Jira is built and sold to managers who have the authority to impose it on their engineers, (typically dumping a lot of management responsibility onto the engineers in the process but that's a different issue). There's really not much you can do in a lot of orgs except hope that Jira starts to stagnate and rot. So I understand the frustration when someone from the engineering side builds something for it -- "why, oh god why are you trying to extend its life?!?"
    - braythwayt 8y ago
      Nope, nope, nope. If Jira didn’t exist, someone would build it, because said managers have the budget and authority to spend. If we want a different management culture, we have to work on the culture directly. Which is the entire point of agile, lean, and other movements. As for managers buying it and imposing it on their engineers, we need to recognize that said managers are users too, and their needs matter. It’s not like there’s a good tool and a shitty tool, and the engineers and managers put in a requisition for the good tool, but the CFO plays golf with the shitty tool’s VP of Sales and they buy the shitty tool. Managers want Jira for a reason. We may not like the reason, but that doesn’t mean they’re wrong, and it especially doesn’t mean that if we burned Jira down to the ground its replacement wouldn’t address the reasons managers want Jira. If we believe that software can do what managers and engineers need doing without being as craptastic as Jira, we need to build it. But we can’t ignore what managers need. We either give them something else that solves their problem, or we stop worrying about Jira and get them to approach software development in a new way.
- celticninja 8y ago
  Yeah I'm avoiding telling any of my managers a out this new development, I like gitub and I don't need Jira fucking it up.
bpchaps 8y ago
It's because many of us have worked at companies that use JIRA extensively. It's a tool that marks the sign that a company cares more about the management of staff as units, instead of caring about employees as breathing and creative forces. It makes management's job easier, but it does nothing for the managed, except lead to frustration and hundreds of emails that have to be waded through for that 5% chance of relevancy. Their integration seems particularly targeted to JIRA, when they've lapsed on many other useful features and improved UX implementations. It reflects GH's priorities as a company. It's a sign that github is catering to management over the programmer. Contrast that to gitlab, whose implementations are designed to make the programmer's job easier.
- babyjoeyjump 8y ago
  > It's a sign that github is catering to management over the programmer. Contrast that to gitlab, which is going the route of making the programmer's job easier. wat?
- kasey_junk 8y ago
  The worst part is there is no evidence it makes managements job easier. The saying is JIRA is yo project management what PowerPoint is to public speaking. For people who are good it can marginally improve the output but for most people it’s an easy way to wank away your time convincing yourself you are working on the right thing as you ignore the real issues.
  - Aeolun 8y ago
    Nobody ever got fired for picking Jira
  - Rapzid 8y ago
    > easy way to wank away your time convincing yourself you are working on the right thing as you ignore the real issues. Replace "yourself" with "others" and you have the answer as to how Jira makes managements life easier ;)
  - drb91 8y ago
_hardwaregeek 8y ago
> Nobody is forcing anyone to use Jira. Nobody is forcing anyone to use Github. I agree that the negativity doesn't seem warranted, but plenty of people are being forced to use Jira or GitHub in their daily routines.
- derefr 8y ago
  I think in this text a corporation is being modelled as a single being with a single decision-making capacity. Sort of like how "my brain" forces spicy food on "my intestines", but when you model the two things together as a single human being, then you can confidently state that nobody is forcing me to eat spicy food. Really, all the GP is trying to say is that neither Github nor Jira has any external market forces colluding to push those products onto "software-buying entities" (like individual freelancers, or whole corporations) that don't want to use them. They're just products, in the market, with freely-available alternatives, and any entity who would normally have the power to choose which software to buy, isn't having that decision made for them by market-distorting forces. There's no Github or Jira monopoly that has come along and crushed the alternatives out of existence, such that they're the only options even if you, a software-buying entity, wanted to buy an alternative.
  - memset 8y ago
    Haha, thank you for this! You must forgive me ("the GP") for being bemused by the textual analysis you have written in defense of my comment!
- sneak 8y ago
  That’s not what “forced” means. There are plenty of other jobs, especially for the kinds of people who find Jira in their workflows.
  - oblio 8y ago
    As long as you're located in or can move to the right places.
  - lmm 8y ago
setquk 8y ago
Really it’s the cynical engineers, me included, being skeptical about an unholy alliance of two tools known for their occasional slinging of hand grenades into the workflow. In fact both tools effectively compromise the underlying concepts they encapsulate. GitHub for example ties you to a very centralised model. The moment there’s a github problem, the whole “post push” workflow falls to its knees. Forget CI, PRs, everything. It’s down or working incorrectly or inconsistently until github find the poo and shovel it. When your old self served SVN server had downtime measured in seconds in a year and your build infrastructure was several orders of magnitude more reliable. Genuinely, it’s worse and needs more humans to keep it ticking on medium sized teams. That’s less humans on adding business value. JIRA itself is an interesting tool. The tool itself has its own problems (abysmal performance mainly) but the main problem is that it has a propensity to be configured by people who don’t know or understand it. That results in many staff effectively running around in a hamster wheel every time they have to do something trivial. These two together multiply and you end up with thousands of hours of developer time thrown out of the window. This is seen as the status quo of development but it doesn’t need to be. We need better more reliable tools, not better integrations between pits of despair. Also we need a firm stick to beat the workflows into shape.
singingfish 8y ago
My work forces me to use Jira. It could be worse (and it has been better), but it's not great. What gitlab really has going for it is the really really useful CI decently integrated with git. If that's your primary conern then the fact that it gives you a reasonable wiki, issue tracker and other stuff on top is just well-enough prepared icing.
- dsumenkovic 8y ago
  Hello, Community Advocate from GitLab here. Thanks for mentioning our CI and other features. Since we always care about transparency, everyone can read more about it here https://about.gitlab.com/features/gitlab-ci-cd/ https://about.gitlab.com/features/gitlab-ci-cd/. Also to mention the documentation where you can read about the first steps towards your GitLab CI/CD journey https://docs.gitlab.com/ee/ci/ https://docs.gitlab.com/ee/ci/
joeblau 8y ago
There are a lot of engineers on HackerNews who have had terrible experiences with Jira (I'm one of them). You're correct, you don't have to migrate; However, if you work at a company where management all of a sudden realizes — "oh now we can integrate Jira for our tasks". It's a slippery slope down the Jira road. I've had 3 jobs where we used Jira and it was always a nightmare. At Uber ATG it sucked because it was slow, extremely confusing, managers didn't know how to use it, engineers didn't either, it wasn't integrated into any developer tooling, and there was no dedicated Jira engineer so it just slowly wasted away. At Amazon, same story as Uber ATG, but we had a dedicated engineer, yet somehow it was still slow. At this startup called Attensity, it was the exact same story as Uber. I've seen Jira work for other things that aren't software engineering related, where it seems like tolerances for crappy software are higher. We use Jira for creating tickets for new computers or requesting access to certain recourses. Those things are fine because they aren't really sprint related — it's more like a fancy to-do system with time stamps. However, if you're on the building and landing software train — nobody want's to hear the word Jira.
- sigi45 8y ago
  What? I have used and i'm using jira for probably 7 years in 3 different companies with 6 different projects. I always took care of our workflow and small issues by the side. Once configured properly (which has nothing do to with magic) it works as advertised. there are a few small issues but not that relevant in daily life. We used atlassian online service and on premise.
  - joeblau 8y ago
    I would love to meet you and introduce you to any manager I have in the future (because I"m sure Jira will be reintroduced in my professional career). What were you using Jira for? Are you an engineer committing code daily? What style do your projects usually follow (waterfall, agile, etc)? What source control tracking do you use with Jira? Were you doing burndown charts?
    - sigi45 8y ago
seanjregan 8y ago
The irony here is that this integration addresses the heart of the complaints in this thread. People don't want to have to update whatever project management team their management uses. Good News! That's why this integration exists. 1. This integration lets developers work on their code while automatically sending updates Jira so they don't have to. 2. When you create a commit, it can automatically transition a Jira issue so you don't have to go to Jira to do it. 3. Use smart commits to update the status in Jira, leave a comment, or log time without leaving your command line or GitHub. 4. When you create a branch in BB or GH it will automatically transition the issue in Jira so you don't have to. 5. When you merge a pull request in GH and BB it will automatically transition the issue in Jira so you don't have to. 6. Linking Jira Software to GitHub lets you see branches, commits, and pull requests right on the Jira issue. 7. Now everyone, even those pesky managers and program managers can see the status of work without asking you to take your headphones off, “bumping” their email in your inbox of “pinging” you for the 10th time in Slack. They can see your status right from the board without even clicking into the issue. 8. Search for Jira issues based on related GitHub information, such as open pull requests. https://www.atlassian.com/blog/jira-software/github-for-jira https://www.atlassian.com/blog/jira-software/github-for-jira
sh87 8y ago
I think the negativity becomes easier to understand if you put it this way. GitHub earned trust from enterprise and open source community alike. Stable, robust, secure and reliable. Competitors try hard but they're not even close. Everyone's happy. One day, they announce, they are bought up by a rich, notoriously closed source software behemoth that was once sued for its monopolistic tactics. It claims its now a changed company wanting to empower developers to build the future and the only way they can do that is by buying GitHub and promises to do their best work to empower every developer to build, innovate and solve the world’s most pressing challenges. 4 months down, they declare they've built a close integration with a proprietary, overpriced issue tracking tool that is described as slow, terrible, unproductive, confusing and an utter nightmare by its users. See it now ?

by memset 8y ago

kasey_junk 8y ago

It’s a sign of how bad JIRA is. The tool is so bad that people (including me) want the integrations to be hard simply to have a reason not to use it.

zuern 8y ago
Just curious, what do you think is so bad about Jira? I think it's miles ahead of other tools like Rally for example. What's your preference?
- smokeyj 8y ago
  People who hate JIRA never had to manage other developers or coordinate work across teams. It's not a product that anyone loves but what the heck are you expecting?
  - jfoutz 8y ago
    With a pure jira approach, I would expect engineers to do what they think is best in the moment, and log something that vaguely matches the requirements laid out in the ticket. Essentially ineffective management of developer time.
  - deleted 8y ago
    [deleted]
  - sidlls 8y ago
    I manage developers and coordinate work across teams. Can't stand JIRA. I'm not expecting much. For one this is a space that many engineers sneer at ("product/sales/marketing/not-engineering" is beneath them) and don't really want to work in. Another thing is that many of the individuals responsible for deciding on project management tools are not qualified to do so but think they are and won't apply effort to doing a proper job of evaluating options.
- kasey_junk 8y ago
  JIRA in its out of the box configuration is an adequate issue tracker. Thats never the problem. The problem falls into a few broad categories: - conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new products is fundamentally different than dealing with customer service items. Just as a specific, issues in JIRA are a terrible way to capture the vision and mission of a new feature. They are further a terrible way to capture requirements which in any other system would be versioned along with the software they define. - the customization of workflows encourages teams to think of every component as a fungible unit. If you don't define 'workflows' and instead prioritize around results, you can motivate teams to operate in their best ways. If you build complicated or bespoke workflows in JIRA you operate in a way that presumes that all teams and all situations can be put in the same box. - JIRA, especially in its most customized versions, implies that you can replace normal human communications, conversations, emails, chats, with a Platonic ideal of tickets. Yet tickets are a bad mechanism for spreading big picture ideals and an even worse mechanism for spreading specific details of a functional specification (no testability, no atomicity with software change, etc). - JIRA's customizability leads people to think that the right thing to do with their project management teams is to define standardized workflows, automated integrations, normalized schemas for issues, and the like. Instead of doing the hard work of aligning priorities Project Managers get caught up in the minutia of making sure tickets are in the proper form or that developers have moved tickets through the correct statuses. All told, this is one of those cases where worse is better. A title, a comment box and a set of tags largely allow you to systematically capture everything you need to capture and allow a qualified project manager to do their job. Github issues does this, JIRA out of the box does this, Bugzilla and FogBugz all do this. I only ever run into problems with JIRA, so I can only extrapolate from experience that it is something about JIRA that leads Project Managers to spend less time with legal pads and more times futzing with JIRA.
  - chii 8y ago
    all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it. Jira gets the flac, because but the problems isn't Jira.
- paulddraper 8y ago
  JIRA Core is a good issue tracker. However JIRA Agile is a dumpster fire, partly because JIRA Agile reinvents JIRA. Summary field? Yes, but also "Epic Name" field. Status field? Yes, but also "Epic Status" field. Priority field? Yes, but also "Rank" field. Subissues? Yes, but also "Epic Link" field. And then boards and sprints are weird. Boards are supposed to be just views, but then access permissions for closing sprints depends on the view you were looking at when you created it. Plus the UI bad; the whole board gets really squished and becomes essentially unusable if I half-screen it.
  - TheGRS 8y ago
    My main gripe about JIRA, other than how abysmal it gets when you add a slew of custom fields and workflows all over the place, is that I can't sort on the boards based on all of these fields I've setup. I set priority and severity on every issue, yet I can't sort by those fields in the planner or board, that's infuriating to me.
    - seanjregan 8y ago
      Check out Jira cloud, you can filter with a single click in the Next-gen UI by issue ower, epic, or label, no JQL required.
      - TheGRS 8y ago
        Not talking about the search or search results, talking about the Active Sprint board and Backlog.
  - p2t2p 8y ago
    I'll tell you a secret, there are no "subissues", there are only issue links and UI represents different kind of links differently ;-).
    - Cogito 8y ago
      Subtask issuetypes are a real thing, and are different to issue links. Different parts of the UI and some functionality works differently for subtasks than for linked issues. For example, you can set it up so that you can't close a 'user story' until all subtasks under it have been closed. Not possible out of the box with linked issues.
- keithnz 8y ago
  I like YouTrack
- leetcrew 8y ago
  yesterday i tried to drag/drop a single profile trace file to upload to a bug report. somehow JIRA uploaded it as ~100 different files, which i had to delete one by one, since JIRA doesn't have batch deletion for attachments. every single deletion sent out an email to everyone who was following the bug, which means i dumped 100 emails on five different people.
- dyeje 8y ago
  That's not saying much. Rally is probably the most overpriced, awful tracking software out there. I prefer Pivotal Tracker personally.
  - mgoblu3 8y ago
    As someone who works at a place that just moved from Pivotal Tracker to Rally.... you're opening up some wounds :(
bicubic 8y ago
I think it's less a sign of how bad JIRA is, and more how bad project management and project managers are in software development. JIRA can be a decent tool. The issue is the way that 90% of all businesses big and small use it, is just so that managers can shrug off any responsibility for understanding the projects they're managing, and wall themselves off in JIRA bureaucracy. Engineers have not taken too kindly to it.
- fnord123 8y ago
  How can it be a decent tool if any operation takes . . . . forever
  - subpixel 8y ago
    Exactly. Jira is horrible developer experience and it occupies a space in the developer workflow where it can create a feeling that the whole project or organization is off the rails.
- dominotw 8y ago
  I've never seen a JIRA installation that isn't slow as hell. Project Manager types dont mind JIRA slowness for some reason. Prbly have too much time in their meetings to sit and wait around.
  - nojvek 8y ago
    JIRA is slooooooooooow. I don’t think any fancy integration can fix that slowness if their APIs are just snail slow. On the other hand JIRA UX and moreso Atlassian UX needs a lot of work. A number of common things take wayyyy too many clicks. It’s hard to discover etc. A good integration can definitely fix that mess. GitHub knows how to do good simple UX.
  - ascagnel_ 8y ago
    If you think JIRA is slow, you should check out tools like HP Quality Center. That thing was such a piece of garbage the last time I had it foisted on me (2015), it: - made JIRA look fast - only ran in IE6 - required a special MSIE shell to run in Win7 - despite running only in IE6/Windows, it had several places where it broke from the standard Windows UX
braythwayt 8y ago
I gently suggest that you examine this thinking, hard. You obviously don’t believe that you have a choice in the matter today. But you also seem to have a helpless belief that you won’t have a choice in the matter tomorrow, nor do you seem to believe there are things you can do to have a choice tomorrow. So instead, you are wishing that something else would force the universe to give you what you want, but without you actually changing your circumstances such that you can freely choose not to use JIRA tomorrow. I urge you to shift your thinking and make it your business to recognize that you actually do have a choice today. You can work somewhere else. That has some costs you may not care for, but it’s healthy to say, “Overall, I like the choice I’m making” and then to be happy with the outcome. Next, I urge you to believe that you can make choices today that give you even greater freedom to choose not to use Jira tomorrow without making difficult tradeoffs. When you have greater confidence in your own freedom of choice in these matters, you will be happier today and tomorrow, and you will let go of wishing that other forces will act to give you what you want in life. Summary: Working on your own agency is far, far better for you personally than hoping that the universe will conspire to make other people stop choosing to ask you to use Jira.
- Spivak 8y ago
  This is all well and good but I don't think the thinking is wrong, Jira is built and sold to managers who have the authority to impose it on their engineers, (typically dumping a lot of management responsibility onto the engineers in the process but that's a different issue). There's really not much you can do in a lot of orgs except hope that Jira starts to stagnate and rot. So I understand the frustration when someone from the engineering side builds something for it -- "why, oh god why are you trying to extend its life?!?"
  - braythwayt 8y ago
    Nope, nope, nope. If Jira didn’t exist, someone would build it, because said managers have the budget and authority to spend. If we want a different management culture, we have to work on the culture directly. Which is the entire point of agile, lean, and other movements. As for managers buying it and imposing it on their engineers, we need to recognize that said managers are users too, and their needs matter. It’s not like there’s a good tool and a shitty tool, and the engineers and managers put in a requisition for the good tool, but the CFO plays golf with the shitty tool’s VP of Sales and they buy the shitty tool. Managers want Jira for a reason. We may not like the reason, but that doesn’t mean they’re wrong, and it especially doesn’t mean that if we burned Jira down to the ground its replacement wouldn’t address the reasons managers want Jira. If we believe that software can do what managers and engineers need doing without being as craptastic as Jira, we need to build it. But we can’t ignore what managers need. We either give them something else that solves their problem, or we stop worrying about Jira and get them to approach software development in a new way.
celticninja 8y ago
Yeah I'm avoiding telling any of my managers a out this new development, I like gitub and I don't need Jira fucking it up.

bpchaps 8y ago

It's because many of us have worked at companies that use JIRA extensively. It's a tool that marks the sign that a company cares more about the management of staff as units, instead of caring about employees as breathing and creative forces. It makes management's job easier, but it does nothing for the managed, except lead to frustration and hundreds of emails that have to be waded through for that 5% chance of relevancy. Their integration seems particularly targeted to JIRA, when they've lapsed on many other useful features and improved UX implementations. It reflects GH's priorities as a company. It's a sign that github is catering to management over the programmer. Contrast that to gitlab, whose implementations are designed to make the programmer's job easier.

babyjoeyjump 8y ago
> It's a sign that github is catering to management over the programmer. Contrast that to gitlab, which is going the route of making the programmer's job easier. wat?
kasey_junk 8y ago
The worst part is there is no evidence it makes managements job easier. The saying is JIRA is yo project management what PowerPoint is to public speaking. For people who are good it can marginally improve the output but for most people it’s an easy way to wank away your time convincing yourself you are working on the right thing as you ignore the real issues.
- Aeolun 8y ago
  Nobody ever got fired for picking Jira
- Rapzid 8y ago
  > easy way to wank away your time convincing yourself you are working on the right thing as you ignore the real issues. Replace "yourself" with "others" and you have the answer as to how Jira makes managements life easier ;)
- drb91 8y ago

_hardwaregeek 8y ago

> Nobody is forcing anyone to use Jira. Nobody is forcing anyone to use Github. I agree that the negativity doesn't seem warranted, but plenty of people are being forced to use Jira or GitHub in their daily routines.

derefr 8y ago
I think in this text a corporation is being modelled as a single being with a single decision-making capacity. Sort of like how "my brain" forces spicy food on "my intestines", but when you model the two things together as a single human being, then you can confidently state that nobody is forcing me to eat spicy food. Really, all the GP is trying to say is that neither Github nor Jira has any external market forces colluding to push those products onto "software-buying entities" (like individual freelancers, or whole corporations) that don't want to use them. They're just products, in the market, with freely-available alternatives, and any entity who would normally have the power to choose which software to buy, isn't having that decision made for them by market-distorting forces. There's no Github or Jira monopoly that has come along and crushed the alternatives out of existence, such that they're the only options even if you, a software-buying entity, wanted to buy an alternative.
- memset 8y ago
  Haha, thank you for this! You must forgive me ("the GP") for being bemused by the textual analysis you have written in defense of my comment!
sneak 8y ago
That’s not what “forced” means. There are plenty of other jobs, especially for the kinds of people who find Jira in their workflows.
- oblio 8y ago
  As long as you're located in or can move to the right places.
- lmm 8y ago

setquk 8y ago

Really it’s the cynical engineers, me included, being skeptical about an unholy alliance of two tools known for their occasional slinging of hand grenades into the workflow. In fact both tools effectively compromise the underlying concepts they encapsulate. GitHub for example ties you to a very centralised model. The moment there’s a github problem, the whole “post push” workflow falls to its knees. Forget CI, PRs, everything. It’s down or working incorrectly or inconsistently until github find the poo and shovel it. When your old self served SVN server had downtime measured in seconds in a year and your build infrastructure was several orders of magnitude more reliable. Genuinely, it’s worse and needs more humans to keep it ticking on medium sized teams. That’s less humans on adding business value. JIRA itself is an interesting tool. The tool itself has its own problems (abysmal performance mainly) but the main problem is that it has a propensity to be configured by people who don’t know or understand it. That results in many staff effectively running around in a hamster wheel every time they have to do something trivial. These two together multiply and you end up with thousands of hours of developer time thrown out of the window. This is seen as the status quo of development but it doesn’t need to be. We need better more reliable tools, not better integrations between pits of despair. Also we need a firm stick to beat the workflows into shape.

singingfish 8y ago

My work forces me to use Jira. It could be worse (and it has been better), but it's not great. What gitlab really has going for it is the really really useful CI decently integrated with git. If that's your primary conern then the fact that it gives you a reasonable wiki, issue tracker and other stuff on top is just well-enough prepared icing.

dsumenkovic 8y ago
Hello, Community Advocate from GitLab here. Thanks for mentioning our CI and other features. Since we always care about transparency, everyone can read more about it here https://about.gitlab.com/features/gitlab-ci-cd/ https://about.gitlab.com/features/gitlab-ci-cd/. Also to mention the documentation where you can read about the first steps towards your GitLab CI/CD journey https://docs.gitlab.com/ee/ci/ https://docs.gitlab.com/ee/ci/

joeblau 8y ago

There are a lot of engineers on HackerNews who have had terrible experiences with Jira (I'm one of them). You're correct, you don't have to migrate; However, if you work at a company where management all of a sudden realizes — "oh now we can integrate Jira for our tasks". It's a slippery slope down the Jira road. I've had 3 jobs where we used Jira and it was always a nightmare. At Uber ATG it sucked because it was slow, extremely confusing, managers didn't know how to use it, engineers didn't either, it wasn't integrated into any developer tooling, and there was no dedicated Jira engineer so it just slowly wasted away. At Amazon, same story as Uber ATG, but we had a dedicated engineer, yet somehow it was still slow. At this startup called Attensity, it was the exact same story as Uber. I've seen Jira work for other things that aren't software engineering related, where it seems like tolerances for crappy software are higher. We use Jira for creating tickets for new computers or requesting access to certain recourses. Those things are fine because they aren't really sprint related — it's more like a fancy to-do system with time stamps. However, if you're on the building and landing software train — nobody want's to hear the word Jira.

sigi45 8y ago
What? I have used and i'm using jira for probably 7 years in 3 different companies with 6 different projects. I always took care of our workflow and small issues by the side. Once configured properly (which has nothing do to with magic) it works as advertised. there are a few small issues but not that relevant in daily life. We used atlassian online service and on premise.
- joeblau 8y ago
  I would love to meet you and introduce you to any manager I have in the future (because I"m sure Jira will be reintroduced in my professional career). What were you using Jira for? Are you an engineer committing code daily? What style do your projects usually follow (waterfall, agile, etc)? What source control tracking do you use with Jira? Were you doing burndown charts?
  - sigi45 8y ago

seanjregan 8y ago

The irony here is that this integration addresses the heart of the complaints in this thread. People don't want to have to update whatever project management team their management uses. Good News! That's why this integration exists. 1. This integration lets developers work on their code while automatically sending updates Jira so they don't have to. 2. When you create a commit, it can automatically transition a Jira issue so you don't have to go to Jira to do it. 3. Use smart commits to update the status in Jira, leave a comment, or log time without leaving your command line or GitHub. 4. When you create a branch in BB or GH it will automatically transition the issue in Jira so you don't have to. 5. When you merge a pull request in GH and BB it will automatically transition the issue in Jira so you don't have to. 6. Linking Jira Software to GitHub lets you see branches, commits, and pull requests right on the Jira issue. 7. Now everyone, even those pesky managers and program managers can see the status of work without asking you to take your headphones off, “bumping” their email in your inbox of “pinging” you for the 10th time in Slack. They can see your status right from the board without even clicking into the issue. 8. Search for Jira issues based on related GitHub information, such as open pull requests. https://www.atlassian.com/blog/jira-software/github-for-jira https://www.atlassian.com/blog/jira-software/github-for-jira

sh87 8y ago

I think the negativity becomes easier to understand if you put it this way. GitHub earned trust from enterprise and open source community alike. Stable, robust, secure and reliable. Competitors try hard but they're not even close. Everyone's happy. One day, they announce, they are bought up by a rich, notoriously closed source software behemoth that was once sued for its monopolistic tactics. It claims its now a changed company wanting to empower developers to build the future and the only way they can do that is by buying GitHub and promises to do their best work to empower every developer to build, innovate and solve the world’s most pressing challenges. 4 months down, they declare they've built a close integration with a proprietary, overpriced issue tracking tool that is described as slow, terrible, unproductive, confusing and an utter nightmare by its users. See it now ?