Comment by dangus
Comment by dangus 10 hours ago
That sounds more like a disastrous missing feature to me.
A good productivity tool doesn’t dictate how teams work.
I’d rather have a tool that’s more customizable.
Comment by dangus 10 hours ago
That sounds more like a disastrous missing feature to me.
A good productivity tool doesn’t dictate how teams work.
I’d rather have a tool that’s more customizable.
Honestly this is a bit like saying that the dishwashers don’t like the food being served at the restaurant.
Project management software isn’t made for the benefit of engineers, that’s on purpose. The customer is the business, not the engineer who works there.
Any issues with the engineers have with workflow really aren’t the fault of the software, it’s the fault of the project managers/engineering managers’ configurations.
You can’t blame the company that makes the paint for the choice in paint color.
Personally I think the only way Jira has dropped the ball is on page load performance.
When I ask my Jira admins to enable a set of people to do something on a project, they struggle.
When I create a ticket and don't open it right away before the popup is gone, poof, it's gone into the depths of that project backlog.
If I want to create a multi-project board, oh, now tickets don't have the same statuses, set up a mapping first.
Or figuring out the artifical limits between epics, tickets and subtasks.
And slowness, don't get me started there.
Yes, just like you are blaming the paint shop for only having the basic colors, I too can blame the paint shop for having 1M green hues to choose from.
And yet every paint manufacturer has hundreds of swatches of various colors that their paint 'comes in', even though there is practically an infinite possibility of colors available.
I've seen many custom JIRA workflows, where you define specific states that can progress to other states. Nearly all of them, over time, were modified so that any state can move to any other state.
And if you engineers don't use the tool you provide, the data in it is useless. Engineers are typically very smart and will just twist any tool they don't like.
Declaration: In order to have accurate state between projects and bugs, everything needs to be tracked in JIRA.
Result: 70% of your Jira stories are now "This JIRA tracks an issue stored in the Github repo, see the repo for current status"
> I’d rather have a tool that’s more customizable.
You think you would, until you do, and by then it's too late.
It's important to have good processes, but the point of all those processes is to help you make things more efficiently. Anything that leads to you spending extra time serving the process directly reduces the amount of real work you can do.
> the point of all those processes is to help you make things more efficiently
I think this viewpoint -- that these processes somehow could increase efficiency if only they were good -- has a lot to do with why engineers dislike systems like Jira, because they will never see the increased efficiency they are looking for.
Let me restate it in a way that I think is a little more nuanced:
The point of systems/processes is to lessen the amount of inefficiency in a group of people working together as that group a) gets larger, and b) experiences turnover.
Nothing's ever going to be as efficient as a single engineer that can build everything with all the details in their head at that very moment. But there's a limitation on size of problems you can solve doing that! So many people working on large problems hate their processes, because each individual person is doing less than if they were in a tiny, stable team, and they can feel this, even if the organization is making great progress.
(And then, at the largest sizes of organization, it's almost impossible to stop the org from crumbling from the weight of its own complexity. People do spend an awful lot of effort trying, though).
I agree with all of that. I understand why there needs to be some kind of rigor applied or else you have a bunch of engineers running around like cats. I'm not saying we shouldn't have process.
But, I've also worked in shops so hidebound that the aim of the organization seemed to be to Follow The Process above all else. Didn't ship anything all quarter? Well, at least we Followed The Process! Customers are screaming? That sucks, but The Process doesn't accommodate their needs this quarter. Principal engineers are leaving? They just don't appreciate The Process!
In my experience, Jira seems to resonate with PMs who adore The Process for the sake of The Process. Lighter, more opinionated systems like Pivotal or Linear seem to help teams deliver features more quickly than teams using Jira to march in line with The Process.
I know managers love Jira — a poster child for customizability — esp product managers, but I have yet to meet a software engineer who does.
It simply slows everyone down, but when it's your only tool for tracking work, it's still better than nothing.
Now, the problem with Jira is not necessarily customizability but that it's dog slow, complex, integrations suck, and permissions system is chaotic. Still, I have yet to see fully customizable work tracking system that's better made than Jira.
But also, a fixed set of features does not force you to ascribe the same meaning to them like the authors intended: I've used "bug" tracking systems to manage large projects with great success (including big features, enhancements, but also big and small fixes).