Why I Hate Jira and Confluence

2-20-2023

project-board

Confluence and Jira are used at a number of companies I've worked for. In each one I've been frustrated by using them. It's not that I think they're terrible products (though I do think they're not ideal), but that they're filling a round hole with square pegs. They are clearly successful products, but I believe this is more due to their effective marketing than to the value they provide developers. For those unaware, Confluence acts as a knowledge store, where people can write and link to text pages (with formatting and pictures). Jira is a sprint board and sprint metrics analytics platform.

At the core, I believe that Confluence and Jira are marketed to and developed for business users, but they are used predominately by developers. The feature set is designed for non-technical, non-power users, but is then forced on people who would be power users if they could. The end result is that at least half of their users are stuck taking tedious steps instead of accelerating. In this post I'm thinking purely from a development team perspective: Jira and Confluence may be ideal for business users, UX people, and product managers. That said, I believe it's used in a larger majority by developers, and is not a good fit for them.

I'm a huge fan of Unix Philosophy and Confluence / Jira clearly go against that. Both tools are kitchen sink approaches that try to do everything in a single, semi-walled garden. The application is not at all open to tinkering, but instead wants to bring your code into its garden through extensions, which are often paid. The tools is meant to work for a large organization with centralized structures, as opposed to many small teams using a decentralized approach. Source code is available only for commercial license holders. When another dev and I spent a good chunk of time attempting to dockerize and upgrade confluence, we ended giving up because it was such a pain. It's organization seems to lend itself to a "one size fits all" where every team shares the same Jira settings and therefore have a bunch of process and restrictions that don't fit the team's use case.

Confluence accepts markdown, but once you've pasted it in, it auto converts it to its internal representation and then there is no going backward. Just like its version control, its editing is a proprietary black box. This means most of the things that I hate about Microsoft Word (not hackable, destructive editing, etc) are true of confluence, coupled with that I can't use any of my existing tooling for version control work (review, rollbacks etc). In essence, confluence expects the user to be entirely gui based and work with only their tools, without modifications. The freedom to work how I like to work, or to iterate on my processes, like I do everywhere else in my development life, is lost here.

Jira works the same way. I give it points for its ok API that I've been able to use to essentially eject from card creation through the gui. Outside of that, it's again focused on non-technical users. Card creation is an incredibly mouse-based experience where most fields companies consider mandatory (team, reporter, epic, points, etc) are specific fields that must be clicked and then waited a half second delay for the field to populate, before clicking again to confirm. The editor is the same editor from Confluence. There are automations that can be applied, but they're all low/no code: again focused on non-developers, to the pain of developers as there is a loss of power/tooling when a dev has to translate code into dragging boxes around etc. There is a large amount of dashboards and analytics that delivery managers and scrum masters have access to, but most that I've known export raw data into excel so they can manipulate it and see what they actually need.

Github issues, wikis and boards are so much nicer to use as a developer and offer a fairly "developer purposes" complete alternative. Other projects like Trello offer lighter weight boards that fulfill many of the needs in a developer friendly way. I believe that Atlassian is such a juggernaut for several reasons. First, they market to the decision makers instead of the users (assuming these tools are used "most" by developers). Second, they are courting large companies that are generally more focused on busyness and conformity than productivity and innovation, and are therefore more interested in a tool that excels at tracking developers than allowing developers to be productive.

Throughout this post, I've made the assumption that the majority of uses or Confluence and Jira are developers. I think this is true in any ideal case. Where this falls down is when developers are separated from their users by multiple levels of analysts and middle management. Developers, like other craftsmen, should be purveyors of tools. We should be elevating our non-technical partners and teaching them how to use, tweak, and make better tooling. Instead, we often adopt a large, bloated, one size fits all tool simply because we'd rather keep our heads down than to improve our and our partners lives. When a developer acknowledge a problem, and then sighs and admits defeat because "it's always been this way" or because "that's what the company wants" it makes me think that developer has exchanged the fulfilling, exciting role of problem solving for the dehumanizing ticket-taker mentality.