Live data from Hacker News

I Fucking Hate Jira (2022)

ifuckinghatejira.com

191–200 of 287 posts

Re: I Fucking Hate Jira (2022)

#191
post #8

I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.

When I clicked on the site the very first opinion called Jira shit because they had 20 different boards for the same thing, 2000 tickets in the backlog and 20 different mandatory fields for each ticket. Which is absolutely not the fault of Jira. Jira does not make you create 20 boards and per default a Title is all you need to create a Ticket. By the complaints own wording they had 2000 tickets because management ref…

If one company uses a tool badly that's a bad company. But if most companies use the tool badly that's a bad tool.

Jira certainly seems to push people towards having a handful of manager users who are the only ones who can create boards/transitions or adjust which fields are mandatory, and this leads to bad behaviour - if only one VIP can create boards, they'll probably create 20 once and then never create another. "Title is all that's required" may be the default in some editions of Jira today but it certainly isn't widely used. And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have - there may be occasional use cases where you need e.g. an action that's impossible to undo, but it's an awful default.

Re: I Fucking Hate Jira (2022)

#192

Earlier quoted context omitted.

What do you use for documentation? My experience with Confluence has been similarly bad.

markdown, in the repo with the code.

Terrible experience for anyone who isn't already a contributor to that repo.

Docs exist for people other than those that wrote them. The people that wrote them don't need to know the information, they already knew it.

Re: I Fucking Hate Jira (2022)

#193
post #8

I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.

My team does a lightweight agile process, we don't hate it. If we used a better tool, we'd love it. We have Jira, and I don't have the energy to change it, nor do I want the responsibility to decide or suggest what other tool that should be. I've always used Jira, I have no suggestions ready. I'm sure it's easy to pick a simple tracker, like GitHub Issues, but I would not know if it'd suffice all our needs and if it…

> I'm sure it's easy to pick a simple tracker, like GitHub Issues, but I would not know if it'd suffice all our needs and if it would scale

The irony here is that those simple trackers scale a lot better. Jira's complexity is part of why it scales poorly - it's really bad when you have 500 people trying to use it.

Re: I Fucking Hate Jira (2022)

#194

Confluence is where documentation goes to die.

It's the worst documentation tool, except all the others. Seriously though, what is better?

Nothing! Confluence is literally just a Wiki with a REST API and a hundred plugins. You could replace it with a different Wiki, but that won't have as much useful plugins and won't be integrated with the other Atlassian products.

Re: I Fucking Hate Jira (2022)

#196
In my experience, Jira isn't great out of the box but it's pretty good if you take a few hours to understand how to configure workflows, field configurations, forms, and boards.

For example, at my last company I had the development project configured with about a dozen different ticket states, but you created a ticket with a simple form with the title as the only mandatory field but there were optional fields for details and screenshots.

Developers could move a ticket into "in progress" or "can't reproduce". The latter transition showed a form with a mandatory explanation field, and it would automatically get assigned back to the person who created the ticket.

On completing the ticket, the developer has to put in a pull request and can only moves it to the Code Review state and had to pick a different developer to assign it to.

It sounds a bit tedious when you describe it but in practice everyone worked off a board with three or four columns appropriate to their role. They move tickets to the right to advance them or to the left to reject them. There were also automated transitions triggered by things like CI tests, deployment etc.

Re: I Fucking Hate Jira (2022)

#197
The tool (Jira) is not the problem. The "tools" (aka PM and process people) are the problem.

In my experience, the people who are given the responsibility and power to build "systems" and processes are usually least qualified to build the said system as they usually have no experience in and understanding of what it will mean to be working under the system. This is akin to the customer vs. user dichotomy in software development, where things are build for the customer with often detrimental consequences for the actual user.

In considering tools and processes, I believe in discussing each individual decision and process step to death by considering secondary and even tertiary consequences. Yet people making such decisions are not in a position to evaluate such consequences since they have no such understanding, capability, or desire.

This would make decision making slow when enforcing tools to an entire development organization. But, decision making should be slow and deliberate. Otherwise, as I have seen in my own company, we would be jumping from tool to tool per the latest fashion of the day. I've also seen this with the mess of WebEx, Zoom, Teams way of having online meetings, where tools keep changing for the sake of some perceived benefits with no real clear improvements.

Re: I Fucking Hate Jira (2022)

#198
Jira has some merits, but its most common uses are for companies in which the priority is to look busy (e.g., growth startups, inefficient established companies).

For early startups that can't rely upon VC-growth appearances and shotgun-approach hiring alone, I propose a complete selection of tools, including a substitute for Jira:

1. Get GitLab. Maybe hosted initially, but eventually self-hosted if you stay in business long enough.

(a) Do code in GitLab Git. Eventually including mirroring and auditing third-party dependencies (but your first few months of prototyping you'll probably be playing third-party package system roulette, and maybe even piping curl into bash from random offshore file-sharing sites run from countries without extradition treaties).

(b) Do project management and issue-tracking in GitLab Issues, with the Boards and the structured tags, for something Kanban-ish. (And someday someone will make great integrated Gantt.)

(c) Do engineering docs in Markdown files in (GitLab) Git when you want the docs versioned alongside the code. Whether it's embedded API docs/comments, or standalone Markdown documents.

(d) Do all remaining internal documentation in the crappy-looking GitLab Wiki. Emphasize low-friction, teach people how wikis are supposed to be used, and make this this canonical go-to from which all other information can be found (including those engineering docs that are in with the code). Even notes on nearby restaurants and nostalgia can go into the wiki -- you're an early startup, enjoy the efficiency and flatness and coolness while you can. Discourage anything that looks like siloing, fiefdom, staleness, BS, etc. It goes into the wiki unless it should be branched&versioned with code.

2. Tell everyone: Everything Goes Into GitLab.

3. Unfortunately, you also need videoconf and text chat. Useful non-ephemeral data from these gets captured in GitLab, probably into the Wiki. (For example. wiki page "2024-02-14 Cat Affordances Meeting", which started in advance of the meeting with an "Agenda" section. Then, during the meeting, was put up on the screen and had a "Notes" section quickly appended. Saved, done, linkable, findable, unpolished, sufficient.)

4. Don't add more docs&comms tools/SaaSes until someone can say why it can't just go into GitLab. Don't even spend time looking into this unless you're actually feeling pain from "Everything goes into GitLab".

5. If someone ignores the rules and starts putting company data into some random other SaaS (like "digital consumer natives" tend to do), have a thoughtful talk with them about Everything Goes Into GitLab and how they feel about that. While in parallel another employee deletes the SaaS account with extreme prejudice, blocks the SaaS in the company firewall, and posts a picture of the SaaS's head on a stake in the startup's kitchenette as a warning to other SaaSes.

6. If the startup is successful, there will be plenty of time for some Vice President of Procurement, who has little idea how people work, much less how they could be working effectively, to be wined&dined by an enterprise sales representatives, and to buy loads of enterprise licenses of Ass-sauna, Jeers-a, Effluence, BS Screams, etc. Only then will you realize how good you had it before, with your early startup, and you didn't appreciate it nearly enough. You will suffer until a vesting milestone, consult with your tax accountant, and then make your escape. To do your own early startup, where the first thing you do will be to proclaim: Everything Goes Into GitLab

Re: I Fucking Hate Jira (2022)

#199
post #77
post #8

I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.

I've wondered the same thing about Microsoft Teams. Is Teams as horrible as people say, or do they just hate it because it's what they happen to use for video meetings at work? Conversely, I don't hear much hate for zoom.

I, and the rest of our dev team use Linux, and found Teams ok when there was a stand-alone client for it, but the browser-based stuff they forced on us a year or so ago was horrible. The notifications were particularly atrocious, to the point of making the whole thing unusable.

The .deb of the stand-alone package disappeared, so it seemed we were stuck with the pain of the browser-based stuff. Then I remembered archive.org and found the .deb. If anyone else is in a similar situation, it's at https://web.archive.org/web/20221130115842/https://packages.... Thanks, archive.org

Re: I Fucking Hate Jira (2022)

#200

We are going to need a story for that. Be sure to set a good estimate of your effort in the form of story points. Use the Fibonacci sequence to pick the difficulty level for your story points. Your manager will then arrange your stories in priority order, Stories must be worked in priority order. At review time the number of stories and the number of points per story counts. Hurry up now.

Story points represent complexity, not difficulty. We also aim for a certain amount of story points per sprint. After 13 we leave the Fibonacci sequence and just double them. The entire team must vote on story points simultaneously to avoid affecting each other’s opinions, then must discuss the votes until we agree on a number. Stories that have sat too long in the backlog need re-pointing. Voting is now done with po…

Do you spend more time setting up Jira or building the product? There is a balance somewhere.
Post reply on HN