Developers Hate JIRA

From countless conference discussions and Twitter threads, it seems there’s a universal disdain among developers for JIRA as a project management tool. Yet, whenever I ask developers at companies with more than a handful of people, they’re still using JIRA. Why is that?

The answer lies in history. It’s often a byproduct of when the company was started. For a time, JIRA was the default tool for project management. Once a company adopts it, momentum builds, and even if teams grow frustrated with JIRA, the cost and effort of switching often outweigh the perceived benefits. So it lingers.

The core issue with JIRA is that it’s too customizable. This flexibility allows teams to create cumbersome workflows and systems. JIRA’s complexity and extensive options often tempt project managers to use as many features as possible. If you have an overzealous PM with admin privileges, you can quickly end up with a labyrinth of workflows, tickets overloaded with unnecessary fields, and other busywork that makes JIRA a nightmare to use.

We used JIRA for over five years, and it was always confusing, packed with too many features. It felt like it was designed for large companies with quarterly release cycles. The UI was unnecessarily complex and, frankly, made me feel dumb — which is a terrible thing for any user interface to do. Software should never make you feel that way. In the end, JIRA felt like an overcomplicated to-do list—full of features we never fully utilized and costing us more than it was worth.

Switching to GitHub Issues simplified everything. Initially, I thought it would only work for engineers, and that PMs wouldn’t be comfortable using it. There was some resistance from the PMs during the migration, but once we started using GitHub Projects, they loved it. Managing products closer to where the code lives cut down on a lot of back-and-forth between systems. Developers were thrilled, too, as they could directly link their PRs and feature branches to issues. All conversations moved to GitHub Issues, and, as a result, we were able to reduce the time it took to ship features because everything was encapsulated within PRs. Plus, migrating to GitHub saved us a lot of money since we could cancel our JIRA subscription — the cherry on top.

In the end, it’s all about what works best for your team. Good software should guide you toward specific, productive use, not overwhelm you with unnecessary complexity.