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!
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.
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?!?"
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.
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.
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
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.
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.
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.
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.
> Jira gets the flac, because but the problems isn't Jira.
I recently had somebody come up and tell me: "I can't get a grasp of the status of the sprint because of Jira."
The issue, in stead was that people were creating epics all over the place and nobody ever updated their stories. So there was no clear structure and the burndown never burned down. I've worked with Jira for a long time and I can, almost, always adapt it to fit a process. However, when nobody knows that the process is, it's impossible to create a good version in Jira, but Jira ends up getting the blame.
JIRA makes it dangerously easy to implement overly bureaucratic processes. A certain kind of organization is drawn to it for that reason. Even a healthy organization switching to JIRA can get carried away with the tools now at its disposal.
JIRA is a software product but also a social institution, an organizational philosophy. Sure, you can have the software without the attitude or vice versa, but use of JIRA is still a (weak) negative signal about the quality of an employer.
Turns out that the main thing protecting employee autonomy is the logistical difficulty of micromanagement. JIRA "solves" that problem.
So your argument is that JIRA is too good and gives the user too much freedom to do what they want? Software is a tool, it is there to do what the user wants, a good tool does not limit the user. Organizational processes are just that, those selected by the org.
JIRA is successful because it is a good tool that gives power to the users. Anyone is free to build a competitor to JIRA, but I would argue that if the developer limits it and forces the client to use their preferred process methodology that they will likely fail.
Just my opinion. I have only been using JIRA for a few weeks now, have had no issues. Nothing amazing about it and nothing terrible. It does the job. Its just a tool. How its used is up to the user.
“The user” is not a monolithic entity. JIRA transfers power from labor to management. Obviously a certain kind of management loves that, but as a worker, it’s in your interest to stay away.
Of course you can use JIRA as just a tool, but it tends to take on a life of its own, becoming central to his work is allocated and performance is assessed.
I agree. One of my previous companies used Jira and it was absolutely fantastic because one project manager had a clear vision for it and implemented it and the other PMs planned sprints inside it.
Yep! I switched to Jira from an older in-house solution early this year, and have found it to be excellent so far. There's a little learning curve on the admin side, but the actual experience of using it for feature / issue tracking has been real positive.
A lotta folks I talk to have had bad experiences with Jira in a big-company setting -- say in particular, Amazon --- but most of those problems I've heard boil down to poor practices on the management / admin end, rather than problems with the software itself.
p.s. I've also used Asana and a few other less-costly solutions, but their limitations ended up getting frustrating.
yeah i've just recently started heavily using it for the first time in a few years, and it's not bad!
It has a fair share of issues (it's SO SLOW to do just about everything, and the text editor annoys me to no end!), but overall I think it's making me more productive and it's a lot easier to keep track of what i'm doing, what i've done, and what still needs to be done.
Other issue trackers "solve" the problem in that they're technically incapable of faithfully representing objects like design specifications, adding enough friction that the process is pushed back from "technical solution" land to "social/organizational solution" land where it belongs.
Jira is a crutch, in the most literal sense: it makes things that should be hard because of your lack of {personal, organizational} health, easy, in a way that makes people avoid doing the "healthy" thing (facing their problems and rebuilding said {personal, organizational} health) indefinitely.
But most other systems don't sell that they can solve this problem. If I gave you a web form with a title, a description, a comment section and some tags, would you argue that you could solve those org problems?
Would you spend any time trying to solve the problem in the system?
Agreed that the problem isn't directly Jira, but (anecdotally maybe) there seems a clear correlation between Jira and unhappy developers who feel their tracker has way too much process. Jira doesn't cause the root problem, but Atlassian are profiting from it existing, and so maybe people are encouraged to use it in those ways. I'm not letting it off the hook so easily.
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.
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.
@TheGRS, that's what Rank is for. Boards are using Rank field for ordering, that's why you can drag and drop card up and down. Also that is the thing that allows a global order across multiple projects - you can have boards which span across very weird sets of issues thanks to JQL
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.
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.
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?
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.
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.
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.
Somewhere along this thread it became an indictment of Jira. I've spent a tonne of time over the years at multiple orgs both using Jira and trying to move away from it. 10 years later.. I'm back on Jira and won't move.
The issues I find (including speed) are really due to the incredibly flexibility of Jira, and things not being thought out by users. Ultimately, I feel like it's akin to the old adage about perl - it does everything including giving you the rope to hang yourself.. it's up to you if you hang yourself. That plus all my friends who insist one needs a PhD in Jira, to Jira... but I digress.
We're set up appropriately with issue types, differentiation between issues, bugs, tasks, (and our version of etc). We can plan sprints locally and remotely, and have all our dashboards and friends immediately update. Integrated (sanely) with confluence we get retrospectives, historic reports. We create bugs, move their states, deal with Agile and Kanban, have histories... the whole deal. To reduce the inherent pain in dealing with bug creation because it generally sucks, we have a slack integration I wrote to:
a. Create a bug
b. When you type ISSUE-ISSUE# into a channel, the robot picks up and gives us all the subject.
The combination above removed all friction. The one thing I wish would happen from a workload perspective is that when a PR is pushed upstream to bitbucket, for a branch matching an issue - the issue would move to the Code Review state. But that is our only point of friction, and one day I'll get off my rear and make our robot do it.
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?
I'm an engineer. Writing code but also doing code review.
I worked with jira and scrump but the last two years I introduced kanban. But those projects have a high level of uncertainty and supportrequests. Which just makes it hard to finish a Sprint.
Always git. Git with GitHub.com, on premise GitHub and selfhosted gitlab.
I do use the reporting Features. It is nice to see the progress. Seeing the backlog shrinking and also the time on how long a ticket is in progress. It helps a little bit of keeping priorities. It also helps showing the management why stuff takes as long as it takes. Especially unplanned work.
Working with Jira and Bitbucket and loving it all the way. We spend some extra time on configuration and learning people how to work with it. Sounds like they havent done any of these things.
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.
I work in a shop that had effectively no project management. When jira was introduced it was a godsend. Obviously email and slack requests aren't better, so what is the alternative system that has people hating on jira?
JIRA has a tendency to.... decay. New ticket types are created with custom fields that aren't ever kept up to date. Everyone starts to choose random entries because they have no choice, and no way to add new ones. Once that starts, things fall into chaos because nobody knows the "right" way to file tickets. Tickets soon become immeasurably immeasurable. Projects become categorized incorrectly on a constant basis. The only people who know how to use JIRA effectively are the ones who know how to ignore all the noise. Once those people leave, you're left with pure, unadulterated chaos.
And then you get people who try to fix it by adding a new ticket type or project group, etc. Rinse, repeat.
If you haven't already, then you should check out JIRA's query language and its API. The query language is... special (and doesn't support wildcards, last I checked). Its API, instead of displaying field names as you see it in their interface, shows "fieldname_21234". No joke. You have to run another api request for all of the field names and associate them yourself. It's painful
To your point - sure, JIRA can be used effectively. Though, any bad tool can be used well if enforced. But that's not what most of us have seen in the wild. JIRA eventually just becomes a behemoth of a tool.
Dev here. I worked in the company that used Jira. Used it for 4 years. It was really useful.
It is anyday better than getting tasks over email.
We had very minimal customisations. A simple set of swimlanes that we update throughout the product development process.
From what you are telling it looks like your team had other problems in delivery. You tried to solve it via Jira by adding new custom fields and forcing people to update them. Solving the deeper issue would have helped there.
I have been able to track my deliverables. See how my team is performing. Plan for the next sprint. Perform retrospectives and capture action items. The tool hasn't broken while doing this. UI is decent. I really don't see a problem with the tool, it serves its goal.
Is there any enterprise scale tool that doesn't, when it isn't managed correctly? It needs management just like any other tool that's being used on an enterprise scale. People just want to be able to set and forget, but then it doesn't adapt well to individual departments and teams. Then people either start messing with it, or if they can't, they start hating it.
The benefit of a smaller tool is then, that teams can just get their own instance and mess that up without impacting the organization.
There's a saying along the lines of, the purpose of a tool is determined by how its users use it. For instance, security dialogs are often useless because users blindly click through. Is this a human problem? Yes, absolutely. Does that mean we can blame users for not using the dialog properly? No, it doesn't. We're trying other approaches now that encourage better behaviors from users.
All that is to say, a human problem is fundamentally a tool problem.
That's a great point about Jira, about decaying and left over ticket types. But I used TFS (team foundation server) in a job, and it had some of the same problems. Someone always felt the need to edit the dang project and team paths and it was just a pain in a big company with constant churn. One level deep labels is much easier to deal with.
The two... archtypical complaints typically I hear levied against JIRA are typically:
1) It's sometimes a tool for managerial micromanagement, such as the extraction of unreasonably certain estimates as "promises", which can then be adjusted further down by your project managers, which can then be used to pressure devs into crunch or worse, instead of as a means of adjusting expectations.
2) It's an extremely complicated piece of software which you can (read: will) overcustomize into oblivion, confusion, and general busywork. Having grown over the years, it's various complications are also not consistent with each other, so some features don't really work well with others. The antithesis of KISS or YAGNI.
3) Project managers will still ask you about stuff instead of referring to JIRA. What's the point of sending time estimates into the void if they're going to swing by and disrupt your flow to hear those same estimates from you in person anyways?!
#1 gives people a (reasonable) emotional reason to hate JIRA, #2 gives people a (reasonable) rational reason to hate JIRA. #3 probably counts for both. I feel like I'm the weird one out not having come to hate JIRA in my social circles.
Project management is important, but JIRA is just a tool, not project management. Ultimately, that's a communication problem with your stakeholders and the people who get to call the shots. Email, slack, trello boards, even water-cooler chit chat can be better than an over-configured JIRA install in the right hands with the right managers. Get everyone on the same page in terms of tasks and priorities, manage expectations, track progress, avoid last minute surprises...
Something like a Trello board is sometimes popular with the "JIRA is overcomplicated" crowd. I use it for personal projects sometimes. It's OK. I'm OK with JIRA in the right hands too though. You don't have to tweak every single knob and settings. You can practice some self restraint and avoid it nerd sniping you, probably.
I was running an on-prem jira. But I felt like I was doing something completely wrong because it was so unbearably slow. I was slightly embarrassed that it was on me that this was running so slow.
Our team grew to the point where we needed a bigger license, so we just migrated over to Jira Cloud. And it was even slower than the on-prem install.
No "no project management" isn't a better solution. No, I can't name any alternatives off the top of my head that are better than jira. But holy cow, jira is not a good piece of software. It has a lot of great concepts, but it runs like garbage and really isn't THAT fancy for what most people require. Especially for the cost.
It's not good, but it's not exactly a risky move either. "No one ever got fired for choosing IBM."
We use YouTrack with great success. We have a fully fledged issue tracker we can customize to our needs, and the agile boards make planning and executing sprints straight forward.
The worst shoes in the world are a godsend to a person who's been walking across the desert in bare feet. Doesn't mean they're good shoes.
Good project management systems are simple and frequently not completely technically automated. Trello, or its older cousin "index cards on a whiteboard" are popular. Regular GitHub issues handle much of what needs to be handled, as long as you impose an organizational policy for how you'll go about triaging and updating status in them. Scrum stand-ups are just... regular meetings. None of this is very fancy; none of it needs to be.
It’s not that JIRA cannot be decent, but in any enterpriseish environment it ALWAYS turns into a monster.
The Jira environment I’m currently working in, takes 2+ seconds for any interaction to update the interface (that’s the sped up version. People tell me it used to take 20...).
Creating a new ticket displays no less than 150 fields (not all of which are required, thank god).
It depends on how Jira is used. In your case it appears that there was just oversight added when there wasn't before, but for many of us we get quizzed daily on whether or not we're logging hours for individual tasks, "burn down" is used as a measure of productivity and there are dozens upon dozens of emails sent out to the point where you can ignore everything and still do okay.
This is excluding Jira's design, which frustratingly makes you click several times to uncover data that should be obvious, and various other minor issues that just create headaches, for example: estimations for individual tasks don't bubble up for stories or epics, so you can have two wildly different sets of data to maintain.
The alternative systems would change depending on what people's issues with Jira are -- i.e are they design-based or ideology-based.
Trello. No "workflows" that force you to drag the ticket through 5 different columns to get it to the state you wanted (or, even better, just make it completely impossible to undo a mistake), no approvals, no waiting 5 seconds for the UI every time you change something, just a bunch of task cards in columns that you drag between them.
Jira's just a tool, a tool with an API, if it burns you so much then set up an email filter and spend a weekend on some GitHub-workalike wrapper or whatever other tool you believe does a better job. God I hate the damned thing, but placed beside all other similar tools in its class, I'd recommend it any day of the week, including over the joke of a system GitHub supplies - hell the ancient Bugzilla even compares favourably with GitHub.
The sad part is... yeah, you're right. It's the best ticketing tool I've used, too.
I'm not sure what the solution is. My naive thought has always been that good management can mitigate most of the need for JIRA - even at large companies. Management like https://en.wikipedia.org/wiki/Kelly_Johnson_(engineer), perhaps.
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.
Does it? I think there are compelling arguments against it wrt remote employees. But I've seen no evidence that once you get bigger than a project that requires more than a physical Kanban boards any project synchronization becomes a farcical activity.
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
That's almost too easy to counter, having worked at a startup with just 3 employees, all devs, and no typical managment whatsoever. Jira was and after like 10 years still is, the go-to tool for bug tracking and it does the job just fine, after a one-time and somewhat lengthy setup phase. Which is obviously nothing compared with the years of use..
Speaking of >making programmer's job easier<, we could say that GitLab Auto DevOps eliminates the complexities of getting going with automated software delivery by automatically setting up the pipeline and necessary integrations, freeing up yourself to focus on the culture part. That means everyone can skip the manual work of configuration, and focus on the creative and human aspects of software creation.
Exactly. Opportunity cost. No software organization can do everything at the same time. What GitHub is saying with this is "It's more important for us to integrate with this thing that your management wants, than to fix any of those bugs you filed".
I was afraid the acquisition by Microsoft was going to lead to it becoming more enterprise-oriented and less user-oriented, and it appears like that's exactly what's happening.
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.
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.
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.
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.
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.
If you know a company that's hiring and has "no Jira" written into the contract, please let me know where! It's easy to find a job at a company that isn't using Jira right now, but then a tool like GitHub offers an integration and they change their minds.
I see a lot of people complaining about JIRA in this thread, so here's my take:
- I've used Trello, GitHub Projects/Issues, and other Project Management software;
- While JIRA has a steep learning curve and is generally unpleasant to use, it is far and away the most customizable and powerful PM software I have used;
- Despite JIRA's poor design choices and UX clunkiness, it is so powerful that I wouldn't use anything else. I'm hoping their design, etc. will ultimately catch up, but even it doesn't, it's still probably the net best option available.
For me that’s exactly the problem with JIRA. Each team I’ve worked with uses a different board, workflow, and what not. I still don’t understand the hierarchy.
And since it is infinitely configurable, the UX is just horrible. It’s not optimised for any particular audience and is all over the place.
For me this is a huge benefit: the engineering team, product management team, qa team, ux team, etc. can each see the things that are relevant to them in the way that they like while still being able to pass the tasks off to the other teams / track them if they would like. You have to put in work to make each flow work for each customer & make sure that the tags are standardized, but once thats in place its super easy (at least for my team)
My reading of this is: software development is still such a disorganized activity that the industry considers it acceptable for each organization to simply make up their own system. Jira is built to work for any such system, no matter how crazy, and your particular instance can change completely at any time (like if your manager reads the wrong blog post over lunch).
This does not make me feel any better about Jira. It's like those videos of early attempts at flight, and Jira is bragging that they make flapping wings and spinning wings and triplane wings and bird-shaped wings -- whatever you want! Great for their company, not so great for me.
Not really. Opinionated software is good when the opinion is something you agree with. When you need the opinionated software to something it wasn't designed for it's frequently really bad.
CMake is opinionated. It's built assuming that the build yields an executable file for Windows, Linux or Mac. Try getting CMake to cross-compile for more than one platform at the same time, or build not than one executable and then build a root filesystem into a system image. This is impossible without circumventing CMake entirely. It's actually pretty easy in Make, which is what CMake generates.
There are tons of organizations which need to manage their projects in a way Trello or Pivotal aren't designed for. These tools require you to adopt a methodology and they work great as long as you do. But if you need to do something strange like integrate with a separate system test team, good luck. That's really why organizations adopt JIRA. They want to do things that the tool designers thought you should never do. And those things are necessary in the eyes of those organizations.
Being opinionated is great if you're a human, but the best software is built by people who are trying to help me do my job, not by people who want to dictate how it should be done from the perspective of not being my employer.
Everything you state as being a "benefit" of Jira's customizability is why devs hate it. The software's features aren't being used to help developers do their jobs, which was the original reason for the product, but to help managers and report fetishists collect reams of unnecessary data points. It is a hindrance to your organization, but at least you get to make sure all those checkboxes are checked.
It sounds like you're either one of the report generators, so it's awesome for you, but all your devs hate it.
Can you give some examples of its power and customizability?
What does JIRA do that for example Trac can't?
(Trac can often be customized with 10 lines of simple Python (or CSS, HTML, JS) dropped as a single file into the plugin folder and you're done. It's the hacker's bug tracker. And it's fast and quite easy to use. I wonder why it's not more popular anymore.)
I've never used Trac for tickets. My first introduction to Jira was replacing 5 different in-house ticketing systems covering systems, desktop support, to software development. Here are some of the things I've noticed that I haven't seen other ticketing systems do as well; each department's tickets had their own fields that were unique to them, you could pass a ticket department-to-department with a clear interface to map and update fields, a clear history was preserved when going from department to department, you could have a simplified interface for users (with additional, more intimidating fields for people working the tickets), you could update tickets by replying to emails (seems obvious/trivial, but that feature is often missing), search was very good. This was close to 10 years ago.
Fiddling with Trac tickets right now it seems like something I would love if I spent the time to learn. For example, search is just a text field. I imagine if I learned the syntax it'd be very powerful. I remember Jira, at the time, had a "simple search" with separate auto-completing fields for things like opened-by, assigned-to, open-date, and "complex search" that used a text-based syntax.
Not that Jira was amazing, but UI makes a big difference. A coworker showed me a different frontend someone had built in front of BugZilla and it looked 100x more approachable.
After working at places that didn't use Jira (well, almost all of them evaluated it but deemed it too expensive and too large of a project to migrate) my current job uses Jira, again. Man is it slow (I've heard this is growing pains of converting a codebase designed to run on a single server and making "services" out of it to scale) and there's way more confusing integration. I've been trying to use it as little as possible.
The default Trac search is very simple, sometimes maybe too simple. There's also the Ticket Query UI for field-based searching, which I use very often and quite like. Plugins for using solr or whoosh search engines also exist, but I haven't used them and don't know much about them.
I know that my experience is by definition limited but across multiple companies & industries the use of JIRA has been uniformly an anti/pattern. GitHub issues on the other hand have never been a negative.
The only reason I bring this up is that I think this is an unmitigated bad feature. The only pushback I have at times in an org is the moat between JIRA & Github
Yeah I've had nothing but a bad time with Jira, it's slow / high latency and high impact to use - combining that with GitHubs poor UX and I guess they're made for each other :/
While I agree that Jira is slow and generally a total pain to use (I can almost hear the JVM roaring 8000km away), I think Github is the contrary: fast with very good UX.
it is odd that JIRA is so slow, and I doubt it's due to the JVM. Clubhouse is built using clojure and is delightfully fast to use. (not affliated, just a Dev who has used mingle, Jira and clubhouse)
Admittedly I havn't used Jira for about 6 years, but I don't recall it being particularly slow, at least if you give it decent hardware to run on (this is on-prem, so not sure how the Cloud editions go).
If you're talking about process aspects, well.. that's also a business process thing, as to how much information PMs/etc want.
I used it 6-8 years ago on-prem. I remember hearing it needed a rather beefy server and I don't remember it behaving particularly fast but it wasn't particularly slow, either. My jobs in-between didn't use Jira, but my most recent one uses the hosted version--it's very, very slow. What's annoying is it doesn't seem to cache either, so a second reload or navigating around is also slow.
I only read this in passing, but I heard it's the growing pains of changing a codebase intended to run on a single-server and trying to rebuild it into "services" that scale.
JIRA is the top project management platform for good reason. I know a lot of people complain that it's complicated, but every time I've something simpler we end up hitting a wall. JIRA just needs a sensible workflow configured for your project and it's great.
All that being said, I don't get this move. Atlassian has a very capable git product. GitHub should have attempted to anoint a new tool.
People complain not only it's complicated but it is slow and overloaded with unnecessary features. Can you open up create a new ticket window and how many features and fields do you count?
> JIRA is the top project management platform for good reason.
As others have said, it's popular with managers, not with developers, but managers make these decisions. I've worked at several places that used JIRA and it was always hated by rank-and-file developers but imposed from above.
That just means it's ideal for your projects, and maybe even most projects. That doesn't mean it's ideal for all projects though.
To use an obvious analogy, PHP is the most popular web backend language and it's ideal for my project, so you should be using it on your project regardless of what your project is...
I noticed absolutely no change in Github's product after the Microsoft news, and I'm 99% sure there will be no appreciable change after this news settles. I'm 100% sure that people are going to freak out and waste their time migrating to BitBucket or GitLab for the wrong reasons. As a Github user, there are a few things Github does that makes me unhappy, like not hyperlinking static text when they should, but who they get in bed with is not one of them.
In general, your new corporate overlords usually spend the first fiscal year trying to figure out what to do with you.
So wait for the first full fiscal year after the deal closes, or the second if its late enough in the year.
Then you will hear logic like, “We’re not going to tell you what to make, but we won’t pay for that,” as if that’s different or even better than just setting the agenda.
I feel that a lot of the sentiment against Jira is a result of bad management - Jira is a tool. It can be used by good managers, and it can be used by bad managers.
Good point. Jira's depth and customizability must be like candy for terrible micromanagers. Kind of like how C++ gets an exaggerated bad rap because it is really attractive to people who like building complicated, baroque systems.
It's an _extremely customizable_ tool. Just deploying it and using it will nearly always result in a bad experience. You have to spend time making it work for your workflow. I don't think that's so much a manager problem as a knowledge of the product. More like a work chair - it can be really uncomfortable if you unbox it and sit down, but if you adjust the back, arms, seat some it could be the most comfortable thing ever.
Tools drive the way they're used. You have to go out of your way to use Jira well, the path of least resistance is to use it badly (e.g. task state transitions default to disallowed and you have to explicitly allow the ones you want to permit, so your workflow will be too restrictive unless you've gone out of your way to fix it).
After using bugzilla, mantis, tfs, jira, gitlab and github, I honestly think that jira is not half bad. In fact I prefer it over gitlab, but I'm alone with this view on the team.
The hatred towards jira is on par with desktop java.
While ive only been a dev for a bit over a year at my current company we use JIRA and its been pretty easy to understand and work with. Issue comes in a tester and dev is assigned work is tracked through the issues ID and you just move the status through its lifecycle (progres, review, testing, done). Maybe theirs more cumbersome workflows at other companies but mine seems to keep it straightforward.
Jira is bad enough that at one point was seriously considering doing a startup in this space. There is a ton of alternatives for "simpler" use cases but 0 better alternatives that can actually be used by large Enterprises.
> 0 aside from Jira that large enterprises can use.
that's because the complaints against Jira (being infinitely customizable and has lots of enterprise features) are the very things that a startup can't do - and perhaps, feel they shouldn't do.
you should check Tuleap definitely cool with large enterprises. Ericson, Airbus, Orange, STMicroelectronics with tens of thousands of user per enterprise on a single instance. Cherry on the cake it's opensource and actively maintained by a company; Enalean. We get a lot og positive feedback from our users and keep improving it
Nooooooooo. Ah I'm so sad. I literally found out 2 days ago we're gonna move to Jira. I hope management doesn't find out about the integration between the two.
You may like Jira or dislike Jira, but having to click fewer controls, and likely wait fewer times for a Jira page to load, will be a plus. Especially if your company is heavily invested in Jira, and switching to your more favored issue tracker is infeasible.
I feel sad for all the Github users who will have to suffer the awful JIRA UX. It’s a tool that tries to be everything to everyone with a decade of legacy cruft attached. The result is something that is slow, confusing, and incoherent. If you have an expert and sink a lot of time into, you can a few decent workflows, but it’s just not worth it.
In the end though, don’t worry the managers will get their reports and everyone will at least have there feature box checked (assume you don’t care about Markdown).
For me its important that it is separate from GitHub for a few reasons:
- having a Jira project means we can easily move issues between projects. This is especially useful for when our support team notices an issue, submits a ticket to our "support ingest" project, and then it can get routed to the correct actual project on the backend. Or when an issue gets misdiagnosed we can move it between projects while keeping a single issue and all the history of it.
- having more complex workflows that allow you to force issues to go through specific steps, trigger webhooks, good fun stuff like that
I really would love a good alternative. Jira has just gotten slower and slower, their UX has gotten worse, and I really would like a good alternative.
However Jira has solid integrations into a lot of places and does a lot of complicated things.
Yeah it's an ugly UI. But once you are used to how it works, doesn't it do the job fine? I don't spend that much time in task management software, just need to look up my tasks...
The hate for it is from the large amount of customization that is done to workflows at large organizations, many times in the name of "compliance" or "security".
Instead of just moving stories between lanes (To Do, In progress, Testing, Done or whatever), you're filling out multiple forms, clicking a bunch of checkboxes, adding links to test results, build results, PRs, etc, all for someone you'll never know to run a weekly report and send it off to a bunch of people who will never read it. But they will generate a wonderful paper trail in case something happens.
This reads like a wise move on GitHub's part. Head to head, GitHub wins against bitbucket 10 out of 10 times x infinity. But being very close to enterprise sales cycles, some pointy haired boss somewhere says "gee, we have a jira contract already and they'll give me this other piece of software (bitbucket) for next to nothing...it's got to be good enough for my devs, right?" Of course this is silly way of thinking, but I'm certain it happens all the time, more than we think in forums like this.
It's like Google Docs + Trello + a Wiki. We use it for our product roadmap and task management, and can easily link to documentation, specs, or discussion all in one platform. I'm a huge fan.
It's pretty extensible and I find it easier to use than Jira.
My complaints aren't necessarily against Jira the software, but the way it got setup at my org. It seemed more for stat building for the PMs to show during their annual review.
So I installed it, configured it, the sync status is "COMPLETE" but I can't see anything related to github in my JIRA issues that are mentioned in PRs and commits.
That was true for some time, but they're making me miss Bugzilla now. I spend increasing amounts of time just watching Jira load it's ever more bloated UI.
I think it depends on how it's configured and on the team's workflow. It really sucked at my second to last job, but at my most recent job it was reasonably usable, in that about half the time it was better than a comparable tool like Pivotal Tracker or Asana, and about half the time it was worse. A good and bad thing about it is that it isn't a typical single page app - good because it has fewer glitches and bad because it is more tedious in some places than Asana or Pivotal.
I have a lot of respect for Pivotal Tracker. It's a really elegant design, it is just missing a good detail view on issues, like GitHub's with history, comments, convenient deep linking, markdown, syntax highlighting, integrations, etc. Trello has a good detailed view for its cards, but not as good as GitHub.
I disagree, if the project is organized the way PT is intended, it's nice. If you have too many cards, or too much information with each card, it gets cluttered, and handles clutter worse than JIRA or Asana.
Having used both HP QC and Microsoft Team Foundation Server (the successor to VSS) for issue tracking, I have to say that Jira is better than TFS is better than QC. The big problem I ran into is that many teams had different fields and TFS and QC showed them all. This is a huge problem when there are well over 100 teams.
This icould be great news, it is not clear from the article but I hope they solved the annoying problem of first repo sync hitting Github rate limits. We had this issue several times when we migrated from Trello to Jira.
To wade in on the JIRA wars going on, I was once a JIRA consultant (among other things).
I ended up telling people I worked on business process design because once you see 100 different ways people are using a tool you learn most of the wrong ways to do it.
The primary issue with any task tracking or workflow tool is that the people implementing it have never learnt what is effective and what isn't. Worse, what is effective changes depending on what exact kind of task you are trying to track, in addition to the organisation and everything else.
I would typically start, regardless of what the particular thing I was brought in to help with was, with getting management/project leads/etc to agree to what outcomes they want from a tool like JIRA.
Companies have processes that get followed, and management need to provide direction and measure what's being done. Overwhelmingly there seems to be no good way of transferring information between these layers, of people doing work and other people trying to understand what that work is.
A good tool will make it easy for that information to flow.
The problem is that for the information to be useful it needs to be accurate and complete, you need people to actually use the tool. Every time you add a gate to a task (this person must accept this before it progresses, or this field has to be filled out) you add friction to the process and people disengage (often using a different tool altogether like excel or sticky notes).
At the same time, a well designed tool supports people doing their work. Prompts remind people what things need to be checked or completed at each step, and notifications can let you know when something needs doing.
As long as you can get people to agree to these concepts, you can start to design workflows and information to capture that will be useful for the people using it, and useful for the people trying to work out what is happening.
JIRA also takes a while to learn how to architect sustainably. If you create 20 copies of different screens it becomes a real chore to go in and change them down the track. If you do have a bit of foresight and experience, however, it's not hard to manage hundred of projects with different workflows and fields.
It has lots of warts and cruft that's built over time, and there isn't enough knowledge about how to use the good bits, so it gets a bad rap.
I know how to use it pretty well, and am normally in a position to change it when I need to, so don't run into the gripes that most people see.
The biggest positive however is not that it can do almost anything 'task-tracky' with a bit of effort - it's that it can do that and someone else maintains it. So many tools (internal and external) grow and grow and grow to try and cover things like assigning tasks and tracking workflow and sending emails, or run into a wall because VBA scripts in excel can only do so much. The ability to take almost any of those and add task tracking by simply integrating with JIRA is a huge selling point and has provided so much value to me over the years. That I can do the same for all parts of the business is the main reason it has spread so far in the enterprise world.
I remember the days that JIRA used to be snuck into small teams when no one was looking, and spread organically throughout the organisation after that because it was so useful.
> Every time you add a gate to a task (this person must accept this before it progresses …
This seems to be the standard failure mode. When a ticket is wrong, I try to fix it only to find I'm not allowed to, because the workflow presumes the actual state of the project today can't happen.
The solution of course it to just allow people to do what they want.
Every now and then it’s useful to everyone to stop some things from happening - it’s easier to have the gate than to not.
The fact that that exemption exists is what drives the pain most people have with systems like this.
My trick was to say “while we’re building this let’s just leave it as open as possible, we can lock it down once we’re sure the process works how we need it” - and then never lock it down (or just lock down the bits that people use to shoot themselves in the foot).
Ok, so finally time to move on to Gitlab, my weekend is gone! While from what I read GH issues are not going away, I won't be surprised if GH finally becomes a pure enterprisey product.
My only concern is what happens when Gitlab is acquired? If someone from GL can confirm that they have serious checks and balances in place to not let the users who make Gitlab succeed be left to fend for themselves, can be a killing blow to Github in retaining even the left overs!
Deciding to move to Gitlab because there is now a separate Jira integration makes no sense to me. Github has built a completely separate integration with Jira - it's not like anything in Github forces you to use Jira, but if you do use it (like a ton of companies do), you would want a better integration story.
This....this makes no sense. An integration doesn't mean something else is going away. That's not how platforms work.
FWIW, gitlab is going to get acquired...it has to. Probably by google, or oracle, or salesforce, or ibm, or hp (or whatever name they have these days), or redhat. And depending on which one it is, will be how ruined gitlab becomes, because all of those seem like terrible options, but I digress now.
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!