4 ms·
Jira. Please stop crapping on it. It's a tool that's too flexible so many people can't resist abusing it. It's you, not it.
For us, it's primarily a documentat
Jira. Please stop crapping on it. It's a tool that's too flexible so many people can't resist abusing it. It's you, not it.
For us, it's primarily a documentation tool. It has great integrations. If someone makes a complex pull request, the text that tells me what it does is the Jira issue. Yes, it could be the PR description, but Jira is much easier to link to, search, etc. 2 years later when someone looks at the git commit, they can go to Jira and read through the whole context, who created it, who commented on it, etc.
Just use the damn thing to solve problems you actually have.
Jira, Java, Windows, JavaScript, Kubernetes, etc. can be used in various ways, and because most people aren't excellent at what they do, flexible tools will result in lot of crappy output just because so many people can use them.
If Jira/etc. destroys your project then it's absolutely your fault.
The problem with JIRA is that it attracts and encourages "bureaucracy creep" in typical "big companies". Right after you're switching to JIRA it's fine. But soon the manager types are discovering JIRA as their favourite surveillance toy, and add this little extra step to a bug life cycle, or add this little field here to check when a bug has been resolved. Then that manager leaves and the next one comes in, and "improves" JIRA workflows again. Repeat that 5 times, and your organization has created a monster.
I've never seen that with other less flexible bug tracking tools.
> Repeat that 5 times, and your organization has created a monster.
Yes, this. Jira is cancer:
> Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host.
https://news.ycombinator.com/item?id=25590846 https://news.ycombinator.com/item?id=25590846
If everyone uses a tool wrong, it's not a problem with the people, it's a problem with the tool.
Jira makes a lot of bad design decisions. Virtually everything it does has no undo. Different issue types behave almost, but not quite, the same, and have far too many different fields that end up meaning almost but not quite the same thing, so denormalisation and inconsistency are rampant. It's a micromanagement-first system: everything you want to do has to be explicitly enabled by a manager, and if you want to do something a manager didn't think of, too bad. And its performance is awful.
I am positive that not 'everyone' is using Jira in the wrong way, just that many-many companies use it and many companies have broken culture or processes (or they have the right processes for the company, but that's not enjoyable for the employeees, that can also be the case). Again, Java or Javascript are also a good example: I am relatively sure that crappy Java code is much more common than crappy Clojure or Haskell code. Does it mean Haskell is 'better' than Java
> It's a micromanagement-first system: everything you want to do has to be explicitly enabled by a manager, and if you want to do something a manager didn't think of, too bad.
We don't have anything even resembling to this in our company, and we use Jira. Again: Jira is a relatively good tool for storing information that's related to a certain piece of work. If you don't think that the context for any work should be documented, then don't do it, but we have learned it the hard way that code changes without business and technical context are not great, because in 5 years you might have a completely different set of people working on the codebase and they sometimes need to ask why this code was ever created. This is the context we store in Jira, and we could store it on a wiki, in Asana, etc. but Jira works just as well and again: it has brilliant integrations to everything.
Yeah, performance is not great but it's getting better nowadays. There are faster tools out there, but we considered integrations to be more important (YMMV ofc.).
> I am positive that not 'everyone' is using Jira in the wrong way, just that many-many companies use it and many companies have broken culture or processes (or they have the right processes for the company, but that's not enjoyable for the employeees, that can also be the case).
I've worked in 6 or 7 companies that used Jira across a variety of different industries, and Jira was terrible in all of them; one of them was a previously excellent company that made a switch to using Jira, and that distinctly coincided with the company becoming worse to work with in many ways.
> Again, Java or Javascript are also a good example: I am relatively sure that crappy Java code is much more common than crappy Clojure or Haskell code. Does it mean Haskell is 'better' than Java
All else being equal, yes. You can make an argument that Haskell etc. attract better programmers because they're hard to learn, but it's hard to make a corresponding argument about Jira; how much time and effort does it take to not use something?
> We don't have anything even resembling to this in our company, and we use Jira. Again: Jira is a relatively good tool for storing information that's related to a certain piece of work.
Well, a) I'm pretty sure that's not how most companies use it, and b) I don't think it's very well suited to that either. Its IDs are the worst of both worlds (not a simple number but not actually informative either) and its search function is awful, so it's vastly inferior to using a wiki (a real one, not Confluence).
> Yeah, performance is not great but it's getting better nowadays. There are faster tools out there, but we considered integrations to be more important (YMMV ofc.).
Most places I've worked disabled most integrations due to performance problems, so I may be missing some of your experiences, but I don't understand what and how you're integrating if you're only using it as a store of information.
This is more about how Jira is configured.
For example, there is no reason why each transition in the workflow couldn't simply have a corresponding counter-transition: "Start development" / "Abort development"; "Move to test" / "Return to development" (not the same as "Test failed"); "Test OK" / "Test again"; "Close" / "Reopen". And the excessive fields almost certainly can be removed from the form, so you could reduce the entire thing to Title + Description + State + Assigned To.
You are right that most companies don't do this. That's because in most companies the management decides how Jira should be configured... and their preference is for "more data" because it gives them the illusion of control, and they don't really care how much extra paperwork this means for the developers.
Well, we could perhaps blame Jira for having the wrong defaults. But even where Jira has the right defaults, the management often decides to override them.
For example, Jira allows to split tasks to subtasks, but by default this functionality is disabled, and the documentation argues strongly against it. (The recommended way to use Jira is that the tasks are atomic, and you have a database of tasks. To relate tasks to each other, use links or tags or epics; all of them optional.) Yet, most managers insist that tasks must be divided to subtasks. And then you get the usual "one subtask per each task" or "analysis, development, and testing are subtasks, instead of steps in workflow", because that's how the management wanted it.
Then underlying reason is that developers and managers have different needs. Developers need a database of bugs, and a short list of tasks to be done. Managers want as much information as possible (no matter whether the information makes sense or not, because they don't understand half of it anyway), plus time tracking (to push people to work faster), plus something that would reduce their need to plan and check how the plan progresses... and if they can outsource all this work to developers, that makes their own work more convenient. Which is why the Jira is configured the way it usually is. But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool.
> there is no reason why each transition in the workflow couldn't simply have a corresponding counter-transition
There isn't, but you have to manually maintain them, and inevitably they get out of sync.
> But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool.
Bad management insists on tools that let them manage badly, of which Jira is the prime example. It's not a bad tool in the sense of being badly coded, and on some level I can't blame Atlassian for making a tool that micromanagers love - I'm sure there's a huge market for that. But precisely because it's designed to give bad managers what they want first and foremost, it's a red flag in a working environment.
This again depends entirely on your company. Way back Jira did not have a "allow any state to transition here", but now it does. Now whether that is something that is useful to you depends on how your company uses Jira and its workflow. If you have a huge, overbearing and stringent workflow, then with each combination of workflow steps and required fields and such, everything becomes more and more complex and you easily get into the sort of situation that you describe for various reasons. I wonder how you would have Jira 'help'. If you define a workflow step and set a certain field to a specific value based on post-function from some plugin that actually makes a REST call to some external system. How would Jira help you in determining that if you transition from that step back to one 3 levels before in your (also non-linear) workflow should unset that specific field?
I don't envy you and I feel for you. It does not have to be that way but you also can't blame Atlassian for letting those sorts of companies, which let's face it are larger companies with more licenses bought, buy Jira and catering to them. However, Atlassian has kept things very very simple and open enough that you don't have to be a victim of that.
> Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards).
I do have to give you this, Jira is not great for empowering people to make their own changes to workflows and such, so you _are_ entirely at the mercy of your company. They are sort of changing some of this with at least Jira Cloud and the new issue view (which I hate with a vengeance for the most part) in that you can both "pin" fields yourself on a per project basis (which is bad, because in our case I want the same ones pinned in all projects, as they all share the same issue types and workflows but there's a project per product we have) and you can move fields between the left and right context (or removed from screen) without having to be a Jira admin. It's still lacking in many ways though. Just so you know, I'm not saying Jira is the best tool ever out there and everything is perfect about it. I'm just saying that your company misusing it doesn't mean that the tool isn't valuable and doesn't have some great features. Did you know that Jira since not too long ago allows story points to have floating point values now, because so many people requested it? That is absolute utter BS and not in line with any agile methodology I've ever come across. But I guess this is where I have to refer back to Money, Money, Money ... :)
FWIW I've been both at companies where other people were Jira admins and to get something changed you had to go through someone else and where I was the admin. Sometimes the changes requested were denied. In other cases, even within a large (10k+ employees) companies, we just had our own Jira for the project and I was actually (one of the few) Jira admin(s). At my current company I am not but most things are actually configured just as they should be. If you want something changed, you ask for it and it's usually not a problem and the stuff they're putting in is not crazy.
Would you rather have a centrally managed IBM Remedy? :)
P.S.: And just on the axe, I think it depends. Is it a standard axe with a hickory handle? By default that definitely doesn't slip. Oh you say you oiled it so much that it slips all the time now? Not the axe's fault!