Jira is brilliant. It is team-led. Different teams have different approaches, some love all the features like components, versions, issue types, assignee, kanban boards, scrumms, reports etc etc. Others like my team use it with subject/description/comments. You make the tool fit what the team needs.
Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I have no doubt you can use Jira in a "KPI led" way. I do doubt you can use Remedy in a responsible way, but even if you can, it relies on the culture of those selling the tools.
Sadly I fear jira and slack will be next -- they already took Zoom and gave us teams instead, after all we "already pay for teams with office" (which aside from cloud-based email, I, and my teammates, never use).
Never has an anti-trust move been so obvious or damaging.
I've never read that sentence before!
My feeling is... developers hate Jira, managers love Jira. And that is expected. The tendency is for things loved by managers to be hated by developers, such as meetings, metrics, etc.
An example of a very misused metric: In one of my jobs, managers started using Scrum Poker results as a productivity measure. “My team scored 100 points in the last sprint.” Imagine the chaos this generated. Quickly teams began to hate the Scrum poker.
Jira is probably just a scapegoat in corporate theater, something needs to be to blame. Jira is a good culprit.
* In MS teams, I can create conversations, group chats, organic meetings, and add people (and include history) as I want and desire. I prefer it for quick discussions with my colleagues and to get a rapid problem solving or critical incident conversation where I don't immediately know who I need / what it's about, and it'll scale as I add people. I push a button and talk to people, push a button to add people, push a button to video chat, all seamless.
* Slack is structured and formal and based around enterprise-created channels and workgroups, with way too much noise in each massive channel and way too little content that's even remotely relevant to me. Outside of channels, conversations are horribly gimped: A) I can only have one conversation with each set of people, I cannot simply rename a chat and have three different chats with same people around different topics B) If I add people to an existing conversation, it will create a new chat without history (this may have improved recently as I know we sent a TON of feedback to Slack admins). Basically, to get anything done you have to create channels, which is great for "top down, I know ahead of time what I need / want to enforce" structure, but awful for "this started as a one-on-one and is now a massive discussion with 17 people"
I'm looking at some of the other comments, and it seems they have some weird gimped version of MS Teams. E.g.:
>>"Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel."
This... is how it works for me. I start a conversation with some people, then I add people, then I click "Call", then we all video call together, then we are done and keep typing in it, repeat as needed.
Weird!
1) Let a Team channel be a normal-ass chat instead of some weird forum-in-a-chat-interface. Shit gets lost. Creating a new post feels very formal and high friction, because it’ll push everything else out of view (another, minor problem: teams’ padding and whitespace is way out of control). Make it configurable! That’s ok. The weird chat-as-forum thing is fine for a very low-traffic announcements channel (and very bad for anything else) so having it as an option is alright.
2) Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel.
These two problems force conversations away from the “Team” and into meeting-specific chats and DMs. It’s really, really bad. It silos knowledge and makes it hard to tell wtf is going on.
Teams is horrible for distributed or hybrid work because of these two deficiencies.
That doesn't sound real. There's supposed to be some central department(s) that collect ideas from the process framework of the season or requested by customers (especially those items for levels that are not requested), add their own ideas and create a superset of that as configuration with everything set to mandatory. The result is infliced upon everyone, except of course the department that was responsible for the definition.
> Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
> Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I'd say it's the other way round. Everywhere I've seen Jira, the person who can change the tool settings (e.g. make mandatory fields optional, add a transition to allow you to move a card to the column it should be in (because Jira is deny by default, you can only move things in ways that are specifically allowed) is a very distant part of the org chart from the team doing day to day work on it. "not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance" is exactly how I'd describe Jira, given how I've seen it used (across a great many organisations, large and small - indeed I'd say switching to Jira is the most reliable indicator that a previously fun company has grown too big and it's time to leave).
Some stuff is probably just typical managerial bullshit. But the fact that Jira defaults to working as a slow, drag-and-drop interface with no undo is absolutely an unforced error.
> Never has an anti-trust move been so obvious or damaging.
Atlassian buying Trello and gradually ruining it is worse than MS giving away crappy products for free.
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 refused to delete outdated and irrelevant tickets.
A new tool would not fix this since I would bet that management would insist that all 20 boards with all tickets in the backlog would need to be transitioned to the new tool. The mandatory fields are obviously also highly important to management, those need to be configured in the new tool as well.
Instead of complaining about the obviously bad management they just complain about Jira. That is, I think, very common when complaining about jira.
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.
Management didn't insist on that.
The dopamine hit from tweaking charts and organizing digital clutter is probably the same area of the brain where the social media infinite scroll dopamine hit happens. If JIRA the product didn’t offer all these dopamine hits for doing busy-work, aka “features”, and stuck to basics then people wouldn’t be complaining about the tool and how their management/admins have implemented some nonsensical process.
I've used Jira (last job) and Linear (now). I don't really see any compelling reason that Linear is "better" than Jira. Jira was always pretty easy to use and navigate for me, and we had team-focused views for ourselves.
Even on this site, several opinions I looked at are about the idea of process or the implementation of a process—not really about Jira. And several of the ones about Jira just came off as whiny nitpicking and not actually meaningful.
JIRA was a dramatic improvement at one point, however, it is bought and sold to managers, so it is unsurprising it eventually converges to managerial overengineering.
You're kind of missing the problem here - it's both and neither. It's not the tool (it's awful) or the mid-to-large org itself, it's the concept that a tool as blunt as a ticketing system can meaningfully capture software development management in a useful way.
If people just treated it as a "necessary evil" time-tracking type system to make sure people were really working when they said they were, that would be irritating but not damaging. But far too many people without a lot of mental faculties actually take it completely seriously and try to put everything in it and expect meaningful results out of it. It actually ends up being worse than "nothing at all" because it _insists_ on the "only do what can be predicted and whose predictions is measured in hours" model of software development that stupid people think encapsulates creative activities.
The background to this is : yes it can. I worked in organizations (long pre-Jira) where we developed the bug/ticketing system specifically to drive our development management process. The two evolved in concert. The result was excellent, and sadly has never been re-achieved with any of the modern tools.
My take on this is that somebody was told that the bug system can be used to drive project management (which it can) but then implemented a bug system without any real understanding of what that means or how to achieve it.
You’re conflating ticketing systems with work estimation.
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.
- Airtable
- A giant board on Miro.com with a bunch of notes in frames
Of course the scaling needs are different whether it’s for just a single team or if the data needs to be aggregated into some KPI. In my experience it’s better to keep KPI publishing separate from task tracking, though
1. It's too configurable. It's like the company wiki. People come in, set up some random projects, processes, fields, statuses, etc. and then move on. There's rarely someone making it all consistent and sensible. This results in task statuses that can be TODO, BACKLOG, PENDING, WAITING, TO DO, etc. etc. etc. You also end up with waaaay too many fields for tasks. Arbitrary distinctions between "Tasks" and "Stories", etc. You're at the mercy of your Jira admin who will definitely make worse decisions than e.g. the developers of Phabricator or Gitlab. Hiding useful fields, adding pointless ones, etc.
2. Despite being super configurable, it can't do some really basic things you'd expect from something whose sole job is task tracking. For example you can only parent tasks 2 or 3 levels deep. A task can't have two parents. Subtasks can't be in different sprints. You can't reorder tasks by priority in the backlog.
3. Most offensively it is just incredibly slow. The main way you add tasks to a sprint is drag and drop on the backlog, but it performs so badly (100% CPU all the time) that they've had to add context menu options to move tasks to the top/bottom or to a sprint. I believe there's also an option to disable animations. A simple web page should not consume 100% of my CPU.
It's by far the worst issue tracker I've ever used.
Companies still pay for it though because PMs love the pretty burndown charts and being able to add a gazillion fields to tasks. How will they report project status to their bosses if they can't have Jira work out the exact-to-the-second estimated delivery time automatically? And by "automatically" I mean by making someone else do all the work.
Even a small drag'n'drop resulted a vast amount of computer power grinding away.
CCM is so bad it’s nearly dysfunctional. Image Jira but 3 times the necessary clicks (this is not hyperbole).
With Jira I can see the good intentions and how they go awry. But CCM is pure madness from top to bottom.
Which were ignored because everyone found it easier to just read and search the comments. So a thick chunk of commenting became de facto mandatory.
Unfortunately in any medium-to-large org, there are a non-zero number of morons.
I used to work in a largish public company (40K+ people). They had a wonderfully functional and flexible bug tracking system.
So no, at least in my experience one can be in a large org and enjoy your bug tracking tool, nothing to do with the overhead of a large org.
But jira, it is beyond awful.
Atlassian desperately needs to pause on new acquisitions and new features for at least two years and rework all of the products they acquired and unify them. Literally every Atlassian product offering has a different way of doing things, no consistency anywhere. Oh, and half of the functionality has no API, and there is no first party Terraform provider so you have to do everything by hand every fucking time.
The abusive workflow bullshit by clueless middle managers is another problem in itself, thankfully I'm in the lucky position to tell people "no, we won't do that".
DC (and formerly Server edition) are pretty good products that do their thing fine and are fast enough for typical use. Unfortunately, Server edition was discontinued and DC is too expensive, so formerly happy developers are forced to switch to Cloud edition, which is horrendously slow. Jira Cloud also lacks some loved features, such as the plaintext comment editor [0].
It seems to me these tools should be optimized for the majority of their users (developers) and if the PMs need pretty graphs and someone else wants it all in a spreadsheet (OMFG) they could use any of a hundred integrations to extract the data and generate those without more effort than wrangling Jira.
Shit, lots of places are already paying for GH or Gitlab (or self-hosting the latter). They just don’t use that part and instead also pay for Jira or Asana or ADO or whatever productivity-murdering junk-drawer-where-information-gets-lost garbage.
If JIRA at least had rational design underlaying poor implementation, it would give some reason to bear and hope. Instead, it is an infinite fractal of nope, the likes of which you hardly encounter outside government contract projects.
We were forced to get off of Phabricator because it was abandoned, but JIRA was still a downgrade in every way. Linear will eat JIRAs lunch and in a decade, it's going to go the way of HipChat as the thing that everyone used but nobody talks about.
That compounds any corporate-inflicted issues.
I was thinking maybe I could help, that some hated software was something I myself had used at some point. But I have never used Jira. When I investigated what Jira was, I had the same thought: I thought that in this case the software is probably only part of the problem.
So, let's sum up my personal gripes (on a Mac):
1. Teams keeps locking up the dGPU for whatever reason randomly after calls, draining the battery and grilling my legs until I figure out that Teams has gone nuts again.
2. Since the macOS Sonoma update and the switch to the "new" Teams client, every time a call comes in, the ringtone glitches out (and I'm not alone in that)
3. There are three different ways of chatting with other people: Meeting chats and direct/group messages (these are summed up under the "chat" tab) and "teams" with "channels". The latter don't produce instant notifications when someone writes there, I guess because Microsoft doesn't want to deal with "I get an instant notification every time someone posts a kitten photo in the off-topic channel" complaints.
4. There is only one uploaded-files repository which means if you have a "screenshot.jpg" sent to someone, and you try to send a different file with the same name in a different chat, it will say "you already uploaded screenshot.jpg, do you want to replace this?". This is fucking bad UX, likely caused by Teams using OneDrive under the hood to share files.
5. The search is slooooow as molasses and damn useless. You have zero chance of ever finding something again, the larger the org the worse the pain.
6. No window/functionality remembers your context when you switch away. Say you click on a notification from a chat because a colleague needs an urgent answer, while you're scrolling in a team thread... you go back, and your scroll position is lost.
I assume they're both doing something unfriendly that Firefox disallows on privacy or security grounds.
But they pushed out a new version recently. Now you've got Teams Classic and Teams NEW (work or school)... at least on the Mac.
It's sooo much better. Way more stable. Search is a delight (relatively speaking). We get far fewer complaints now.
Worth mentioning: We only use the "Chat" aspect, we don't use the "Teams" aspect. If we want to discuss a project, we just spin up a new chat with relevant parties and rename the channel to the project. Works great. We could never get "buy in" on the Teams aspect, nor threaded discussions. The main reasoning was having to monitor two tabs in the product. Everyone just wanted to stay on the Chat tab, so we made it work.
Also the ux is pretty bad.
That’s stupid and a flaw in teams. It’s a bad messaging app. It’s pretty good with meetings though.
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
Jira is just the tool management chooses because nobody-got-fired-for-buying-jira.
I can just say from my own experience that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer or anything near a software project, and yet enforces all this garbage for their illusion of control. And yet they have none. Just because they are higher up in the hierarchy than the people that works with the actual product.
And then there is all these managers that think that everything should be a ticket and all changes can absolutely map to a ticket. Or that everything is actually done by the guy on the ticket.
I bet when I die and go to hell, my punishment will be to fill out Jira tickets and push them through the workflow.
Edit: formatting and spelling
However, as a manager, things go south very quick if you're not tracking what's being changed and by whom. You won't know what's included in your release, nor if it was tested properly. You won't know who to reach for fixes after testing or even what to tell clients when they ask if a feature/fix was shipped.
I hate overly complicated processes, but tracking things is essential.
Overly complicated processes are just patches to try to cover up for immature engineering practices.
The source of truth is their changelog not your Jira tickets
git
>You won't know what's included in your release
release notes
>nor if it was tested properly.
CI
This is all configurable by the JIRA admin at your org. You're not complaining about JIRA, you're complaining about someone at your company who set up the workflows. I figured this out after bitching endlessly about JIRA at company 1 only to move to company 2 and discover everything I had hated about the process was set up by my previous boss...
I thought it was JIRA, but it was the org..
My team has done a lot of work to lean into the tool IE well defined issues, epics, tickets, t shirt sizing for pointing via 1, 3, 5, etc.
There is lots that can be improved for sure.
With this system, my team, in addition to any one else at the company, is able to click into our JIRA board and get a very high level to a very low level understanding of what we are working on.
This allows for very clear reporting structures and ensures our goals are on track with those of the company's. This also makes outcomes more measureable which is exceptionally helpful for reviews.
At the end of the year or halfway through I can go in and say: I worked on these 4 epics that are part of these two Issues which serve company goals A, B, and C. I completed x% of the tickets for each of these epics, led this entire other epic which was completed on time etc etc.
Where we run into issues is when there is a ticket that has to move between boards. The ideal situation is we just move the ticket from board to board as needed but based on the user they may or may not have permissions and have to open a new ticket linking it to the previous one. Not ideal but that's up to us to resolve to make sure the right people have the right permissions.
We ignore all the analytics IE burn down and friends. Those are useless.
Short version: Jira, in a vacuum, is neither great nor awful. It just is. But it has a complication that makes managers I want to work for dislike it, while strongly appealing to managers I don’t want to work for.
That’s not universally true, I’m sure. However, it’s been my experience.
I think that could also be described as Jira gives people who don't really have anything to do, something to do, but for those who are blessed with an abundance of work, Jira can be unnecessary overhead.
But actually my biggest grievance is the terrible search function. You can search for the literal title of an issue and it won't come up in the results.
So, when I try to do something new (to me), and I search the web, the hits are frequently outdated or related to a plug-in that I might not have access to. Makes it really difficult to do anything that isn't part of my company's baseline.
Have a bug? JIRA makes perfect sense, you have a ticket with comments, it keeps track of how long it's been around, it can automatically move the bug through a process, etc. All these tools started out as "bug trackers" after all.
Trying to plan future work? What I usually want is some kind of lightweight graph tool to figure out task A unblocks task B, etc. This graph changes a lot over time, with tasks merging and splitting apart. I've wasted a lot of time trying to enter all this in tickets.
Want to know about work that's already completed? I would never look at JIRA. Look at your Git forge. Pull requests should have proper descriptions. The Git history will always be more accurate and detailed than a bunch of JIRA cards.
So basically, use JIRA for bug tracking, Git/Github/Gitlab for historical tracking, and I'm not sure what to use for planning. Honestly I've been reaching for Excalidraw recently.
Right up until Atlassian and Jira become synonyms for everything bad amongst the overwhelming majority of people who have encountered it. About when "Jira-free workplace" goes on job ads. Which has got to be a pretty good strategy by now. Anyone seen it yet?
At my old work I usually left a search going from the root network folder over the weekend, scanning for some keywords, when I needed a doc none knew where it was or if it existed at all.
There was a parallel documentation system from IBM that didn't work, where the canonical docs should be. But you more or less had to know the document ID to query it. So most documents were also in the network folders spread out between hundred project folders and meeting folders.
It's like:
cat $DOCS > /dev/null
rm $DOCS
Seriously though, what is better?
I tried using README files in the repo but there’s far too much friction to get most folks to bother. Google Docs tend to disappear content due to a lack of structure.
For what it's worth it's a lot better than it was in 2016 but I'm still not a fan.
[1] https://www.broadcom.com/products/software/value-stream-mana...
It's entirely possible to write a simple, elegant, issue tracker in JIRA.
I have yet to see one. I am ashamed to say that I never made one.
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.
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.
In the places where I've hated Jira, it's been locked into overly complicated workflows that didn't match what I needed; into the inability to create new views that provided insight into the work; into many tedious required fields even though we didn't use that data in our work stream at all. I've been locked into "one-size-fits-all" workflow approach.
Turns out: that's pretty much all configurable! Jira doesn't mandate the use of a one-size-fits all approach. Shitty company culture mandates that.
In my current position, I have admin rights to Jira and also a mandate to keep teams empowered and processes simple. Guess what -- Jira is pretty awesome here (I use it to develop, too.) In roughly a day or so, I created an entire automated hiring process via a Jira board [1] that got us phenomenal feedback from candidates. I actively ask teams what parts of the process are annoying, and then automate them or fix them, because I am empowered to care about developer experience.
Once you're a part of a generative culture that truly cares about empowerment and enablement, you start to see how much of your disdain for tooling was actually a disdain for a culture that prevented even very useful tools from having a positive impact.
[1] https://seankilleen.com/2024/01/how-i-created-an-automated-a...
Things are sometimes stories, sometimes epics, and sometimes tasks or sub tasks. No one knows why, nor have they found a good way to integrate them all into The Workflow.
I've never spent more than like an hour training anyone on JIRA and have used it successfully for many, many years.
On top of that, I can create a quick form in Confluence (with some intelligence/dependencies) and enabling/disabling/showing/hiding other options, sections, questions, etc.
No complains from either products here. Are they perfect? No. What is?
That said, when it’s bad it’s because the company is trying to be too clever with it. If it’s used how Atlassian recommends, it works fine. If not, you have a lot of pain. I can’t blame Atlassian too much for their customers, either. The customer is always right.
If you have someone with the knowledge to use what's in the toolbox and the scope to build flows that support how work is done in your org, you'll love Jira, because it'll work far better for you than anything else could.
If you don't have someone like that, or if you're small enough not to want or need that yet, then you'll fucking hate Jira.
I have tried all the Jira clones, and Jira is the only thing that doesn't try to turn PMing into a video game for lazy micromanagers... if you don't let it become that.
Jira doesn’t actually bother me. Confluence is a tool of satan.
One company allowed each team to manage tasks however they liked - and therefore each team had a different method. Other companies tried to force Trello or Asana into software engineering workflows. I now think of JIRA wistfully.
I particularly liked that there are very nice cli tools for it: https://www.pivotaltracker.com/integrations/command-line
FYI a dozen people would be a huge team at Pivotal. 30 folks working in a single backlog is unheard of. But I hear Pivotal became a different place after Rob left, so I don't know what it's like now.
I think the key is to have good search, which Jira does not remotely have.
I get their points, but the way everything is presented is awful. I assume that these are comments on an article or responses in a conversation, but I can't see who is responding to what. Clicking "Next" to see each individual comment is also tedious, and it means I'm going to stop reading after 4 or 5 pages. I'd rather read a single page that I can scroll through rather than an "interactive" site like this.
I read dozens of them and I found the presentation to be a fun approach. The creativity is welcome IMHO. It was immediately clear to me that these were comments scraped from various sources on the internet. Who they're replying to doesn't matter much. If you've worked with JIRA extensively, you've already heard many of these criticisms.
I personally just my own backlog/todo system (both for work and non-work stuff) and consider Jira usage a necessary evil part of the job. Hopefully I'll someday work somewhere uninfected.
Now I just write all my jira stuff in a external text editor and paste it in.
Jira is the only tool I know that has proper permission and visibility controls.
If you try and do anything outside of that use case, its limitations become glaringly obvious.
And companies very often use it in a way that it is not supposed to be used which then requires expensive cloud add one which bloat the monthly cost.
Jira is fine. Admittedly, I've seen some installations that are slow AF but that isn't the problem.
Current worse; TargetProcess with a 9 month development process.
Of course the idea is to make a good product that folks like to use, but it's surprising that you can succeed by knowing what buyers want.
The unfortunate reality though is that almost everything we consume nowadays is pushed onto us without our consent.
What the fuck is this? I don't care how much you dislike a software package, this is not ok to say. Regards, an ex-Atlassian staff member.
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
It gets ridiculously bloated
(No really, Trello is just Jira with cuter, slower menus)
When you learn how they are supposed to be used, and use them that way, they work really well. Sadly I have only met three people in my entire career who did so. Their job titles were scrum master, release manager, and project manager. They had to learn how to use the tools because that was their job.
And so they did. They could do literally anything we asked them to. They showed us all kinds of amazing things we didn't know we could do. All because they took a few hours of training and read the docs. That's when I learned that my own parroting of "I hate Jira" was just my own ignorance showing, and I grew up a bit. I really like Confluence now; I didn't even realize it was a Wiki before.
You can misuse any tool but that doesn't mean the tool itself is shite, you're just using it incorrectly. If you limit Jira to just an issue tracker with Kanban it's actually pretty good.
I dunno if the situation has changed since then, but I would bet it hasn’t changed much
For instance, I searched for "I **ing hate JIRA too, the interface is clunky and slow and makes me angry.," and found it was from this comment from Feb 2014 [1].
It is perhaps a bit disingenuous to not to include dates.
1. https://www.reddit.com/r/sysadmin/comments/1z07fi/my_company...
Some people complain that I don't update my stories but more often than not I just wait so much for stuff to open on Jira that end up doing something else while it is loading the page and forget about it.
- Me, 2024.
They loaded the oldest comments first... and you had to click "Load the next 10" REPEATEDLY until you got to the newest comments.
I have since left that company and don't have to deal with Jira anymore so I'm not sure if it got "fixed" at all since then.
It was the one of the most baffling, user hostile decision I have seen made to a product, and I'm sure someone got a commendation for "speeding up the ticket load page by X%".
Working on an efficient and product-oriented company can be a joy, and 100% capitalist.
Working projects that are just politically driven, or where process took over common sense, that's depressing, capitalism or not.
While I have not heard about Jira, Atlassian rings a bell. Not sure why.
That's where a lot of people usually hear about Jira, but it's going to depend on your org.
It figured out it was best for him to continue that way.
this is almost on the same level as someone saying he never heard of subversion
I'm not so sure about the subversion comparison. Maybe it's out of date - someone who got started programming in the last ~10 years has probably only ever used Git, whereas plenty of organizations use Jira, as far as I know.
How about this? https://www.openproject.org/
