8 ms·

Jira can’t stop people from using it incorrectly

98 points by zdw 3y ago

retrocryptid 3y ago
"No, it's the children who are wrong."
- deleted 3y ago
  [deleted]
cratermoon 3y ago
Several years back, before Jira became the software everyone loves to hate, I worked at a smallish company where the engineers had brought up local Jira instance as a sort of skunkworks project, because the bug-tracking tool the company had been using wasn't working for them. They set it up to fulfill the basic need for programmers on a team to keep track of their work. Fast forward a couple of years and it had become the company standard, replacing whatever preceded it, and the company had at least doubled in number of employees. The Jira workflows and ticket fields got the "corporate standard" makeover, including adding a field with so many values that alone it accounted for much of the increasingly poor performance. The arguments the author makes here encapsulate the evolution at my then-employer. Everything became about using an enforced process and workflow. The worst part about it was how some of the changes were enforced on all projects from the top down, meaning teams (like mine) that had a reasonably good, workable project setup had to change the way we did things, use different terms, and generally give up the working style that made use successful. Some time later, much to my chagrin, I ended up consulting at a company using something even worse than Jira: + Azure DevOps, Azure Boards, and all things Azure. These were coupled with the micromanagement and non-manager anti-patterns described in this article into a situation where developers spent more time pushing buttons and shuffling tickets arounds than writing code. The engineering manager made it clear how, to her, seeing tickets moving through the workflow on the board, on schedule was as important as working code.
sidlls 3y ago
No, I love my current manager, and really despise Jira. It’s slow, bloated, and tries to solve every project management problem and ends up solving almost none of them well.
- deleted 3y ago
  [deleted]
digitalsushi 3y ago
someone on here a few years back said "You dont hate Jira. You hate that it's a mirror". It meant that Jira just reflects whatever your busines management policies are and I think there is some truth in it.
- t-writescode 3y ago
  Nah. I hate how long it takes to load different pages. I hate the UI and how there's a bazillion non-removable fields that don't need to be filled in, but are present. I hate that you can't click on links inside Jira, but almost every real thing is actually a link, so that's unhelpful. I hate how it automagically saves changes. And many more things.
  - darkstar999 3y ago
    > I hate the UI and how there's a bazillion non-removable fields that don't need to be filled in Huh? That must be configuration on your project. I haven’t experienced that.
    - jayd16 3y ago
      I hate tools that are almost always misconfigured.
- Rayhem 3y ago
  > You don't hate jira, you hate that it's a mirror Is this just a restatement of Conway's Law[1]? [1]: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- echelon 3y ago
  Jira is like trying to use Perl in 2023. It's slow, it's clunky, it's ugly, it's bug ridden, it's unloved, and nobody understands it. May it die a quick death. Did I also mention it's slow? I think I wrote this entire comment faster than one Jira page navigation. Maybe two, if I have to be charitable.
nine_zeros 3y ago
Management _loves_ to observe and analyze tickets to death. They think that's their entire job. This is why they buy JIRA. It lets them sit back and look at charts of BS points, BS tags with little to no understanding of what the work actually means. They don't buy JIRA because it helps engineering. They couldn't care less that it takes so much of engineering time. Which leads to why engineering hates management. Because management doesn't care about engineers, why should engineers care about managers?
- Zigurd 3y ago
  Agile metrics is the "diet snacks" of project management, and Jira is a key enabler of that delusion.
- JohnBooty 3y ago
  Management _loves_ to observe and analyze tickets to death. They think that's their entire job. At my last job they made a lot of noise about valuing collaboration, mentorship, career development, etc. But after layoffs, it was revealed that management literally just counted up Jira tickets to measure developer productivity. So any time you had spent helping others was essentially just time you spent destroying your own performance ratings. ¯\_(ツ)_/¯
  - nine_zeros 3y ago
    And when they don't reveal transparently what they use to measure, engineers feel the gaslight burning and stop complying. Then manager asks, "What's wrong?" Management is an utter bane of the tech industry.
- deleted 3y ago
  [deleted]
000ooo000 3y ago
I hate them both!
- deleted 3y ago
  [deleted]
db48x 3y ago
No, there is room in my heart to hate both.
- deleted 3y ago
  [deleted]
tekla 3y ago
Nope. My manager is great. Jira just really really really sucks
- deleted 3y ago
  [deleted]
waffletower 3y ago
I really really like my manager. She hates Jira. I also hate Jira. (She's married to someone else so I ought not to say that I love her)
- deleted 3y ago
  [deleted]
- Minor49er 3y ago
  Of all the types of tickets that Jira could be configured to handle, it sadly cannot track nor measure the open issue of this hopeless office romance
satisfice 3y ago
This is a pretty good article. But it uncritically swallows the idea that the only way to have reasonable transparency is through atomizing work into trackable to-do items. I do successful work of all kinds with clients and collaborators and never come near a Jira.
- somewhereoutth 3y ago
  It's a 'remembering' tool - but 'forgetting' is also a valid and productive activity. Some things should be remembered, e.g. important bugs, but other things quite often benefit from being forgotten, like irrelevant feature requests. It is surprising how many problems can be solved by simply ignoring them - the trick of course is knowing which ones to ignore. To-do lists tend to preclude this strategy entirely though.
- dasil003 3y ago
  This is a keen observation and 100% true. A lot of people (both engineers and managers) willingly align behind this regime because the system gives them ostensible clarity on what they need to do, and a paper trail to show how hard they've been working as air cover if anything goes wrong. They are optimizing for comfort and covering their own asses. Unfortunately, this puts a very low ceiling on the type of problems that can be solved. In fact, it works against creative problem solving because it obfuscates the big picture by drowning out the strategic summaries and narratives needed at different zoom levels for different stakeholders. The devil is in the details, and the only way to get the details right is to have real expertise and collaboration based on higher level understanding. Ideally every individual involved has the highest level goal they are capable of executing on, and is empowered to work out the details collaboratively with whoever needs to be involved. This is easier said than done, because most people—even experts in specific domains and skillsets—are not experts in collaboration and understanding other people's mental models. Management's job, if they are doing it correctly, is to understand these dynamics (hopefully rooted in deep hands-on expertise) and to set up the structure that facilitates the necessary collaboration. Useful tooling for this problem is context specific, but less is usually more nuanced messaging or vision doesn't travel or align well across large groups of people. Jira does nothing to help with this; it's just not built for strategic planning or collaboration. It shines for tracking a huge influx of unrelated tasks that have to be passed around between silo'ed teams without dropping any balls. This allows project managers and operations folks to monitor things mechanically where the problem and process is already well understood. It offers very little to support higher-level problem solving.
fouc 3y ago
First time I used Jira I was lucky that the company had it setup quite nicely. I really enjoyed it. One of the things I really enjoy about Jira is the fact that a task and a sub-task have the exact same UI. A sub-task can be easily moved to be a full task and vice versa.
- lloeki 3y ago
  "Hey this PROJ-1234 task is in fact a subtask of PROJ-1111!" "Agreed! let's move it to be a subtask of PROJ-1111! and here's a new PROJ-1235 for the second part, let's make it a subtask as well" "Wait, I can't make PROJ-1234 a subtask of PROJ-1111..." "Ah, I see, PROJ-1111 is already a subtask of PROJ-1002, which indeed makes sense" "Oh, right! I forgot subtasks can't be nested. So maybe PROJ-1002 is an epic?" "Sounds about right! Oh wait, PROJ-1002 is part of epic PROJ-223" "Oh. I get it now, forgot about that epic which tracks things for product item foo" "Alright, is foo still on track and required?" "Yeah, it's merely been postponed because the currently worked on project item bar was priorised as we needed a bit more work to refactor and complete foo" "So now we're set to do PROJ-1234 in the current sprint, and this would complete both foo and bar, two birds one stone!" "Yeah that was the plan all along, having the design lend itself to that, with proper composition and all." "But we can't make it part of both epics" "Correct." "What if we create a new task and link it with PROJ-1234" "Could work. How do we qualify it though? It's "duplicated by" but we keep that for duplicate bug reports as there are automated workflows for it, notably a duplicate is supposed to be closed." "Blocked by maybe?" "Well it's kind of bidirectional and blocked by is one direction only" "Drat there's no "Linked to" in the combo box" "Yeah management wants everything qualified so that they can build reports. IIRC they don't scope it by kind "bug" because marking some tasks as bugs biases another counter, so some bugs stay as tasks, so they can count only bugs reported by customers and not internal bugs" "Oh right, doubles down on why we can't use duplicate, we'd break the report. Actually I think we can't use the link feature at all because it's really the same task and that'd break their report too" "Screw it let's just put a link on each one's description to the other. I'll shoot an email to the JIRA admin to see if we can add more link kinds, and maybe fix the automations and reports" "Yeah, we're already overtime for that sprint planning anyway. Let's move." "Should we do that at the PROJ-1234 level or at the PROJ-1111 level?" "Not too sure. Maybe we should have used a checklist for PROJ-1111" "But then PROJ-1478 depends on PROJ-1234 only, not PROJ-1111 as a whole" "Ah, right. Maybe we cleaned up the arch a bit too much lol" "Right? Maybe we should switch to an arch that matches how we can link tickets lolsob" "JDD: JIRA driven development" "Hold my beer while I write a JIRA plugin to export task structure as a code scaffold" "Kill me right now" "Goddammit time flies, let's finish this. So where are we on PROJ-1526?" "Blocked, we're waiting on feedback from the user" "Alright. Wait, there are two "Waiting on customer" statuses now? Which one is it?" "Huh. Let me look at the browser inspector... Ok, id 17, so I think it's the second one. No idea where the other one comes from." "Ha. Ok, moving on." Slack pings > Hey, meeting xyz has started 10min ago, are you joining? "Drat"
natch 3y ago
I like my manager and I like Jira mostly, though it can definitely be set up poorly and search could be made more approachable.
- deleted 3y ago
  [deleted]
danrl 3y ago
No, I really do not like Jira. My manager great.
- deleted 3y ago
  [deleted]
Zigurd 3y ago
In the majority of my consulting engagements, the client is using Jira. I don't think the permissions for my account have ever been right on the first day.
softwaredoug 3y ago
Jira is the union of all TPS reports. Between every PM, every manager, etc, everyone wants to track slightly different information. The ICs can't keep up - they have five people telling them to use Jira just a little bit differently. The bosses/PMs don't feel this tension, they see only their asks, their report they want to stay up to date, they wonder why its so hard. Eventually, ICs see it as confusing hassle (like TPS reports in Office Space). ICs don't know what to do, and everyone gets confused, information doesn't actually surface in Jira, real issues get dropped on the floor, etc etc The problem isn't that any one of those bits of reporting is wrong. It's actually that the higher levels need to realize they're actually asking for different / conflicting / excessive information and need to have a stronger hand in reducing information reported so to ensure that which is there is actually accurate. (The insane configurability of Jira and other PM tools just reflects this chaos)
ggm 3y ago
I don't hate jira or my manager. I do dislike the misapplication of jira as a tool to problems by rote, and I dislike some of the consequences my manager accepts to achieve his KPIs. Managers and Jira have their place. It depends on context and scale of problem amongst other things. I can imagine a tool like jira helping prevent a space shuttle disaster, and I can imagine a tool like jira not preventing it. I can imagine a manager preventing, and not preventing a doomed launch. I can imagine a 2D grid of jria and no jira, manager and no manager and every single square can have "maybe, maybe not" inside it.
- deleted 3y ago
  [deleted]
hprotagonist 3y ago
> The most common reasons I hear for hating on JIRA are “because it’s slow as balls” is conspicuously absent as the first reason!
- deleted 3y ago
  [deleted]
niedzielski 3y ago
I encouraged our IT team to try Trello (now owned by the same company, Atlassian) which sports a JIRA integration[0]. Either due to the fundamental limitations of the integration or a botched setup, it's useless. There seems to be two copies of each ticket (one JIRA, one Trello) that can be in different states. It was not just another UI for the same underlying data. I do hate JIRA. JIRA adds all the beauty of a government bureaucracy to what should be post-it note management. It's hard to overstate how demotivating JIRA is to my work and especially to my planning. Worse, everyone in the organization has to use it. [0]: https://blog.trello.com/jira-trello-intregration https://blog.trello.com/jira-trello-intregration
- LelouBil 3y ago
  I'm not sure JIRA is meant to be "post-it note management."
- WorldMaker 3y ago
  I miss Trello sometimes. The Atlassian merger killed most of its old spark, and on top of that the micro-managers of Jira at my company wound up eating my old Trello account (because Atlassian decided to merge accounts on email address, which was dumb) destroying a lot of data in the process, and then decided to turn off Trello entirely (and block it). I'm much more of a Kanban sort. Jira is awful at Kanban. Trello was great. We migrated some of our Trello boards to Microsoft Planner (inside Teams), which is a laughable joke. Then eventually to Jira because Jira is an inescapable black hole and "oversight" from the micro-managers matters more than getting projects done on time.
somewhereoutth 3y ago
A ticket for each bug or new feature, with commentary including images and videos as necessary, linking to consequent code commits, with a not-done/under-review/complete status field, raised by the reporter, assigned to the responsible person, and indicating the target release. That is the essence of a good workflow tool, and Jira will do it fine. It is all the extra stuff that seems to cause the grief.
- MBCook 3y ago
  Exactly. I’ve used it like that. It’s great. But at other companies I’ve been at, it’s not a productivity tool. It’s a management too. Estimates for planning. Which is fine. Until pointless rules appear. We’ll use standard story points. But not 1, that’s too small. So things start at 2. But after a while that’s too small. So they start at 3. But you can’t go over 8, past that they have to be split. And you shouldn’t probably use 8 anyway. Pretty soon everything will be 5s. No matter how big or small. Good thing we point. And of course the whole point of pointing is to put things in sprints. That’s fine. But then the rules come. You can’t go over your capacity. You can’t go below your capacity. You have to roll over everything you didn’t do. You can’t roll things over. We committed to finish by Junetober 37th even if we’re not ready so it has to go in the sprint now. So now you put things into the sprint after the sprint started and remove things before it’s over so that the magic numbers look correct even though they are complete BS. But luckily you can track things. Except every team is forced to use the same workflow even if they don’t work the same way. Because otherwise it would be “complicated“. So the IT tickets have to look like software development tickets. And the planning tickets have to look like software development tickets. It’s important to have tickets to plan your future plans so you know what tickets to make. After all, if you don’t schedule everything 18 months in advance to the day, are you really doing agile sprints? But you can link tickets. For example you can choose requires, or needs, or is dependent upon, or can’t be done without, or is waiting on. Wouldn’t one thing do for all of that? No one actually knows. It’s an unanswerable question. Did I mention there’s Kanban support? You’re not allowed to use that. Because. And all this gets so complicated you need people whose job it is to wrangle Jira full-time. Make reports, add more fields, etc. Of course those fields don’t make sense in a lot of cases. But sometimes they required. And other teams want them required but aren’t allowed to because everyone has to work the same way. So the ZRX team invents their own email gateway to put issues into Jira their way. You didn’t know about that right? Because if you add the issue directly they’ll ignore it. Productivity! I don’t know if it’s fair to call the thing I used at those companies “Jira”. That’s a bit like calling a battery made out of a box full of potatoes a “vegetable medley”. I mean it’s sort of true but that’s not the point anymore is it? I like actual Jira. It’s a good product. Too bad almost no company will let you use it, only corruptions. It doesn’t exist to do its real job but to instead generate management reports. Which they don’t read. Poor Jira.
xwowsersx 3y ago
My biggest complaint with all of the Atlassian tools I use (Jira, Confluence, etc.) is how slow and unresponsive they feel. Creating a new Issue requires waiting at least a few seconds, sometimes more, for the newly created Issue to pop up on the bottom left. Editing a Confluence doc requires clicking the edit button and waiting a few seconds while the entire page does, what appears to be, some massive shift to editing mode (understandable that there would be big differences between read and write mode, that's not my issue). I think my perception of and feeling towards the Atlassian tools I use would be, no exaggeration, 10x more positive if everything just felt zippy and close to instantaneous. "Speed is a feature", or however the aphorism goes. Also, I'd be remiss if I didn't link to https://ifuckinghatejira.com/ https://ifuckinghatejira.com/ (for the lulz)
- tails4e 3y ago
  We use confluence and jira, an d for some reason it seems perfectly usable compared to others stories here. It's not a small organization either, so I wonder if it's some misconfiguration that's killing performance for others?
  - xwowsersx 3y ago
    That's quite possible! I'd love to know what it is. If it's somehow a consequence of the total number and age of stories since our account's beginning, I'm not sure what we could really do about that other than to do bulk deleting which...we really don't want to do.
  - _s 3y ago
    Have you used other tools like linear? The performance difference is striking. Atlassian tools are decent enough, and mostly usable is how I'd describe them. I'd take anything else though, even Rally.
    - xwowsersx 3y ago
      I have. Linear is great, although I didn't use it as extensively as Jira. Wish we could use it.
re-thc 3y ago
Jira is my real manager!
- deleted 3y ago
  [deleted]
brailsafe 3y ago
In my last job, I definitely hated my manager and how they used Jira, but I actually liked Jira for the most part. What I hated about Jira was that it allowed my manager to decide on an expectation for how it should be used, and though technically it did do that, it didn't enable me to use it in a way that aligned with their idea of how it should be used. It frustrated him that I didn't accept the guilt he was trying to throw at me for not using the tool in the way he decided was important. Also, it suffered from the same problems as any isolated tool; being out of sync with other tools and invisible unless I'm looking directly at it. I never really got the unresponsiveness that others mention, even on an intel MacBook pro. What I like about Jira technically, is that it has a pretty decent rich media interface for expressing ideas. If I found a bug, or needed to document how something currently works, I could use the native screen recording on my mac and then drag the video file straight into the comment. It would have been great if my manager wasn't a petulant, controlling, and passive-aggressive tool, so that I could use Jira in a way that better suited the development process.
lampshades 3y ago
I hate Jira and I hate managers.
- deleted 3y ago
  [deleted]
colechristensen 3y ago
No, I hate Jira. It takes an impressive amount of experience, self control, and perspective for the management and product types to not take full advantage of the kind of absurd abuse Jira enables. Jira gives people bad ideas and makes them think they’re supposed to do things that way. Jira encourages bad behavior. I don’t hate addicts for being addicts. People with not enough to do find things to do and with jira around those things are “bothering developers with ever increasing process”, it is indeed the tool’s fault.
- deleted 3y ago
  [deleted]
po 3y ago
Jira is like the `extends` keyword in Java... It makes it way too easy to create huge hierarchies of classes that then take tons of additional tooling to refactor. Sure you can have a simple process in Jira... but it will be constantly whispering into the ears of you and your coworkers, "wouldn't you like to have an approval step for that? I can easily add one here... How about we add another state that this issue can be in? Then we can hide those issues from this alternate view over here..." Jira ossifies your company process in concrete which feels great when you first build it but then agility becomes a struggle. You don't even notice it at first but slowly over time your company will fight to get things done outside of the process. You'll then spend so much of your time adapting Jira to reality, you'll wonder what the point of it is. So yeah, you hate your manager who is mostly just trying to use the best tool for the job, and bought the most commonly used and well regarded tool for it... but that tool is encouraging them to build a giant mess.
rco8786 3y ago
Nah I hate Jira lol. Or else I’ve hated all of my managers and that’s definitely not the case.
- deleted 3y ago
  [deleted]
theultdev 3y ago
No, me and my manager switched off Jira a long time ago because we hated it
- deleted 3y ago
  [deleted]
soudiere 3y ago
Nope, definitely hate Jira.
- deleted 3y ago
  [deleted]
jchw 3y ago
No, I hate Jira. I tried using it at home, too, back when they offered licenses for mere mortals. It's slow, the UI is weird and full of old and new stuff that totally mismatches, I hate the API, etc. Maybe some of it has improved, but when it got its reputation, it sucked. I absolutely prefer Linear no matter the manager, and it's not even perfect.
- deleted 3y ago
  [deleted]
cebert 3y ago
I work in a fairly large S&P 500 company that uses JIRA to manage most of our software projects. While I do agree that the performance of JIRA can leave a bit to desire at times, I don’t feel the same animosity towards it as many seem to. Since we also use GitHub Enterprise, I’d personally prefer to use GitHub for issue management but I can live with JIRA. Perhaps I’m just fortunate to work under leaders who don’t force a lot of overburdening JIRA processes. At my work each team can setup their JIRA project and workflows, boards, etc. in a manner that makes most sense for them. Teams can use hours or story points, kanban or scrum. The focus is on delivering features and quality (in terms of customer reported open CRM issues not JIRA issue counts). I feel like management is pretty transparent on how they use JIRA and what their expectations are. My boss and their boss openly share with us what they look for in terms of team project health. I feel like anyone on my team could suggest a reasonable JIRA process change and it would be considered.
- igetspam 3y ago
  > I’d personally prefer to use GitHub for issue management but I can live with JIRA. No, you wouldn't. I promise. You'd spend months fucking around with GitHub Projects, hoping you could figure out how to unclusterfuck it and you'd miss Jira. It's not good enough. I didn't know how much I actually didn't hate Jira until I worked at a company that tried every other option. They all suck. Jira sucks less.
- fatnoah 3y ago
  > The focus is on delivering features and quality In my first month as VP at a growth stage startup, I asked everyone in Engineering why we used Jira. The responses all boiled down to what was basically a shrug. I followed up with what they felt we should use it for and the universal answer was just to be a scrum board, so I spent a bunch of time removing fields and nearly all workflow steps and rules enforcement except in cases where a particular team wanted them. This ruffled a few feathers of folks who loved making tools do all the work, but the improved QoL and happiness the team at made any objections moot. Similarly,I asked all the external stakeholders what they wanted out of the Engineering team, and the common answer was regular delivery of features and products. So now that's what we're optimizing our process around, and (not a surprise) that's been more of a "make the product team focus on fewer things", reduce architectural debt, and automate more things kind of effort. Now, estimation is still a big part of this, but it's used mostly for capacity planning and to gauge the effectiveness of efficiency related efforts.
kstrauser 3y ago
I agree. I’ve said Jira is a code smell. It doesn’t automatically mean an engineering department is broken, but I’ve personally never seen a counterexample. My problem is that the wrong kind of manager takes to Jira like a lab monkey to meth. You don’t have to use it to build a development process that makes reporting happy but devs sad, and yet that’s what always seems to happen. And if you’re willing to use Jira with its defaults and not as an inner platform, why not pick something that devs actually like to use? For instance, my coworkers think Linear is great.
sharts 3y ago
No, we actually do hate jira. Having to open a browser load a heavyweight page and then fill out various fields on multiple forms on just to enter some text is stupid. It would actually make it less annoying to use if it was some kind of CLI/TUI. Like in the old days of mainframes when you’d talk to a receptionist to schedule an appointment or register for classes and they’d be typing away on a colorful/neon terminals. It doesn’t need to be vim like. But it definitely shouldn’t be what it is today —which is a tool for geriatrics and designed by literal clowns.
- yjftsjthsd-h 3y ago
  There are 3rd party jira CLIs, FWIW
  - baal80spam 3y ago
    I know there are but frankly I would be afraid to use a CLI for the software I know is unreliable.
    - doix 3y ago
      The Jira API is pretty good, probably the only thing I can positively say about Jira. In a previous life I pretty much only interacted with it from the API. My workflow was: run script to automatically grab the issue I should be working on from a predefined JQL thing, create a new branch locally and spit the contents of the issue to stdout. I'd just use my email client to reply to comments. Also had a script that would parse my own format to create bugs/features with all the random extra metadata and I'd only have to write a title/description.
- deleted 3y ago
  [deleted]
cagey 3y ago
I liken Jira to a fire hydrant and each and every PM and every level of (mostly completely useless) management to a small dog that is congenitally compelled to "lift its leg on [Jira]" by "customizing" it in some way, sometimes on a nearly continuous basis. What results is a nasty smelly mess that only gets worse over time.
fnordpiglet 3y ago
Jira isn’t the problem. The problem is software estimation, managers who require a date, probability, and ever letting process people touch agile. Software estimation is basically a useless craft. Rather than focusing on when things are being delivered I think it’s much more important to focus on are things being done most efficiently right now and making sure past obstacles don’t come back. Management often requires a date of delivery for broader strategic planning - which is understandable. However they confuse precision for accuracy. The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. The joint probability of a bunch of very positively skewed distributions “and”’ed together yields a random date skewed way too early. To solve this process people were brought in to “fix” agile but creating bullshit like story points and points poker and burn down charts and pigs and chickens. Then they graft all this into Jira to improve automation, structuring, and reporting. Agile used to not be like this. Not every project of every org was well adapted to agile, and it required management that gets once you embark on a software effort there’s a lot of indeterminacy involved. Pressure to stay lean and agile should be focused on the present, that efficiency is high and decisions are made quickly, regret is addressed to ensure it doesn’t come back, etc. The future takes care of itself if you take care of the present. I also like to describe the an uncertainty principle of software development. The more you try to measure it and predict delivery the slower it is, with worse outcomes, less reliably forecasting, with more attrition and burnout.
- ohthehugemanate 3y ago
  So many +1s for you. I want to add that if the team is focusing on the present, it becomes clear that estimation is a passive, descriptive (rather than active, proscriptive) act. No ticket has time pressure on it. The manager predicts the future timeline based on how long similar tasks took in the past, on average. No idea if one task will take 5 or 15 days, but 10 of them will take about 100 days. Once you understand that, there are many very simple ways for a competent manager to get development velocity out without adding work for the developers... and all management actually wants is average velocity and remaining work in similar units. If your team tries to keep tickets about the same size, ticket throughput is your velocity. At most the devs can slap gut instinct Easy/Medium/Hard labels on the tickets so they don't have to "right size" everything. Either of those (or a thousand variants), when coupled with the pile of work left to do (in the present understanding) can give a competent manager high precision long term estimates with confidence intervals. No need to make it more complicated (or time consuming!) unless the devs tell you they NEED more. In my experience, teams that focus on the present, and which are in control of their own process (ie adding or changing only when DEVS feel the need) typically end up evolving their own agile process... which is way more effective than OOTB processes like Scrum, and doesn't feel like a burden (the team drops anything that feels like a burden). Teams who have a process imposed upon them, on the other hand, spend years ranting online about how terrible agile is, and waste a lot of time in unnecessary bullshit.
black_13 3y ago
[dead]
tetrisgm 3y ago
Yeah I hate my manager for complicated UIs, slow load times, complicated queries, lots of ways the setup can fail, and generally making everything into a complex platform rather than just putting tickets in a column. Totally not a product design problem.
- deleted 3y ago
  [deleted]
whoomp12342 3y ago
If you are a jira admin, you CAN stop people from using it incorrectly. Be an asshole with permissions. People need to EARN the right to do more than just comment and move through the workflow. That doesn't mean they have a fancy title. That means they have earned your trust through consistent good behavior.
- deleted 3y ago
  [deleted]
WesSouza 3y ago
Jira is the problem. It gives management the illusion that it can do everything, and it always get extremely messy. It is also painfully slow.
- darau1 3y ago
  > it always get extremely messy I have found having my own, personal, task management system was the foil for this. It is extra overhead, but at least I always have a system that works for me, even if everyone else is mired in chaos.
yosito 3y ago
The problem with Jira is that it's not opinionated enough about what using it "correctly" means. Every company I've ever worked for that used Jira had turned it into a giant foot gun.
- ryathal 3y ago
  I don't think being opinionated helps. TFS is extremely opinionated, and has gotten more so, but I can't say it's better. It's just as easy to make a convoluted mess that doesn't mean anything. It's only real advantage is if you use the full stack of MS stuff the integration between all the parts is really good, where Jira seems like a totally separate entity from your source control and build system. Both have their advantages though.
bearpaw 3y ago
JIRA's search feature, well, let's just say it's a real gem. Once your pile of tickets grows over the years across a delightful array of projects, attempting to find anything resembles a treasure hunt in the Bermuda Triangle. Good luck with that!
- nicwolff 3y ago
  Save and star a "Recently viewed" filter like order by lastViewed DESC and you'll at least always be able to find that ticket you were looking at earlier...
JoeAltmaier 3y ago
The use of 'No True Scotsman' for a tool is a sure sign it's not working well for many people.
arexxbifs 3y ago
I like my manager and I like our very simple workflow. I do, however, _strongly dislike_ Jira's UI. It's almost as slow and broken as Confluence's UI, and that's saying something.
OJFord 3y ago
Jira certainly has its quirks, slowness, bugs, etc. but I don't think I hate it (nor my manager). What I hate is 'stand ups', 'sprints' (even the language of it all is repulsive), pretending point estimates are in units of abstract complexity (and then having time for a certain amount of them within a fixed time period sprint), retros, .. I hate 'scrum'. (Or, because some 'Scrum Master' is going to tell me I just haven't done 'proper scrum' which I would obviously love - whatever non-Agile (manifesto sense) pretending to be 'doing agile' term you want to call it.)
- kmlx 3y ago
  > pretending point estimates are in units of abstract complexity solved this one by enforcing estimates in time duration. you can easily convert to SPs for any SP-specific metric.
  - paulryanrogers 3y ago
    I think it's supposed to go the other way. One adjusts the sprint point capacity based on recent point completion trends. The abstraction should make it harder to over promise because it's disconnected from discrete units of time. Of course it may not work well or at all. I know managers and executives still try to convert them to units of time.
    - Scarblac 3y ago
      Because they need an estimate in time units. E.g. marketing needs to plan their campaign for when the new release comes out; management needs to know whether we can finish that potential new project in the time frame the customer needs or not. Developers sometimes don't think about the rest of the business.
      - OJFord 3y ago
        It's the pretence that it's not time that I don't like - not that people try to use it for or need something for time estimations. I often find myself saying things like 'well it's trivial, but it's going to be quite a slog because xyz' - leave it up to someone else how they want to point that. E.g. every single endpoint needs to be reviewed and updated to use appropriate status codes, where previously responses have all been 200 with potential error message. API is already versioned, this will be a breaking change but no need to worry about that or the clients at all. -- low complexity, very time consuming. I suppose high complexity tasks are less often quick, or at least not that you would know in advance (optimise SQL query, identify cause if & fix bug) but certainly low complexity tasks can be very slow.
da39a3ee 3y ago
The article seems confused. It acknowledged that the problem is annoying customization of workflows by managers, but then bemoans the fact that no one has created a replacement that supports customizations. But that's the point! We don't want fucking customized workflows. Because we know that any product that offers them will end up being used by managers to create an annoying mess.
shaoner 3y ago
My company moved to Jira 2w ago and I feel the burden, it's a horrible tool. I don't care if my manager set it correctly or not. 1) What correctly means in Jira? 2) Honestly it's not a good use of all our time to learn how to use it correctly. Right now, I can't move a task to another column which gives me a non helpful generic error. Should I spend time investigating this? And yeah it's not only slow but sometimes it crashes your browser, sometimes it doesn't even load what you click on. I can't seriously understand the appeal. I would prefer anything else, including post its.
shmde 3y ago
Looking at Jiras dashboard makes me want to challenege my boss/upper mgmt to a steel cage boxing match.
indymike 3y ago
Jira is a fair-warning story for "Yes, you can customize it. Before you do, ask if you should customize it."
flkiwi 3y ago
I work at a large company that uses Jira. I had a need to create an issue tracking system for a non-IT org with a large volume of repeatable, largely repeatable tasks with an easily defined workflow and the need to track various approvals and decision points. “Perfect! I’ll reuse a tool we already have! Save everyone money, document and standardize our processes! It’ll be great!” Nope. Our instance of Jira was set up for IT projects only and could not be set up for any other workflow. I tried to work around the administrative limits only to find a mess of tags and types and requirements that demonstrated that absolutely nobody had made any effort to adopt standard taxonomies even in the IT space. It’s not a perfect tool, and there’s enough wrong with it that both the “dysfunction taints Jira” and “jira is inefficient” crowds can be right. But it really is a good enough tool that does not do nearly enough to encourage its good enough use.
lordandxavier 3y ago
For people saying there is no alternative to JIRA. Please checkout Linear https://linear.app/ https://linear.app/
- thiagovsdiniz 3y ago
  +1 Linear is the definitive tool for issue tracking.
antran22 3y ago
IMO it's not Jira's fault (although I hate Jira with a burning passion). It's the problem of management trying to force their opinionated certainty on a very uncertain process of software development. One of my past team used another lightweight Jira alternative, and even though the software does it best to keep things light, agile, PMs read the burn up chart as religiously as the Bible, then make their strategic decision based on the most optimistic estimation of the chart. Agile is great at its core, but business people ruined it. And we have craps like Agile Expert.
dahwolf 3y ago
Funny thing is that the example given of a "bad workflow" is in fact a fairly basic software development flow: 1. Ready to start (requirements and technical solution direction clear) 2. Working on it 3. Merge (to see if it also works live) 4. QA (typically dedicated role) 5. Regression testing (did we break anything?) 6. Release to Prod. 7. Sanity test on prod. You could argue that you don't need both "Ready for QA" and "In QA" but for the QA team this distinction can be of value. This doesn't even include a UX/UI sign-off, security audit, privacy review, and in my case several health-tech related audits. For a typical developer, you're only asked to move your stories/tasks from 2-4, unless you get feedback from 5-7. That's not too much to ask, it's just basic sanity. In my experience, that's not wasteful, it's a basic flow of work. What is wasteful instead is endless meetings that disrupt, of which only 10% of the content is relevant to you. What is wasteful is 5 million stakeholders asking about the status of things whilst that is the whole damn reason we have the system. What is wasteful is poorly written stories/tasks that require enormous detective work to understand. What is wasteful is constantly shifting priorities, moving work in and out of a sprint whilst it's already ongoing.
- WorldMaker 3y ago
  I think the biggest problem with tracking all of that process in a workflow engine like Jira is that a lot of it is redundant. Merge status is tracked by your pull request/merge review tools. The things available in QA testing should be known to your CD tools, your Release pipelines, and your QA environments. QA sign off should at the level of "a release", not the level of a dev task/user story. (Cherry-picking, reverts, and other types of "unmerging" create unanticipated bugs.) It's also most home directly in your Release pipelines. Same with Production sign off, sanity testing, and rollbacks to previous releases. Those are Release pipeline concerns and tracking it in Jira is at best redundant bureaucracy at that point. It shows either a lack of faith in the reporting tools of your Release pipelines or a management's devotion to Jira over the tools that actually get things done.
  - Scarblac 3y ago
    And of course managers and other stakeholders have their own Excel sheets, emails, etc. They don't use Jira, Jira is for developers.
SideburnsOfDoom 3y ago
Article says: > You don't hate Jira, You hate your micro-Manager Yeah maybe, but also: Jira is an attractive nuisance for micro-Managers. High dependence on Jira is therefor a red flag (i.e. an indication that a bad thing _might_ be happening and other indications should be checked).
not_the_fda 3y ago
It could be worse, it could be scaled agile [SAFe](https://scaledagileframework.com/ https://scaledagileframework.com/)
fnands 3y ago
Relevant OldCoderGuy video: https://www.youtube.com/watch?v=hSzlE2pM-rY https://www.youtube.com/watch?v=hSzlE2pM-rY
moribvndvs 3y ago
Points about the main problem being organizational aside, Jira has been consistently unreliable in the I’ve 10 years of using it (both hosted and self hosted). It’s a moving target. Right now, I can’t add a comment from a mobile browser (either their mobile view or requesting desktop mode) so I have to use their mobile app, which is very poor compared to the web product, especially for teams with customized screens/workflows. Their rich text editor has consistently sucked and has destructive bugs in it. Despite being logged in, it eats comments and updates all the time with various csrf or authentication errors. Tomorrow it will be something else. We use cross functional teams so it’s impossible leverage Releases to effectively coordinate releases to software that lives between multiple Jira projects. I’d rather use gitlab issues or whatever, but in an organization with lots of products, product people understandably hate those comparatively inflexible repository-based issue management. So that’s part of Jira or any issue management system is rectifying the strategic (product, project) and tactical (engineering and support). Jira's the only one that comes close (at least that I have used for any length of time) which is why it isn’t going anywhere any time soon.
Scarblac 3y ago
I disagree with the equivalence between "you don't want any manager" and "you want to hide your work". I don't want to hide my work, I just think the reason most of our managers are non-managers is because the team can manage itself. We can produce the same reports the manager can, after all we tell him what to put in them. The manager is often an unnecessary layer.
xg15 3y ago
This article reminds me a bit of the Java advocates who used to pop up in every discussion comparing programming languages and remark that, well actually, Java's reputation as a slow language full of boilerplate is wholly underserved and JVMs are in fact beating speed benchmarks left and right. And it's not wrong - you can write fast and concise Java if you are very disciplined, know exactly what you are doing and stay clear of most dependencies. However, that's hardly relevant in practice as both the language as well as the ecosystem and the established "best practices" want you to abandon both conciseness and efficiency in favour of some vague goal of extensibility. I think it's the same with Jira. Sure, you can use Jira as a simple Kanban board, but then, why would you buy a Jira license in the first place? There are cheaper tools for that. On the other hand, even if Jira advocates tell you that insanely complex workflows are wrong, all of the software is geared to supporting exactly those kinds of workflows. So if you're actually want to get your money's worth from a Jira license then you'll have to design complicated workflows and add numerous special fields.
graybeardhacker 3y ago
Anyone who says "I spend more time (documenting, entering bugs, reporting progress, etc) than doing work" is missing a key point: those things ARE the work. Writing the code is only a tiny part of being a developer. Writing a giant blob of undocumented code and jamming it into the tree is bad, m'kay. Write succinct, well documented features that are unit tested and can be traced back to a test using a bug tracker and merge easily into a code base is what we should all strive for.

98 points by zdw 3y ago

retrocryptid 3y ago

"No, it's the children who are wrong."

deleted 3y ago
[deleted]

cratermoon 3y ago

Several years back, before Jira became the software everyone loves to hate, I worked at a smallish company where the engineers had brought up local Jira instance as a sort of skunkworks project, because the bug-tracking tool the company had been using wasn't working for them. They set it up to fulfill the basic need for programmers on a team to keep track of their work. Fast forward a couple of years and it had become the company standard, replacing whatever preceded it, and the company had at least doubled in number of employees. The Jira workflows and ticket fields got the "corporate standard" makeover, including adding a field with so many values that alone it accounted for much of the increasingly poor performance. The arguments the author makes here encapsulate the evolution at my then-employer. Everything became about using an enforced process and workflow. The worst part about it was how some of the changes were enforced on all projects from the top down, meaning teams (like mine) that had a reasonably good, workable project setup had to change the way we did things, use different terms, and generally give up the working style that made use successful. Some time later, much to my chagrin, I ended up consulting at a company using something even worse than Jira: + Azure DevOps, Azure Boards, and all things Azure. These were coupled with the micromanagement and non-manager anti-patterns described in this article into a situation where developers spent more time pushing buttons and shuffling tickets arounds than writing code. The engineering manager made it clear how, to her, seeing tickets moving through the workflow on the board, on schedule was as important as working code.

sidlls 3y ago

No, I love my current manager, and really despise Jira. It’s slow, bloated, and tries to solve every project management problem and ends up solving almost none of them well.

deleted 3y ago
[deleted]

digitalsushi 3y ago

someone on here a few years back said "You dont hate Jira. You hate that it's a mirror". It meant that Jira just reflects whatever your busines management policies are and I think there is some truth in it.

t-writescode 3y ago
Nah. I hate how long it takes to load different pages. I hate the UI and how there's a bazillion non-removable fields that don't need to be filled in, but are present. I hate that you can't click on links inside Jira, but almost every real thing is actually a link, so that's unhelpful. I hate how it automagically saves changes. And many more things.
- darkstar999 3y ago
  > I hate the UI and how there's a bazillion non-removable fields that don't need to be filled in Huh? That must be configuration on your project. I haven’t experienced that.
  - jayd16 3y ago
    I hate tools that are almost always misconfigured.
Rayhem 3y ago
> You don't hate jira, you hate that it's a mirror Is this just a restatement of Conway's Law[1]? [1]: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
echelon 3y ago
Jira is like trying to use Perl in 2023. It's slow, it's clunky, it's ugly, it's bug ridden, it's unloved, and nobody understands it. May it die a quick death. Did I also mention it's slow? I think I wrote this entire comment faster than one Jira page navigation. Maybe two, if I have to be charitable.

nine_zeros 3y ago

Management _loves_ to observe and analyze tickets to death. They think that's their entire job. This is why they buy JIRA. It lets them sit back and look at charts of BS points, BS tags with little to no understanding of what the work actually means. They don't buy JIRA because it helps engineering. They couldn't care less that it takes so much of engineering time. Which leads to why engineering hates management. Because management doesn't care about engineers, why should engineers care about managers?

Zigurd 3y ago
Agile metrics is the "diet snacks" of project management, and Jira is a key enabler of that delusion.
JohnBooty 3y ago
Management _loves_ to observe and analyze tickets to death. They think that's their entire job. At my last job they made a lot of noise about valuing collaboration, mentorship, career development, etc. But after layoffs, it was revealed that management literally just counted up Jira tickets to measure developer productivity. So any time you had spent helping others was essentially just time you spent destroying your own performance ratings. ¯\_(ツ)_/¯
- nine_zeros 3y ago
  And when they don't reveal transparently what they use to measure, engineers feel the gaslight burning and stop complying. Then manager asks, "What's wrong?" Management is an utter bane of the tech industry.
deleted 3y ago
[deleted]

000ooo000 3y ago

I hate them both!

deleted 3y ago
[deleted]

db48x 3y ago

No, there is room in my heart to hate both.

deleted 3y ago
[deleted]

tekla 3y ago

Nope. My manager is great. Jira just really really really sucks

deleted 3y ago
[deleted]

waffletower 3y ago

I really really like my manager. She hates Jira. I also hate Jira. (She's married to someone else so I ought not to say that I love her)

deleted 3y ago
[deleted]
Minor49er 3y ago
Of all the types of tickets that Jira could be configured to handle, it sadly cannot track nor measure the open issue of this hopeless office romance

satisfice 3y ago

This is a pretty good article. But it uncritically swallows the idea that the only way to have reasonable transparency is through atomizing work into trackable to-do items. I do successful work of all kinds with clients and collaborators and never come near a Jira.

somewhereoutth 3y ago
It's a 'remembering' tool - but 'forgetting' is also a valid and productive activity. Some things should be remembered, e.g. important bugs, but other things quite often benefit from being forgotten, like irrelevant feature requests. It is surprising how many problems can be solved by simply ignoring them - the trick of course is knowing which ones to ignore. To-do lists tend to preclude this strategy entirely though.
dasil003 3y ago
This is a keen observation and 100% true. A lot of people (both engineers and managers) willingly align behind this regime because the system gives them ostensible clarity on what they need to do, and a paper trail to show how hard they've been working as air cover if anything goes wrong. They are optimizing for comfort and covering their own asses. Unfortunately, this puts a very low ceiling on the type of problems that can be solved. In fact, it works against creative problem solving because it obfuscates the big picture by drowning out the strategic summaries and narratives needed at different zoom levels for different stakeholders. The devil is in the details, and the only way to get the details right is to have real expertise and collaboration based on higher level understanding. Ideally every individual involved has the highest level goal they are capable of executing on, and is empowered to work out the details collaboratively with whoever needs to be involved. This is easier said than done, because most people—even experts in specific domains and skillsets—are not experts in collaboration and understanding other people's mental models. Management's job, if they are doing it correctly, is to understand these dynamics (hopefully rooted in deep hands-on expertise) and to set up the structure that facilitates the necessary collaboration. Useful tooling for this problem is context specific, but less is usually more nuanced messaging or vision doesn't travel or align well across large groups of people. Jira does nothing to help with this; it's just not built for strategic planning or collaboration. It shines for tracking a huge influx of unrelated tasks that have to be passed around between silo'ed teams without dropping any balls. This allows project managers and operations folks to monitor things mechanically where the problem and process is already well understood. It offers very little to support higher-level problem solving.

fouc 3y ago

First time I used Jira I was lucky that the company had it setup quite nicely. I really enjoyed it. One of the things I really enjoy about Jira is the fact that a task and a sub-task have the exact same UI. A sub-task can be easily moved to be a full task and vice versa.

lloeki 3y ago
"Hey this PROJ-1234 task is in fact a subtask of PROJ-1111!" "Agreed! let's move it to be a subtask of PROJ-1111! and here's a new PROJ-1235 for the second part, let's make it a subtask as well" "Wait, I can't make PROJ-1234 a subtask of PROJ-1111..." "Ah, I see, PROJ-1111 is already a subtask of PROJ-1002, which indeed makes sense" "Oh, right! I forgot subtasks can't be nested. So maybe PROJ-1002 is an epic?" "Sounds about right! Oh wait, PROJ-1002 is part of epic PROJ-223" "Oh. I get it now, forgot about that epic which tracks things for product item foo" "Alright, is foo still on track and required?" "Yeah, it's merely been postponed because the currently worked on project item bar was priorised as we needed a bit more work to refactor and complete foo" "So now we're set to do PROJ-1234 in the current sprint, and this would complete both foo and bar, two birds one stone!" "Yeah that was the plan all along, having the design lend itself to that, with proper composition and all." "But we can't make it part of both epics" "Correct." "What if we create a new task and link it with PROJ-1234" "Could work. How do we qualify it though? It's "duplicated by" but we keep that for duplicate bug reports as there are automated workflows for it, notably a duplicate is supposed to be closed." "Blocked by maybe?" "Well it's kind of bidirectional and blocked by is one direction only" "Drat there's no "Linked to" in the combo box" "Yeah management wants everything qualified so that they can build reports. IIRC they don't scope it by kind "bug" because marking some tasks as bugs biases another counter, so some bugs stay as tasks, so they can count only bugs reported by customers and not internal bugs" "Oh right, doubles down on why we can't use duplicate, we'd break the report. Actually I think we can't use the link feature at all because it's really the same task and that'd break their report too" "Screw it let's just put a link on each one's description to the other. I'll shoot an email to the JIRA admin to see if we can add more link kinds, and maybe fix the automations and reports" "Yeah, we're already overtime for that sprint planning anyway. Let's move." "Should we do that at the PROJ-1234 level or at the PROJ-1111 level?" "Not too sure. Maybe we should have used a checklist for PROJ-1111" "But then PROJ-1478 depends on PROJ-1234 only, not PROJ-1111 as a whole" "Ah, right. Maybe we cleaned up the arch a bit too much lol" "Right? Maybe we should switch to an arch that matches how we can link tickets lolsob" "JDD: JIRA driven development" "Hold my beer while I write a JIRA plugin to export task structure as a code scaffold" "Kill me right now" "Goddammit time flies, let's finish this. So where are we on PROJ-1526?" "Blocked, we're waiting on feedback from the user" "Alright. Wait, there are two "Waiting on customer" statuses now? Which one is it?" "Huh. Let me look at the browser inspector... Ok, id 17, so I think it's the second one. No idea where the other one comes from." "Ha. Ok, moving on." Slack pings > Hey, meeting xyz has started 10min ago, are you joining? "Drat"

natch 3y ago

I like my manager and I like Jira mostly, though it can definitely be set up poorly and search could be made more approachable.

deleted 3y ago
[deleted]

danrl 3y ago

No, I really do not like Jira. My manager great.

deleted 3y ago
[deleted]

Zigurd 3y ago

In the majority of my consulting engagements, the client is using Jira. I don't think the permissions for my account have ever been right on the first day.

softwaredoug 3y ago

Jira is the union of all TPS reports. Between every PM, every manager, etc, everyone wants to track slightly different information. The ICs can't keep up - they have five people telling them to use Jira just a little bit differently. The bosses/PMs don't feel this tension, they see only their asks, their report they want to stay up to date, they wonder why its so hard. Eventually, ICs see it as confusing hassle (like TPS reports in Office Space). ICs don't know what to do, and everyone gets confused, information doesn't actually surface in Jira, real issues get dropped on the floor, etc etc The problem isn't that any one of those bits of reporting is wrong. It's actually that the higher levels need to realize they're actually asking for different / conflicting / excessive information and need to have a stronger hand in reducing information reported so to ensure that which is there is actually accurate. (The insane configurability of Jira and other PM tools just reflects this chaos)

ggm 3y ago

I don't hate jira or my manager. I do dislike the misapplication of jira as a tool to problems by rote, and I dislike some of the consequences my manager accepts to achieve his KPIs. Managers and Jira have their place. It depends on context and scale of problem amongst other things. I can imagine a tool like jira helping prevent a space shuttle disaster, and I can imagine a tool like jira not preventing it. I can imagine a manager preventing, and not preventing a doomed launch. I can imagine a 2D grid of jria and no jira, manager and no manager and every single square can have "maybe, maybe not" inside it.

deleted 3y ago
[deleted]

hprotagonist 3y ago

> The most common reasons I hear for hating on JIRA are “because it’s slow as balls” is conspicuously absent as the first reason!

deleted 3y ago
[deleted]

niedzielski 3y ago

I encouraged our IT team to try Trello (now owned by the same company, Atlassian) which sports a JIRA integration[0]. Either due to the fundamental limitations of the integration or a botched setup, it's useless. There seems to be two copies of each ticket (one JIRA, one Trello) that can be in different states. It was not just another UI for the same underlying data. I do hate JIRA. JIRA adds all the beauty of a government bureaucracy to what should be post-it note management. It's hard to overstate how demotivating JIRA is to my work and especially to my planning. Worse, everyone in the organization has to use it. [0]: https://blog.trello.com/jira-trello-intregration https://blog.trello.com/jira-trello-intregration

LelouBil 3y ago
I'm not sure JIRA is meant to be "post-it note management."
WorldMaker 3y ago
I miss Trello sometimes. The Atlassian merger killed most of its old spark, and on top of that the micro-managers of Jira at my company wound up eating my old Trello account (because Atlassian decided to merge accounts on email address, which was dumb) destroying a lot of data in the process, and then decided to turn off Trello entirely (and block it). I'm much more of a Kanban sort. Jira is awful at Kanban. Trello was great. We migrated some of our Trello boards to Microsoft Planner (inside Teams), which is a laughable joke. Then eventually to Jira because Jira is an inescapable black hole and "oversight" from the micro-managers matters more than getting projects done on time.

somewhereoutth 3y ago

A ticket for each bug or new feature, with commentary including images and videos as necessary, linking to consequent code commits, with a not-done/under-review/complete status field, raised by the reporter, assigned to the responsible person, and indicating the target release. That is the essence of a good workflow tool, and Jira will do it fine. It is all the extra stuff that seems to cause the grief.

MBCook 3y ago
Exactly. I’ve used it like that. It’s great. But at other companies I’ve been at, it’s not a productivity tool. It’s a management too. Estimates for planning. Which is fine. Until pointless rules appear. We’ll use standard story points. But not 1, that’s too small. So things start at 2. But after a while that’s too small. So they start at 3. But you can’t go over 8, past that they have to be split. And you shouldn’t probably use 8 anyway. Pretty soon everything will be 5s. No matter how big or small. Good thing we point. And of course the whole point of pointing is to put things in sprints. That’s fine. But then the rules come. You can’t go over your capacity. You can’t go below your capacity. You have to roll over everything you didn’t do. You can’t roll things over. We committed to finish by Junetober 37th even if we’re not ready so it has to go in the sprint now. So now you put things into the sprint after the sprint started and remove things before it’s over so that the magic numbers look correct even though they are complete BS. But luckily you can track things. Except every team is forced to use the same workflow even if they don’t work the same way. Because otherwise it would be “complicated“. So the IT tickets have to look like software development tickets. And the planning tickets have to look like software development tickets. It’s important to have tickets to plan your future plans so you know what tickets to make. After all, if you don’t schedule everything 18 months in advance to the day, are you really doing agile sprints? But you can link tickets. For example you can choose requires, or needs, or is dependent upon, or can’t be done without, or is waiting on. Wouldn’t one thing do for all of that? No one actually knows. It’s an unanswerable question. Did I mention there’s Kanban support? You’re not allowed to use that. Because. And all this gets so complicated you need people whose job it is to wrangle Jira full-time. Make reports, add more fields, etc. Of course those fields don’t make sense in a lot of cases. But sometimes they required. And other teams want them required but aren’t allowed to because everyone has to work the same way. So the ZRX team invents their own email gateway to put issues into Jira their way. You didn’t know about that right? Because if you add the issue directly they’ll ignore it. Productivity! I don’t know if it’s fair to call the thing I used at those companies “Jira”. That’s a bit like calling a battery made out of a box full of potatoes a “vegetable medley”. I mean it’s sort of true but that’s not the point anymore is it? I like actual Jira. It’s a good product. Too bad almost no company will let you use it, only corruptions. It doesn’t exist to do its real job but to instead generate management reports. Which they don’t read. Poor Jira.

xwowsersx 3y ago

My biggest complaint with all of the Atlassian tools I use (Jira, Confluence, etc.) is how slow and unresponsive they feel. Creating a new Issue requires waiting at least a few seconds, sometimes more, for the newly created Issue to pop up on the bottom left. Editing a Confluence doc requires clicking the edit button and waiting a few seconds while the entire page does, what appears to be, some massive shift to editing mode (understandable that there would be big differences between read and write mode, that's not my issue). I think my perception of and feeling towards the Atlassian tools I use would be, no exaggeration, 10x more positive if everything just felt zippy and close to instantaneous. "Speed is a feature", or however the aphorism goes. Also, I'd be remiss if I didn't link to https://ifuckinghatejira.com/ https://ifuckinghatejira.com/ (for the lulz)

tails4e 3y ago
We use confluence and jira, an d for some reason it seems perfectly usable compared to others stories here. It's not a small organization either, so I wonder if it's some misconfiguration that's killing performance for others?
- xwowsersx 3y ago
  That's quite possible! I'd love to know what it is. If it's somehow a consequence of the total number and age of stories since our account's beginning, I'm not sure what we could really do about that other than to do bulk deleting which...we really don't want to do.
- _s 3y ago
  Have you used other tools like linear? The performance difference is striking. Atlassian tools are decent enough, and mostly usable is how I'd describe them. I'd take anything else though, even Rally.
  - xwowsersx 3y ago
    I have. Linear is great, although I didn't use it as extensively as Jira. Wish we could use it.

re-thc 3y ago

Jira is my real manager!

deleted 3y ago
[deleted]

brailsafe 3y ago

In my last job, I definitely hated my manager and how they used Jira, but I actually liked Jira for the most part. What I hated about Jira was that it allowed my manager to decide on an expectation for how it should be used, and though technically it did do that, it didn't enable me to use it in a way that aligned with their idea of how it should be used. It frustrated him that I didn't accept the guilt he was trying to throw at me for not using the tool in the way he decided was important. Also, it suffered from the same problems as any isolated tool; being out of sync with other tools and invisible unless I'm looking directly at it. I never really got the unresponsiveness that others mention, even on an intel MacBook pro. What I like about Jira technically, is that it has a pretty decent rich media interface for expressing ideas. If I found a bug, or needed to document how something currently works, I could use the native screen recording on my mac and then drag the video file straight into the comment. It would have been great if my manager wasn't a petulant, controlling, and passive-aggressive tool, so that I could use Jira in a way that better suited the development process.

lampshades 3y ago

I hate Jira and I hate managers.

deleted 3y ago
[deleted]

colechristensen 3y ago

No, I hate Jira. It takes an impressive amount of experience, self control, and perspective for the management and product types to not take full advantage of the kind of absurd abuse Jira enables. Jira gives people bad ideas and makes them think they’re supposed to do things that way. Jira encourages bad behavior. I don’t hate addicts for being addicts. People with not enough to do find things to do and with jira around those things are “bothering developers with ever increasing process”, it is indeed the tool’s fault.

deleted 3y ago
[deleted]

po 3y ago

Jira is like the `extends` keyword in Java... It makes it way too easy to create huge hierarchies of classes that then take tons of additional tooling to refactor. Sure you can have a simple process in Jira... but it will be constantly whispering into the ears of you and your coworkers, "wouldn't you like to have an approval step for that? I can easily add one here... How about we add another state that this issue can be in? Then we can hide those issues from this alternate view over here..." Jira ossifies your company process in concrete which feels great when you first build it but then agility becomes a struggle. You don't even notice it at first but slowly over time your company will fight to get things done outside of the process. You'll then spend so much of your time adapting Jira to reality, you'll wonder what the point of it is. So yeah, you hate your manager who is mostly just trying to use the best tool for the job, and bought the most commonly used and well regarded tool for it... but that tool is encouraging them to build a giant mess.

rco8786 3y ago

Nah I hate Jira lol. Or else I’ve hated all of my managers and that’s definitely not the case.

deleted 3y ago
[deleted]

theultdev 3y ago

No, me and my manager switched off Jira a long time ago because we hated it

deleted 3y ago
[deleted]

soudiere 3y ago

Nope, definitely hate Jira.

deleted 3y ago
[deleted]

jchw 3y ago

No, I hate Jira. I tried using it at home, too, back when they offered licenses for mere mortals. It's slow, the UI is weird and full of old and new stuff that totally mismatches, I hate the API, etc. Maybe some of it has improved, but when it got its reputation, it sucked. I absolutely prefer Linear no matter the manager, and it's not even perfect.

deleted 3y ago
[deleted]

cebert 3y ago

I work in a fairly large S&P 500 company that uses JIRA to manage most of our software projects. While I do agree that the performance of JIRA can leave a bit to desire at times, I don’t feel the same animosity towards it as many seem to. Since we also use GitHub Enterprise, I’d personally prefer to use GitHub for issue management but I can live with JIRA. Perhaps I’m just fortunate to work under leaders who don’t force a lot of overburdening JIRA processes. At my work each team can setup their JIRA project and workflows, boards, etc. in a manner that makes most sense for them. Teams can use hours or story points, kanban or scrum. The focus is on delivering features and quality (in terms of customer reported open CRM issues not JIRA issue counts). I feel like management is pretty transparent on how they use JIRA and what their expectations are. My boss and their boss openly share with us what they look for in terms of team project health. I feel like anyone on my team could suggest a reasonable JIRA process change and it would be considered.

igetspam 3y ago
> I’d personally prefer to use GitHub for issue management but I can live with JIRA. No, you wouldn't. I promise. You'd spend months fucking around with GitHub Projects, hoping you could figure out how to unclusterfuck it and you'd miss Jira. It's not good enough. I didn't know how much I actually didn't hate Jira until I worked at a company that tried every other option. They all suck. Jira sucks less.
fatnoah 3y ago
> The focus is on delivering features and quality In my first month as VP at a growth stage startup, I asked everyone in Engineering why we used Jira. The responses all boiled down to what was basically a shrug. I followed up with what they felt we should use it for and the universal answer was just to be a scrum board, so I spent a bunch of time removing fields and nearly all workflow steps and rules enforcement except in cases where a particular team wanted them. This ruffled a few feathers of folks who loved making tools do all the work, but the improved QoL and happiness the team at made any objections moot. Similarly,I asked all the external stakeholders what they wanted out of the Engineering team, and the common answer was regular delivery of features and products. So now that's what we're optimizing our process around, and (not a surprise) that's been more of a "make the product team focus on fewer things", reduce architectural debt, and automate more things kind of effort. Now, estimation is still a big part of this, but it's used mostly for capacity planning and to gauge the effectiveness of efficiency related efforts.

kstrauser 3y ago

I agree. I’ve said Jira is a code smell. It doesn’t automatically mean an engineering department is broken, but I’ve personally never seen a counterexample. My problem is that the wrong kind of manager takes to Jira like a lab monkey to meth. You don’t have to use it to build a development process that makes reporting happy but devs sad, and yet that’s what always seems to happen. And if you’re willing to use Jira with its defaults and not as an inner platform, why not pick something that devs actually like to use? For instance, my coworkers think Linear is great.

sharts 3y ago

No, we actually do hate jira. Having to open a browser load a heavyweight page and then fill out various fields on multiple forms on just to enter some text is stupid. It would actually make it less annoying to use if it was some kind of CLI/TUI. Like in the old days of mainframes when you’d talk to a receptionist to schedule an appointment or register for classes and they’d be typing away on a colorful/neon terminals. It doesn’t need to be vim like. But it definitely shouldn’t be what it is today —which is a tool for geriatrics and designed by literal clowns.

yjftsjthsd-h 3y ago
There are 3rd party jira CLIs, FWIW
- baal80spam 3y ago
  I know there are but frankly I would be afraid to use a CLI for the software I know is unreliable.
  - doix 3y ago
    The Jira API is pretty good, probably the only thing I can positively say about Jira. In a previous life I pretty much only interacted with it from the API. My workflow was: run script to automatically grab the issue I should be working on from a predefined JQL thing, create a new branch locally and spit the contents of the issue to stdout. I'd just use my email client to reply to comments. Also had a script that would parse my own format to create bugs/features with all the random extra metadata and I'd only have to write a title/description.
deleted 3y ago
[deleted]

cagey 3y ago

I liken Jira to a fire hydrant and each and every PM and every level of (mostly completely useless) management to a small dog that is congenitally compelled to "lift its leg on [Jira]" by "customizing" it in some way, sometimes on a nearly continuous basis. What results is a nasty smelly mess that only gets worse over time.

fnordpiglet 3y ago

Jira isn’t the problem. The problem is software estimation, managers who require a date, probability, and ever letting process people touch agile. Software estimation is basically a useless craft. Rather than focusing on when things are being delivered I think it’s much more important to focus on are things being done most efficiently right now and making sure past obstacles don’t come back. Management often requires a date of delivery for broader strategic planning - which is understandable. However they confuse precision for accuracy. The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. The joint probability of a bunch of very positively skewed distributions “and”’ed together yields a random date skewed way too early. To solve this process people were brought in to “fix” agile but creating bullshit like story points and points poker and burn down charts and pigs and chickens. Then they graft all this into Jira to improve automation, structuring, and reporting. Agile used to not be like this. Not every project of every org was well adapted to agile, and it required management that gets once you embark on a software effort there’s a lot of indeterminacy involved. Pressure to stay lean and agile should be focused on the present, that efficiency is high and decisions are made quickly, regret is addressed to ensure it doesn’t come back, etc. The future takes care of itself if you take care of the present. I also like to describe the an uncertainty principle of software development. The more you try to measure it and predict delivery the slower it is, with worse outcomes, less reliably forecasting, with more attrition and burnout.

ohthehugemanate 3y ago
So many +1s for you. I want to add that if the team is focusing on the present, it becomes clear that estimation is a passive, descriptive (rather than active, proscriptive) act. No ticket has time pressure on it. The manager predicts the future timeline based on how long similar tasks took in the past, on average. No idea if one task will take 5 or 15 days, but 10 of them will take about 100 days. Once you understand that, there are many very simple ways for a competent manager to get development velocity out without adding work for the developers... and all management actually wants is average velocity and remaining work in similar units. If your team tries to keep tickets about the same size, ticket throughput is your velocity. At most the devs can slap gut instinct Easy/Medium/Hard labels on the tickets so they don't have to "right size" everything. Either of those (or a thousand variants), when coupled with the pile of work left to do (in the present understanding) can give a competent manager high precision long term estimates with confidence intervals. No need to make it more complicated (or time consuming!) unless the devs tell you they NEED more. In my experience, teams that focus on the present, and which are in control of their own process (ie adding or changing only when DEVS feel the need) typically end up evolving their own agile process... which is way more effective than OOTB processes like Scrum, and doesn't feel like a burden (the team drops anything that feels like a burden). Teams who have a process imposed upon them, on the other hand, spend years ranting online about how terrible agile is, and waste a lot of time in unnecessary bullshit.

black_13 3y ago

[dead]

tetrisgm 3y ago

Yeah I hate my manager for complicated UIs, slow load times, complicated queries, lots of ways the setup can fail, and generally making everything into a complex platform rather than just putting tickets in a column. Totally not a product design problem.

deleted 3y ago
[deleted]

whoomp12342 3y ago

If you are a jira admin, you CAN stop people from using it incorrectly. Be an asshole with permissions. People need to EARN the right to do more than just comment and move through the workflow. That doesn't mean they have a fancy title. That means they have earned your trust through consistent good behavior.

deleted 3y ago
[deleted]

WesSouza 3y ago

Jira is the problem. It gives management the illusion that it can do everything, and it always get extremely messy. It is also painfully slow.

darau1 3y ago
> it always get extremely messy I have found having my own, personal, task management system was the foil for this. It is extra overhead, but at least I always have a system that works for me, even if everyone else is mired in chaos.

yosito 3y ago

The problem with Jira is that it's not opinionated enough about what using it "correctly" means. Every company I've ever worked for that used Jira had turned it into a giant foot gun.

ryathal 3y ago
I don't think being opinionated helps. TFS is extremely opinionated, and has gotten more so, but I can't say it's better. It's just as easy to make a convoluted mess that doesn't mean anything. It's only real advantage is if you use the full stack of MS stuff the integration between all the parts is really good, where Jira seems like a totally separate entity from your source control and build system. Both have their advantages though.

bearpaw 3y ago

JIRA's search feature, well, let's just say it's a real gem. Once your pile of tickets grows over the years across a delightful array of projects, attempting to find anything resembles a treasure hunt in the Bermuda Triangle. Good luck with that!

nicwolff 3y ago
Save and star a "Recently viewed" filter like order by lastViewed DESC and you'll at least always be able to find that ticket you were looking at earlier...

JoeAltmaier 3y ago

The use of 'No True Scotsman' for a tool is a sure sign it's not working well for many people.

arexxbifs 3y ago

I like my manager and I like our very simple workflow. I do, however, _strongly dislike_ Jira's UI. It's almost as slow and broken as Confluence's UI, and that's saying something.

OJFord 3y ago

Jira certainly has its quirks, slowness, bugs, etc. but I don't think I hate it (nor my manager). What I hate is 'stand ups', 'sprints' (even the language of it all is repulsive), pretending point estimates are in units of abstract complexity (and then having time for a certain amount of them within a fixed time period sprint), retros, .. I hate 'scrum'. (Or, because some 'Scrum Master' is going to tell me I just haven't done 'proper scrum' which I would obviously love - whatever non-Agile (manifesto sense) pretending to be 'doing agile' term you want to call it.)

kmlx 3y ago
> pretending point estimates are in units of abstract complexity solved this one by enforcing estimates in time duration. you can easily convert to SPs for any SP-specific metric.
- paulryanrogers 3y ago
  I think it's supposed to go the other way. One adjusts the sprint point capacity based on recent point completion trends. The abstraction should make it harder to over promise because it's disconnected from discrete units of time. Of course it may not work well or at all. I know managers and executives still try to convert them to units of time.
  - Scarblac 3y ago
    Because they need an estimate in time units. E.g. marketing needs to plan their campaign for when the new release comes out; management needs to know whether we can finish that potential new project in the time frame the customer needs or not. Developers sometimes don't think about the rest of the business.
    - OJFord 3y ago
      It's the pretence that it's not time that I don't like - not that people try to use it for or need something for time estimations. I often find myself saying things like 'well it's trivial, but it's going to be quite a slog because xyz' - leave it up to someone else how they want to point that. E.g. every single endpoint needs to be reviewed and updated to use appropriate status codes, where previously responses have all been 200 with potential error message. API is already versioned, this will be a breaking change but no need to worry about that or the clients at all. -- low complexity, very time consuming. I suppose high complexity tasks are less often quick, or at least not that you would know in advance (optimise SQL query, identify cause if & fix bug) but certainly low complexity tasks can be very slow.

da39a3ee 3y ago

The article seems confused. It acknowledged that the problem is annoying customization of workflows by managers, but then bemoans the fact that no one has created a replacement that supports customizations. But that's the point! We don't want fucking customized workflows. Because we know that any product that offers them will end up being used by managers to create an annoying mess.

shaoner 3y ago

My company moved to Jira 2w ago and I feel the burden, it's a horrible tool. I don't care if my manager set it correctly or not. 1) What correctly means in Jira? 2) Honestly it's not a good use of all our time to learn how to use it correctly. Right now, I can't move a task to another column which gives me a non helpful generic error. Should I spend time investigating this? And yeah it's not only slow but sometimes it crashes your browser, sometimes it doesn't even load what you click on. I can't seriously understand the appeal. I would prefer anything else, including post its.

shmde 3y ago

Looking at Jiras dashboard makes me want to challenege my boss/upper mgmt to a steel cage boxing match.

indymike 3y ago

Jira is a fair-warning story for "Yes, you can customize it. Before you do, ask if you should customize it."

flkiwi 3y ago

I work at a large company that uses Jira. I had a need to create an issue tracking system for a non-IT org with a large volume of repeatable, largely repeatable tasks with an easily defined workflow and the need to track various approvals and decision points. “Perfect! I’ll reuse a tool we already have! Save everyone money, document and standardize our processes! It’ll be great!” Nope. Our instance of Jira was set up for IT projects only and could not be set up for any other workflow. I tried to work around the administrative limits only to find a mess of tags and types and requirements that demonstrated that absolutely nobody had made any effort to adopt standard taxonomies even in the IT space. It’s not a perfect tool, and there’s enough wrong with it that both the “dysfunction taints Jira” and “jira is inefficient” crowds can be right. But it really is a good enough tool that does not do nearly enough to encourage its good enough use.

lordandxavier 3y ago

For people saying there is no alternative to JIRA. Please checkout Linear https://linear.app/ https://linear.app/

thiagovsdiniz 3y ago
+1 Linear is the definitive tool for issue tracking.

antran22 3y ago

IMO it's not Jira's fault (although I hate Jira with a burning passion). It's the problem of management trying to force their opinionated certainty on a very uncertain process of software development. One of my past team used another lightweight Jira alternative, and even though the software does it best to keep things light, agile, PMs read the burn up chart as religiously as the Bible, then make their strategic decision based on the most optimistic estimation of the chart. Agile is great at its core, but business people ruined it. And we have craps like Agile Expert.

dahwolf 3y ago

Funny thing is that the example given of a "bad workflow" is in fact a fairly basic software development flow: 1. Ready to start (requirements and technical solution direction clear) 2. Working on it 3. Merge (to see if it also works live) 4. QA (typically dedicated role) 5. Regression testing (did we break anything?) 6. Release to Prod. 7. Sanity test on prod. You could argue that you don't need both "Ready for QA" and "In QA" but for the QA team this distinction can be of value. This doesn't even include a UX/UI sign-off, security audit, privacy review, and in my case several health-tech related audits. For a typical developer, you're only asked to move your stories/tasks from 2-4, unless you get feedback from 5-7. That's not too much to ask, it's just basic sanity. In my experience, that's not wasteful, it's a basic flow of work. What is wasteful instead is endless meetings that disrupt, of which only 10% of the content is relevant to you. What is wasteful is 5 million stakeholders asking about the status of things whilst that is the whole damn reason we have the system. What is wasteful is poorly written stories/tasks that require enormous detective work to understand. What is wasteful is constantly shifting priorities, moving work in and out of a sprint whilst it's already ongoing.

WorldMaker 3y ago
I think the biggest problem with tracking all of that process in a workflow engine like Jira is that a lot of it is redundant. Merge status is tracked by your pull request/merge review tools. The things available in QA testing should be known to your CD tools, your Release pipelines, and your QA environments. QA sign off should at the level of "a release", not the level of a dev task/user story. (Cherry-picking, reverts, and other types of "unmerging" create unanticipated bugs.) It's also most home directly in your Release pipelines. Same with Production sign off, sanity testing, and rollbacks to previous releases. Those are Release pipeline concerns and tracking it in Jira is at best redundant bureaucracy at that point. It shows either a lack of faith in the reporting tools of your Release pipelines or a management's devotion to Jira over the tools that actually get things done.
- Scarblac 3y ago
  And of course managers and other stakeholders have their own Excel sheets, emails, etc. They don't use Jira, Jira is for developers.

SideburnsOfDoom 3y ago

Article says: > You don't hate Jira, You hate your micro-Manager Yeah maybe, but also: Jira is an attractive nuisance for micro-Managers. High dependence on Jira is therefor a red flag (i.e. an indication that a bad thing _might_ be happening and other indications should be checked).

not_the_fda 3y ago

It could be worse, it could be scaled agile [SAFe](https://scaledagileframework.com/ https://scaledagileframework.com/)

fnands 3y ago

Relevant OldCoderGuy video: https://www.youtube.com/watch?v=hSzlE2pM-rY https://www.youtube.com/watch?v=hSzlE2pM-rY

moribvndvs 3y ago

Points about the main problem being organizational aside, Jira has been consistently unreliable in the I’ve 10 years of using it (both hosted and self hosted). It’s a moving target. Right now, I can’t add a comment from a mobile browser (either their mobile view or requesting desktop mode) so I have to use their mobile app, which is very poor compared to the web product, especially for teams with customized screens/workflows. Their rich text editor has consistently sucked and has destructive bugs in it. Despite being logged in, it eats comments and updates all the time with various csrf or authentication errors. Tomorrow it will be something else. We use cross functional teams so it’s impossible leverage Releases to effectively coordinate releases to software that lives between multiple Jira projects. I’d rather use gitlab issues or whatever, but in an organization with lots of products, product people understandably hate those comparatively inflexible repository-based issue management. So that’s part of Jira or any issue management system is rectifying the strategic (product, project) and tactical (engineering and support). Jira's the only one that comes close (at least that I have used for any length of time) which is why it isn’t going anywhere any time soon.

Scarblac 3y ago

I disagree with the equivalence between "you don't want any manager" and "you want to hide your work". I don't want to hide my work, I just think the reason most of our managers are non-managers is because the team can manage itself. We can produce the same reports the manager can, after all we tell him what to put in them. The manager is often an unnecessary layer.

xg15 3y ago

This article reminds me a bit of the Java advocates who used to pop up in every discussion comparing programming languages and remark that, well actually, Java's reputation as a slow language full of boilerplate is wholly underserved and JVMs are in fact beating speed benchmarks left and right. And it's not wrong - you can write fast and concise Java if you are very disciplined, know exactly what you are doing and stay clear of most dependencies. However, that's hardly relevant in practice as both the language as well as the ecosystem and the established "best practices" want you to abandon both conciseness and efficiency in favour of some vague goal of extensibility. I think it's the same with Jira. Sure, you can use Jira as a simple Kanban board, but then, why would you buy a Jira license in the first place? There are cheaper tools for that. On the other hand, even if Jira advocates tell you that insanely complex workflows are wrong, all of the software is geared to supporting exactly those kinds of workflows. So if you're actually want to get your money's worth from a Jira license then you'll have to design complicated workflows and add numerous special fields.

graybeardhacker 3y ago

Anyone who says "I spend more time (documenting, entering bugs, reporting progress, etc) than doing work" is missing a key point: those things ARE the work. Writing the code is only a tiny part of being a developer. Writing a giant blob of undocumented code and jamming it into the tree is bad, m'kay. Write succinct, well documented features that are unit tested and can be traced back to a test using a bug tracker and merge easily into a code base is what we should all strive for.