Skip to content

Instantly share code, notes, and snippets.

@t3db0t
Created September 8, 2016 21:57
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save t3db0t/de49195d1e6809c9c1e8a413dfe85a47 to your computer and use it in GitHub Desktop.
Save t3db0t/de49195d1e6809c9c1e8a413dfe85a47 to your computer and use it in GitHub Desktop.
Why Clubhouse/Why Not Jira
TL;DR: JIRA is the salesforce of project management: slow, ancient, difficult. Clubhouse is a modern, reactive application tailor-made for agile product development. I’ve measured speed increases of 400-1500% (or more in a few worst cases). No, I’m not making that up.
Why Clubhouse?
Here’s a simple presentation I made of why:
https://docs.google.com/presentation/d/14KWfFRXzAJGA1oAblV_5Z4wSPcuR74QxaFLaM2Mjhsg/pub?start=false&loop=false&delayms=3000
A few additional items:
- Easily configurable/filterable workspaces
- Shareable workspaces for custom views tailored to a specific purpose
- New, improved planning workflow for product management / release management
- Git-Flow-style automated deployment
- Easy API for future integrations, i.e. Jenkins
- Extremely responsive customer support
- Continuous improvements
This blog post is a great overview of why to switch to Clubhouse, but needs to be updated, since almost all of those ‘missing’ features have since been added.
Why Not Jira?
Since I’m trying to organize the overall design and architecture of a product line, I’m using the project management tools more frequently than individual developers, and the little aggravations really add up. But there was a single thing that finally broke me and forced me to switch—read below.
• Speed: JIRA’s cloud-hosted application is EXTREMELY SLOW. For some individual developers, this wasn’t much of an issue, because they might only use it once a day to update a few tickets and forget about it. For me or anyone else trying to organize and understand the project as a whole, it started to feel just downright useless. Every single operation takes seconds. Loading our main Kanban board takes anywhere from 4 to 15 seconds (!!). Clicking on a single ticket to view its details takes up to 6 seconds (!!!). The best I can hope for is a couple hundred milliseconds for any given operation.
• Outdated/Senseless UI: But it’s not just the network latency that contributes to an overall slowness: it’s the UX design itself (or total lack thereof). From the Kanban view, clicking on a ticket opens a sidebar that squishes all the ticket cards so much they’re unreadably useless (unless I have it fullscreened). In order to change any information that the sidebar doesn’t happen to show, I have to click a menu button, then edit, then potentially page through the issue options in order to make the change. But the worst aspect of this is:
• Slow, Ineffective Search: Searching for tickets is actually one of the most critical elements in a project management system: during a sprint meeting, say, you often need to see if a ticket was already created for the issue at hand, or find one you know is being referred to. In JIRA, you type your search, then wait several seconds while a flat, paginated list comes back, containing ALL possible tickets, including completed ones, without any obvious distinction/sorting, across all JIRA projects! And if you made a typo, or you weren’t exactly sure what the right search term was, you get to do it all over again!
• Confusing Organization: It’s very difficult to do any kind of meaningful high-level organization in JIRA. I’m talking about product-level planning, sorting ideas into epics and stories and seeing a clean, filtered view of those. For instance, Epics are represented as cards in the Kanban view like all other tickets, and so you find yourself asking: wait, do I put this ticket in “In Progress” AND the Epic ticket in “In Progress?” What do I do with this extra epic card hanging around? They are not automatically or graphically linked in any way in the Kanban interface, so you end up with this extra epic card that noone knows what to do with.
• Configuration Paralysis: JIRA is basically the Salesforce of project management: A bloated, ineffective UI painted thinly over a bloated, ancient database comprising countless miscellaneous fields. There are so many possible settings and configuration options, starting in on customizing anything can easily lead to confusing and difficult-to-debug problems. In fact, the straw that broke this camel’s back for me was that another team in the company changed our “Issue Screen Schema” in a way that literally made it impossible for me to create Epics, because a required field wasn’t included in the schema, and despite 3 different attempts, I could not figure out how to fix it, nor could anyone in IT. This is an utterly absurd situation to find yourself in with software that you pay good money for.
• Nonexistent Support/Improvement: Say you set an issue resolution to “Duplicate” or something and then realize the ticket has to be reopened. You’d want to change the resolution to “Unresolved,” right? Guess what: people have been requesting this for LITERALLY FIVE YEARS to absolutely no avail. There’s literally no way to do it without stupid workarounds.
• …and all the other tiny little things that add up, like scrolling down, clicking in a box, hitting ‘delete’ and typing a number in order to specify story points. And that’s only if you’re already looking at the issue modal. If you’re not, you need two more clicks to get to that.
I probably don’t need to tell you that even tiny UX frictions add up and results in wasted time, user frustration and secondary effects, like spending less time writing good tickets because it took so long to use the software. And if you say something like, “Well, you just need to configure JIRA to better suit your needs”—No. I don’t want a one-size-fits-all monstrosity, I want software that’s tailored to modern, professional agile development.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment