So, Jira.
I do not love it.
Preliminary concessions
Admittedly, Jira does some things well.
It’s a good system of record. We don’t delete anything from it, so you can check project histories from years ago. It tends to keep records of things we didn’t get around to doing, so if we forgot to do X, Jira might remind us later. It’s OK at managing distributed organizational processes like multi team approvals, or requests to other teams.
Above all, it provides a kind of visibility for management into the engineering process. We use it for reporting high level project status to our chain of command, and for release management. It’s good at tracking “In what release will XYZ get released to customers?”
Why I don’t love Jira
Above all, Jira has a really bad user interface, compared to something like Asana. I remember what good UIs feel like. They feel enjoyable, quick to navigate, discoverable, intuitive. Jira is configurable and extensible and highly integrated with other systems, but in my opinion, it has absolutely awful UX and UI. This means that a big chunk of my workday involves bad UX and bad UI.
And above all, it is horrendously slow. It takes forever (in our environment) to create a new Jira (I should time it; sometimes it seems like it’s 20+ seconds). It’s long enough to get bored and want to change focus to something else. Making a new ticket once is bad; making 20 Jira tickets at once is an exceptionally tedious activity, of a kind that software developers should not have to suffer through.
Finally, Jira is bad at some of the things you would expect it to be really good at. For example, Jira is really bad at managing tasks and todos. It’s bad at managing workload. It’s even bad at managing projects.
Jira is bad at tasks
It’s too slow and tedious to put every single thing you need to do into Jira. As a result, most people don’t do that. Some people use Microsoft To Do instead, which is single-user task tracking software that actually works fairly well. It has a clean interface, and it’s a desktop app with desktop app-quality performance.
A lot of people use todos in Google Docs or in Confluence. It’s a lot more lightweight – you can tag a @username and a checkbox will just auto-appear.
Honestly, sometimes I just make todos using MacOS’s Stickies or a plain text doc. I also love Slack’s reminders for lightweight todos.
It’s not just individual workflow tasks that don’t fit nicely in Jira: it can be team workflow stuff too.
Jira is bad at workload planning
We’re constantly trying to plan our workload from one sprint to the next. (Everything is divided into sprints, even though we don’t really use agile processes in most other ways.)
You can assign your Jira tickets to a sprint and give them a workload estimate. I’ve found that Jira sprint plans are a mixed blessing. They’re too granular, for one thing. And yet there’s a lot that we never capture on a Jira - the time cost of going to meetings, the time cost of updating Jira. We end up getting pulled into new questions and discussions from one day to the next, in nonlinear ways that defy the plans again and again.
But no one can realistically plan their sprints more than 1 or 2 at a time. So if you want to know “Who will be available to start a new project in 8 weeks,” Jira is useless.
Sometimes we just use a Google sheet for workload planning.
Jira is bad at project management
I’ve noticed that when my organization needs actual large-scale project management software, we just use Smartsheet. It’s just a much better tool that models the project management problem better. I see why skilled project managers prefer it.
“Voting with your feet”
In short, for a lot of problems, Jira is a bad tool, even when it theoretically provides the right feature set for the task. So people vote with their feet: they just skip Jira where it’s not effective and use something else.
This is a good strategy. I endorse it (when practicable).
But sometimes Jira can’t be ignored.
What are our options then?
Let’s write our own Jira client
So here’s the thing about Jira. It has reasonable JSON-based REST APIs and an excellent SQL-like query language, JQL.
And this means you don’t have to suffer through all the bad parts of Jira.
To be clear, you can’t fix the Jira workflow for yourself. If that’s what you hate, I can’t help you.
But it’s absolutely possible to fix the awful UX and dodge the disastrous slowness of the UI.
We are software developers, are we not? If someone asks us to use a horrible interface all day, and there is an easy workaround, shouldn’t we just … use it?
I ended up writing my own Jira client. It’s a native MacOS app that connects to Jira, fetches useful data about tickets I care about, and displays precisely the fields that I want to see. It uses SwiftUI, so it has native app performance and uses native app widgets. I added some custom functionality that I want (e.g. it can track my current priorities if I have a lot on my plate, and it can store notes on tickets that are private to me.)
It’s read only (for now). I don’t want to rewrite the whole Jira UI. I just want to improve the UX for things I do a lot.
Here are some things I often want to do quickly:
- Finding tickets currently assigned to me.
- Finding tickets that I created but am not assigned to.
- Finding all the tickets I’ve commented on.
- Finding tickets that I have closed in the past.
It’s a lot more common for me to look something up in Jira than to change something in Jira.
Consider: - “What was that ticket I just finished?” - “Where’s the devops ticket I recently opened?” - “What ticket number should I reference in my next Git commit?”
I ask myself these questions all day.
It’s more rare that I actually want to close a ticket or comment on something. I set up my viewer app so that you can click on an issue to open in your browser. Then you can use the Jira UI for editing.
It’s not about rewriting the whole application. It’s just about making it suck less for my own workflow.
I can’t release the source code for it at this point, alas. But I’ll just say it’s absurdly simple to write a Swift app that fetches some JSON and draws some tables in a MacOS window.
I don’t usually work with Swift, but this is a trivial project to set up. It took me a spare afternoon or two, including reading a bunch of SwiftUI docs and tutorials since that’s not what I usually use at work.
(To me, the details of the implementation aren’t interesting, since all you are doing is writing a few UI components based on Apple’s stock interface elements. Every so often, I ran into “how do you update a value without triggering re-rendering loops?” But I’ve done some Javascript component work in the past, so it was quick to resolve those issues.)
I can’t emphasize this thought enough: if you hate the Jira UI, write your own client. It turns a horrible experience into a fun toy project.
I still hate Jira
I still hate Jira. But now, every time I open up my own little Jira viewer, I feel content.
Most problems in the world can’t be solved with code. Which makes it even nicer to solve the ones that can.