To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it.
It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process.
tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it gets taken for the central thing. This is an illusion. Fixing a bug without filing a JIRA ticket is in itself progress. Moving a JIRA card without any other change is not. Yet the second is what's visible and therefor what's rewarded.
Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host.
In case the cancer metaphor didn't make it very clear, I don't like JIRA much. Yet if JIRA were to die today, the middle management who live by JIRA would replace it with something else equally bad, if not worse.
Filling in missing features won't and can't fix that.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money. And developers are expensive as hell.
And I've also never worked anywhere that had a better option than JIRA.
Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with technical details, I probably spam the whole team with lots of "Ticket was edited" notifications because there is no logic to Atlassian's markup systems.
I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true.
</rant>
And as someone who enjoys documenting their own work for fellow developers and other roles, I don't even think Jira helps. Most discussions will still happen offline and without documentation, especially from non-technical roles who hate typing.
> I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true.
I kinda feel this way about every project management tool, be it a personal or professional one. You're always chasing the dragon for how clean it was when you originally configured it.
From a dev perspective, I see your point. Redmine was great for the reason that we documented a lot better inside tickets because it was lower friction.
My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.
That would be great. On a client project a few years ago I effectively bullied the product owner into doing that.
We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and we can do task estimation as a team and assign them, and so on. But most of them were tasks that would take a few minutes at most. (Some of the problems I fixed live while working with the designer). Our launch deadline was fast approaching and it would have taken more time to write a good jira ticket than it would to fix most of the issues - let alone discussing them as a group to estimate. While arguing he ended up showing his cards by admitting that the main reason he wanted everything in jira was for reporting. How else would upper management know that we were making progress? I said that sounded like his job, not mine. And he begrudgingly agreed and took my plain text list and dutifully retyped everything one by one into jira tickets. And then marked them all complete a week later when I’d fixed them all.
I think that experience killed the last bit of respect I had for Agile as a methodology - at least as it’s practiced in the wild. If we were using something lighter - like trello - I don’t think I would have resisted so much.
Great story, but re the “killed respect for Agile” bit:
Agile done right is all about less process. It’s right there on the Agile Manifesto:
> Individuals and interactions over processes and tools
I’d also read https://agilemanifesto.org/principles.html for an illustration of what is considered valuable — especially the bit about simplicity which process heavy (aka fake-agile) agile consultants totally miss; also the bits about what constitutes project progress & how to most efficiently convey information.
You should be able to tailor your agile processes to what makes sense for you. Following the herd and insisting on agile ceremonies “because everyone else does it / someone told us to”, even to your team’s detriment, is cargo-culting.
In your case you clearly tailored your process to something that improved your efficiency and met your reporting requirements, so, as far as I’m concerned, you’re doing agile “right”.
Oh, I’ve read all that. But I feel like there’s two agile methodologies - one that the authors intended, a lightweight adaptive attitude where you ground out your process based on what works with your team. And then there’s Agile: The Process as prescribed by agile consultants who go to agile seminars. This agile insists on daily standup, point based estimation, velocity tracking, jira (for some reason), etc. Otherwise you are Doing Agile Wrong, and you will be cast off the holy mountain.
I get the sense the authors of agile used words like “scrum” because they imagine software development like a full contact sport; where everyone is fully engaged with all their senses to truly be aware of what’s happening, what’s needed and what is the most important thing to work on. The cargo culting agile consultant approach always feels like an attempt to make software into a repeatable assembly line, and make software engineers into factory workers.
Fair enough, but that's just really shitty consultants. These days practitioners (the ones I run into anyway) are quite conscious of process overhead. It helps that many are into Lean as well.
FWIW, shitty agile consultants have had plenty of pushback too, with comedy sites like https://www.halfarsedagilemanifesto.org/ being set up to point out their buffoonery. I do suggest laughing in their faces when they pull out tripe like that. Sometimes their excuse is, 'well, we don't work for a startup, we're a
regulated business' -- well, it's still tripe, there are plenty of regulated businesses with lightweight agile processes.
My favourite piece of writing on this, in fact, comes from the US Defense Innovation Board, and is called "Detecting Agile BS"[1]. Their recommendations may not 100% work for your organization, and that's okay -- tailor it with an eye to outcomes for your team.
Playing the devil's advocate, maybe detailed reporting to the boss is useful and worth doing. Probably the product owner's job and not yours, but not necessarily a bad (or, specifically, not agile enough) way to work.
I'm familiar with using Jira for enough customer support requests to require a full time ticket wrangler position, and closing tickets timely with accurate reports is often more important than the requested fix or support intervention: looking good with the IT managers that are, for all practical purposes, our customers has a higher priority, for everybody, than helping a random end user with a noncritical problem.
I disagree. We were a product team. Our primary responsibility to the company was to ship working code, not open and close jira tickets. Would management have forgiven poor reporting in the scramble leading up to an on time / on budget launch? Yes. Would management have preferred a delayed release in exchange for more tickets visible in jira? No. I’m sure my manager could pass it off and say he did his job (look at the velocity graph!). But we would be failing our responsibility to the company.
> I feel that Jira's configurability makes it like desktop Linux 20 years ago.
Totally. A tool that's optimized for everybody is optimized for nobody. Jira for me is in the class of "false consensus" products. Since everybody has to manage work and get things done, there's an illusion that people mean the same thing by that. But the way people and teams work and the kind of work they do varies so greatly that there will never be one perfect work management tool.
Hey now! I have fond memories of my Linux desktop from 20 years ago, I believe I was using GWM around that time. Please don't compare the abomination that is Jira to that.
I find it kinda odd that people's complaints about JIRA seem to all center on meetings and people. JIRA is absolutely not easy to configure. It's a pro suite of tools that requires investment in setup. What it allows is total flexibility within a set of paradigms to meet any orgs preferred workflow. Other tools that are simpler are all too simplistic.
You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices.
If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, everybody here knows that's not true.
I think the true way to optimal resource usage is not through ever-increasing process and managerial layering. Instead, it's through tight feedback loops where small cross-functional teams iterate closely with the people they're serving. Which is exactly how most good startups work. If you were really right about pursuing a financial optimum, the first thing (very resource-constrained) startups would do is get a copy of JIRA and hire some middle managers to carefully parcel out the work against precisely designed specs and timelines. That they don't should tell you something.
I think it’s important to realise that the vast majority (I’m sure it’s more than 90%) of software development being done is technical people from enterprise A building something to help nontechnical people from enterprise B with process C. That’s not something that startups have ever competed with, for good reason.
I love startups and I love working on that space, but you must stay aware that it’s a tiny galaxy within a much larger universe of software that is built and sold like any other engineering project.
And in this “enterprise” (for want of a better word) space, management is important. Not because managers are omniscient or omnipotent, but because at the end of the day, when a customer is paying a large amount of money for something intangible, they need people to talk to, they need figures to see, they need metrics. And in business, the customer is king. Again, except for the startup galaxy where customers are two a penny
Startups compete in the enterprise space all the time, [1], so I don't think your characterization is correct.
I agree that client relations is important, but that's something that happens in many businesses. Like the comment I replied to, you assert that a managerial apparatus is necessary for that. I don't think that's the case. It's true that managerialist-dominated companies often prefer to work with other companies of a similar culture. But that doesn't have anything to do with what makes for efficient software engineering.
No again you’re mixing two markets. Just because a SaaS startup sells solutions to big companies, doesn’t make that the same thing as custom IT projects
Enteprise but Startupy: MS Teams
Not startupy: BMW need a solution to track how many defective gearboxes are detected every month, sorted by supplier, model and assembly site, data fed in from the various factory control networks, verified weekly by each quality responsible on an intranet and sent monthly to top mgmt.
What I’m saying is that the second type of project represents more than 90% of the software being coded out there today.
A startup by its very definition (or at least PG’s definition) does not operate in this space , because it’s not exponentially scalable
I would be interested to see your data for that 90%.
Even if correct, I also don't think your point invalidates mine. I have done contract work for small companies that build "second type" code for large companies. One doesn't need Jira for that. As I said, one needs good client relations, but that can certainly be accomplished without a lot of top-down mangerialist claptrap. Indeed, it's my experience that things are better that way. They don't need metrics. They need their problems solved. Those two sometimes go together, but they're quite often opposed.
That's not what I mean at all. JIRA doesn't imply any sort of top down approach. In fact, I'd argue it's the best tool for those tight feedback loops. Each ticket is a versioned history of the decisions, feedback and work history of a single task. Startups can get away without tools because they can communicate very tightly. That doesn't scale much past an org of even 20 people. Not everyone can talk directly to the CEO or the budget makers, nor are they all sufficiently cognizant of the business constraints to make the right calls on prioritization. There isn't a tier of professional managers as much there's a tier of experts in their discipleship who have visibility across multiple teams and into the business decision making. People who need to allocate budgets and resources without attending every scrum or sprint planning.
You specifically said Jira wasn't for developers, but rather for the managers and stakeholders. That sounds pretty top-down to me.
I also don't understand how you believe Jira can be best for tight feedback loops, but also agree that the tight communication and focused teams make Jira unnecessary. That seems contradictory.
I only meant developers don't necessarily need it to organize their team. Or at least they could get away with something simpler. But organizing the team is only half the battle. Or really less. Knowing what to work on and how to prioritize is more important. Especially if you're managing multiple products and projects. Developers may not need it to write code but they absolutely need it to manage expectations as much as managers need it to set expectations and track against goals and budgets.
Developers absolutely don't need Jira to manage expectations. And we don't need it (or managers) to set expectations and track goals. There are more things, Horatio.
I get that Jira may be a way that works for you, for a local definition of "works". But there are a lot of good ways to make software.
I disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't know how to think about that at all.
A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort.
More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables.
Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.
> The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion
I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up.
Let's take two projects. Project A is estimated by the eng team to take three months to complete. It's not broken down into tasks that are individually estimated and tracked. Just one monolithic task: Do Project A. The project manager says "go!" and then leaves the tech lead to basically run open loop, maybe with a monthly "So, how are things going, eh?" conversation.
Project B is estimated by the engineering team to take three months, but is then broken into small week-long sub-projects, and days-long sub-tasks, highlighting dependencies. After stacking the tasks up and assigning them to the team, it looks like the project will actually take four months. Throughout development, new tasks are created as bugs are found and assigned priorities. The project manager and eng lead watches the finished/remaining task lists daily or weekly, and can easily tell when something is taking much longer or much shorter than expected, and what other parts that depend on that will be delayed.
Which project do you think has the best chance of making its estimated complete date? If the complete date is actually a deadline, which project can be more easily re-sized half way through if we need to cut scope in order to make it? Which project can the team's boss's boss's boss more easily obtain status information about? How does anyone besides the eng lead know whether Project A is even done?
The first approach relies on a lead and a team that actually has the ability to do this style of development. No doubt it would not work with lots of teams in practice, but I think it would work for a lot if they were ever given the option.
Of course the way to do it is not to completely let the team go untethered with monthly checkins. You can still monitor progress, at the tech-lead level. But micromanaging the team members has always seemed hugely detrimental to me. In particular, let the team deliver in chunks: a prototype, a major feature, a reduction in bugs. But let them follow their passions in their day-to-day work.
In my experience, plan B gets something done, but you pay for it by shipping half as much and it's half the quality, plus everyone is unhappy. I guess if all you want is to ship something for a deadline go for it.
edit: to be clear, I don't think you should turn the team totally loose. I just think the right level of external micromanagement is at the scale of weeks, rather than the 'hours' I see useless managers doing in practice.
I couldn't agree more. The second approach is definitely more likely to make the deadline. At the same time, it will often result in disgruntled people who just do the minimum possible to ship. The extra meetings and overhead result in less time for actual dev work, and people will be hesitant to make any improvement they deem would be nice to have, no matter how small, because of all the processes it has to go through.
> A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work.
My heart wants to agree, and I think that up to a certain level for internal projects you can do this. But at some point that’s just not possible from a business perpective.
Can you imagine going to your client and saying “you know that project you’ve paid us 150M$ for? Don’t worry about it, Bob’s on it, he’s the best. See you in 3 years’ time for the launch!”
That's not the idea. There's a shitload of middle ground between breaking everything down into daily tasks and daily meetings; and disappearing for 3 years until you emerge with a completed product.
I agree and there’s the right balance to be struck. But I’ve worked with big customers on big projects, and the one thing they all have in common is a love of metrics. When you’re spending a lot of money you need to be reassured weekly that all is on track and all is good
Commercial artistic endeavors are deadly serious about schedules and coordination. Broadway and Hollywood have some of the most intense and impressive project management in the world. They couldn't survive without it.
But it does look pretty different from tech project management. Department heads are not treated as task monkeys. They are treated as being potentially myopic about their own pieces of the puzzle, and given support on integration with the rest of the production.
The appropriateness of different styles of planning is based largely on how much the work is labor vs knowledge-work. Programming disproportionately ends up being knowledge work, because everyone is always working in a language, framework, scale, or business area that they don't understand.
After all, programming is a craft that can have things akin to "writer's block" (for instance, being stuck on a bug or design). It's more like writing the script than shooting the movie.
While I agree that it's for managers and stakeholders, I wonder how much of it ends up being a net value-add. Where I work, we have a million and one different kinds of reports that pass through the chain of command (admittedly not all of these are derived from Jira, but they exist for the same reasons). We then end up with arbitrary, company-wide reporting requirements that for a lot of teams are like fitting a square peg in a round hole. Then, when you show up as non-compliant on the report that doesn't actually say anything valuable about your team or project, you have to drop everything and shoehorn some solution to make the report happy even though there's precisely zero value added (I would argue a net loss because time and effort is wasted while adding zero value). All because inconsistencies in the reporting aren't tolerated since upper management can't be bothered to understand even the smallest amount of nuance.
I know most of the people in these positions aren't _actually_ stupid, and would agree if you were able to explain to them why some specific thing is completely irrelevant, or even detrimental, to your team. At the end of the day, though, at big orgs no one cares. They'll waste as much time and effort as necessary in order to look good on metrics. Even if the metrics are worthless.
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits.
Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eyeball the ticket.
I don't think the comment was implying that a manager has to eyeball the ticket to make it worthwhile. The comment said there's value in documenting the process, and I agree with that.
We use a ticketing system to track work. It's not Jira. But we do have a requirement that all work is tracked in that system. It's not so that a Product Manager or Engineering Manager can chime in and micromanage; it's so that we have a record of the fix that's easy to find, track the conversation around it, and be able to reference it 6 months or later. Documenting how it was fixed and tested and verified is very useful. Having a place for a manager to eyeball tickets before they are working is not the value of the system.
It's just so obviously an absurd statement to say that if a bug is fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all. A huge portion of the day to day work of software engineering happens without explicit documentation of every decision for every change for every line of code. Life continues, software is built.
The necessity for documentation exists along a spectrum, and the means of documenting things exists along a spectrum. We have lots of tools for documentation. Design docs, commit messages, the commits themselves, JIRA, email, chat. Which one is appropriate depends on the given situation.
Who is claiming that if a bug fix fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all?
That's not my intent as the parent here, or the point I'm seeing or picking up from this thread. There's value in documenting in a system (Jira is one choice), but I know that I'm certainly able to see value in building a system and a process and then trusting that developers use them when appropriate and know when they are not adding value.
the problem is it takes me 2 seconds to run git log to see if a bug has been fixed, vs going to a web browser, waiting for JIRA to load, waiting for a search to finish, curse at search for being useless, eventually find the ticket, and then see if it's complete.
For a manager, this could easily have been written as:
It makes me 2 seconds to look in our issue tracking system to see if a bug has been fixed, vs opening a terminal, find the project, curse at grep for being useless,...
Of course omitting steps in your favorite solution makes it look easier.
And how is testing/validation tracked in how you use git?
Most of us don't work in a vacuum without managers, testers, customers.
And for the record, I as a developer also hate Jira, but we have to look at a reasonable solution.
Let’s face it, most git logs have one-liner commit messages that may or may not describe the issue at a very high level. Even if you have long commit messages, they still are less likely to contain extended discussions about the issue (which can be useful many months later), and cannot be edited. In many places, commits are expected to have the Jira/bugtracker ticket number in the commit message, so that if I find the bugfix via a git log (or git blame), I can quickly find the ticket with the extended discussion and other details that might be important.
Except when the linked ticket is just a title with no content.
However, I would argue that even some of that metadata is better than no metadata. At least the ticket can provide some clues for anyone who is investigating a change.
I feel like GitHub issues are good enough for this purpose; unfortunately GitHub charges a per user license fee meaning that most non engineers don’t get access by default reducing its usefulness.
Which means that the creator of the ticket does not understand the value of the ticket and is just forced to do it by process and so does the minimum required for Jira and his other tools to let him work.
Github issues are basically what a Jira ticket is. Just with less of the other stuff around it feature wise that Jira has. How your company uses Jira is not what makes Jira good or bad. Jira can either be used in an appropriate way or it can be customized into a big rigid process machine that we'd all hate. Been there done both. I like being in the Scrum Master/team lead position to try and influence things into a "less process" world. Ultimately I'm probably still 'hated' by the Devs because there's 'too much process and Jira' and the higher ups don't like it either because they don't 'have enough control' (actually illusion thereof).
When has JIRA actually been effective as the documentation for a bugfix? JIRA in its most effective will just tell you whether we agreed to do this work and the state the work is in. It is not "documentation."
> When has JIRA actually been effective as the documentation for a bugfix?
We use JIRA specifically for this. Commit messages are JIRA ticket numbers and a short message to provide some context.
In JIRA we document what was requested/reported and which customer the issue affects/came from. We attach relevant documents and link it to possible related tickets. If a case is unclear we send it back to support and get additional info.
Once we commit we comment if needed to provide additional details. Our build pipeline then updates the ticket with build numbers after the issue is resolved so we know which versions has the build, which is pulled by our update distribution mechanism.
This way customers will get a notification when a new version is available that has a fix for one of their issues.
We then assign it to someone on support so they can follow up with the customer and verify that the issue is resolved, or we get the issue back with more details.
This way it's easy for both support, devs and management to see what's going on, and it has the needed context in case someone else has to take over.
Not saying JIRA is perfect by any means, but this works quite well for us. I should mention though that we use on-premise install so speed is not an issue for us. By the sound of things we'll be finding some alternative once that option is gone...
I have absolutely seen documentation in Jira. Sometimes the canonical advice for how to do a task is "Go clone JIRA-1234 and follow the steps laid out there".
It's a shitty documentation system because it's extremely hard to find that organically, but people do use Jira as documentation.
I've definitely used issue tracking systems to look into why a bug was fixed a particular way - if a fix is non-intuitive, including the issue # in the commit messages can give you a lot more context than just a commit message.
I’ve seen Jira be the source of truth for user stories related to changes. It was neat at first because you could track why something was changed and what it was supposed to do, and even have a user confirm it’s working the way they expected (I hate when bugs are closed because the dev thinks it’s fixed but it actually isn’t). The ticket would point to source or git log if you wanted more detail.
Sadly it developed from a tiny, quick, useful note to a documentation slog when a new project manager joined and wanted a long description of everything typed into the ticket. So I ended up killing Jira altogether.
Wouldn’t it have been easier to explain to the project manager that there were costs associated with documenting the minutiae, get them onboard and continue to use the system that has worked for you? (Genuine question, not a rhetorical one)
I thought so, but I wasn’t successful. I’m not sure how much was just someone new trying to change stuff and someone who really believes in writing tons of stuff.
I don’t think the problem was jira, it’s just in project management thinking that it is the most important part and the dev work is subservient or easy.
We have an automated process where emails to our support distro go to JIRA and Slack via Zapier. No user request or bug report gets lost. Issues with insufficient info get followed up on by an ops/support person. All feedback and actions go into the ticket. Something that can be worked around is documented and resolved. True bugs get logged to the dev backlog and linked to the support ticket. Works like a charm. The users can see the ticket history without really learning much about JIRA. Devs in know exactly how the issue was reported and triaged. Probably 3/4 of issues are resolved without a dev ever being roped in. And no user ever wonders what happened to their request.
It depends on your organisation size and structure, but probably you want to run the bug fix through some triage first (meh management overhead, but needed if you have many bugs to make sure the "important" ones are fixed), then code review (well, that doesn't happen in jira, but probably should be (automatically) reflected there to have one place to look later) and after fixing probably should be routed to the documentation team so docs are being updated and to support team so they can talk to customers accordingly.
I think you might be missing another dimension, in that it depends on the size and type of bug. "See a problem fix a problem" is a common mantra in physical work type environments I've been in. You don't wait for a manager to tell you to pick up a debris that's fallen in a forklift path. You clean it up. This doesn't quite translate as well to software, you certainly don't just want to make production code changes without some kind of review, but there are things like cleaning up some annoyance around a dev VM image that doesn't require ticketing. A smart dev will likely tell people they fixed it (especially so teammates can update their VM), and a smart manager might document that fix with a ticket for their metrics, but my experience, is that organizations that laud autonomy in these kinds of improvements tend to have significantly greater actual velocity than ones that don't. I've lived through an org that reprimanded any change that wasn't documented (or really dictated) and it creates an atmosphere of apathy and distrust. The same org over time finally had enough personalities who lauded initiative that it was transformative, and the apathy evaporated.
Yes, there is value in that and it's a thin line. However if it affects external behavior it is some form of product decision, which eventually needs to be signed off and it has to be documented in some way.
Of course a typo fix in a comment (to find something even more trivial than your VM example) doesn't need a process. But that's also not what I'd call a bug.
Typically how I've seen this work in high-functioning environments is that devs aren't scheduled at 100% according to JIRA. They have time set aside in their schedule for work of this nature. They'll fix the bug, create a JIRA for the commit/PR, and get on with things. The coworkers on PR reviewers and get their notification that way or in standup. If it's more than 30 or 60 minutes they might log some time against it.
On a team I was on, there was a rule that we simply wouldn’t bother documenting 1 point JIRA tickets as then the documentation itself would likely take more time than just making the change.
That reasoning is weird to me. I could live with "there is no impact for users on this" but if it has impact for users (there of course is a difference between developing a library where a lot of things have impact from a GUI application where most things are invisible to the user) it should be documented, even if documentation takes three times the time. Good documentation is part of a quality product.
It's not valuable because then later a manager will still assign the work to another developer, who will spend almost the same amount of time trying to reproduce the bug and finding it fixed. This leads to several back-and-forth slack group slacks to figure out that it was already fixed, and decreases morale. It wastes as much time as if it weren't done at all.
This is not how it happens in my experience. The other developer, who sees their teammate's daily updates and code reviews, would just say "oh this was fixed yesterday". The manager trying to assign work is a tedious redundancy here; the engineers do a better job of owning the problems if the manager goes away.
I work on a team of 70 developers (directly) and another 50 or so work on a shared code base between our project and others, and I make daily modifications to that shared code. all those developers are spread from PST to CET+1. Bugs that get fixed are sometimes done by domain knowledge holders on he base team, and those fixes are large fixes that get done on a different release schedule to mine. Its an utter waste of time for me to bug some guy in Seattle about something that he fixed months ago in a release that I haven't received yet when I can see the fix version and change in jira, and either wait or take the fix from the upcoming release myself.
It really depends on the situation. If you have a small team that owns their own codebase, then people will generally know what's going on. In a large codebase with multiple branches it's going to be messier. If everyone's sharing a bug tracker it should be easy enough to claim bugs you're working on.
For the short term, yes. For the long term, if you do not document the reasons of the changes, eventually you will not remember what the reason was for that change.
In software products with enough large bases, some changes decisions affect other users, who eventually might request the change in the opposite direction.
You do not want to lose the rationale behind the original change/fix.
Keep in mind that what is a bug for some users is a feature for others: https://xkcd.com/1172/
This is a specific view of the role of the developer, one where a developer is not a stakeholder, has no agency, and is in essence a hired gun easily replaced by another hired gun. Products built like that tend to be the lowest quality, because the people actually making it don’t care about what they’re making. Teams run like that require detailed work tracking solutions with dedicated middle management.
The other approach is to have developers build up a real sense of why they are building what they’re building, who they are building it for, and give them the agency to change the how and what to better meet that why. This requires trust, so it is more easily done in organizations that are on a first name basis. It may involve jira, but really almost any work tracking solution will work.
I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots.
Yes I'm an assembly line robot and the plant foreman. Jira and delegation helped me pull off both
Pretty sure that's what the majority of programmers are. I know I am. My identity isn't wrapped up in programming. I build stuff for a company that pays me lots of money and then I go home and do stuff I like.
We need to get rid of this wild west mentality where disorganization is lauded.
Fair enough and quite common I suppose. Generally for some a job is just that, for other (perhaps just some lucky few) it's a calling. I'd think the share of the former was large among programmers ("coders") in the early days of computing, when that wasn't a highly regarded job (seen alike data entry). Then a few years after the micro computer revolution, many of those who grew up and where fascinated by home computers entered the work force. Those you essentially just needed to feed and perhaps point in a direction. Then the Internet bubble happened and many realized that there was hard cash to be earned. There we have the career IT guy (who's just as happy to do something else which pays at least as much). It's not that they perform worse (in situation where discipline and organization is paramount they can be expected to outperform geeks), but the work style is quite different.
> We need to get rid of this wild west mentality where disorganization is lauded.
I don't think people celebrate their lack of discipline, but rigidity stymies creativity (and don't ask me how long it'll take me to fix a bug). I don't think Silicon Valley happened accidentally in California rather than in Prussia.
This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.
> Jira makes it easy to track what's actually going on.
No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".
They live in GitLab. There is also tickets in GitLab, which all developers are happy to use.
There is a wiki as well, which, gosh, is just markdown in another repo! Markdown you can build beautiful PDFs from! And websites!
But nope, we need JIRA and confluence, because for some reason GitLab isn't good enough. Now the tickets are separate from the actual work, there is another platform with a complex and slow ui, and our docs formerly markdown are now in some proprietary confluence RTF, which can export to word and PDF - with no custom styling.
I haven't used gitlab's wiki specifically, but the reason why you would use something like confluence is because you get a wiki with a wysiwyg editor, so less technical people can use it without having to learn markdown and there is less friction to making docs. It's not specific to confluence.
Hell google docs would probably beat confluence in a corp if they let you make a wiki structure out of it vs. it's current 'pile of documents' organization model because it has a better wysiwyg editor and inline comment system.
I'd argue that Markdown is easier to learn than confluence wysiwyg, and also more useful in the long run. Especially as there are many GUI Markdown editors with buttons and preview windows, that give you best of both worlds.
The constraint for the org I work in is that GitHub has a per user license fee that makes it difficult to justify getting a license for everyone in the org since we have a lot of non developer staff. But everyone has access to confluence/JIRA. Does Gitlab also have similar license restrictions?
Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you.
As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company, etc.
edit: anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone
I agree with your assessment, having experienced a gradual shift from junior to senior myself.
As for why the downvotes, hypothesis 1: People might misconstrue your position as "senior ICs are supposed to design the system entirely on their own". I understand you as "management provides the direction and some design constraints, seniors fill in the details, juniors just implement specifications from the seniors", which matches my experience.
Hypothesis 2: Maybe it's a culture thing? I'm guessing from your user name that you're from Europe, and I'm from Germany. Maybe the downvoters are literally coming from a different place? (Don't know how it would be different over there though.)
Generally the details have been sorted out at some level otherwise how did you estimate it? And the ticket was likely estimated 2 months ago and you may not have been a part of that. I prefer a ticket with as much detail as possible so I'm not making the wrong assumptions.
Of course there are details to figure out. Why wouldn't I want all the information from design and other teams in front of me when I'm figuring those details out? I'm struggling to see why a detailed ticket is a bad thing.
Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.
I dislike Jira, but it's quite untrue that it's absurd that there needs to be context and a record of discussion for tasks. People leave, focus changes, memories fade.
It's not a unique occurrence that I wonder "why the hell is it done like this?!" only to find it was a decision I was part of with developers who had left in a least-worst-change trade-off. Jira or products like it help us avoid repeating the same mistakes.
Put another way, part of the art is not just the code, but the code that's not there. Jira/tickets are one way of managing that data.
And at other times, it's just a tool for bureaucracy, I get that.
heh you would be surprised. I literally closed a ticket from 2014 this week which had a lot of relevant information and prior discussion. Without the record of it somewhere I would of had taken much more time.
I also always search jira for a particular issue that I am having to see if someone else has already solved it or a reason for it not to be solved. Sometimes it works quite well saving me a lot of time.
I worked at an org where you couldn’t do anything without and being assigned a Jira ticket. Want to refactor some code so the feature your working on is maintainable, nope you need an assigned Jira ticket. The fact that work units are called tickets and Jira was built originally for desktop support is the foundation of the problem. Don’t think, just code attitude.
Anything is better than Jira including post it notes on a wall.
Why is this a problem? Was it difficult to create a Jira ticket? When last i used Jira, it took a few seconds to create one. Less time than it takes to write a commit message.
Not the person you responded to, but I'll take a swing.
In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are in the middle of a sprint. you are not allowed to change the sprint. 2 weeks (or whatever) later you have a meeting, where you have to argue for your ticket being next. That probably doesn't result in success, but pretend it does. Then it gets assigned to somebody that essentially knows nothing about it, because developers are interchangable, don't you know? Meanwhile you are stalled because that refactor made sense to do before the ticket you are working on. So you work on that one, don't move it to complete, and get dinged. Or you do it anyway, knowing you will have to do the work a second time once the refactor is done, but hey, you'll get so move multiple tickets to 'ready for test' next sprint or so, so yay, you measure well, can't wait for bonus time!
Yes, I just described a horrible process, but pretty much how it goes in most places. The very first thing people forget, and fight strenuously against, is the agile principle "people, not process"
To offer the counterpoint, if I am refactoring sw that runs in a flight computer or something, even more process is needed, because you need to test extensively before releasing code that can kill someone. That check in can cost hundreds of thousands of dollars if you touched something that is now going to have to go through lengthy QA.
It just depends on where you work, and the cost of bugs vs rapid response to problems/requests. In my experience orgs try to build a workflow that would suit the space shuttle when the product is, well, less important and serious.
Great comment, and I'm glad you replied with these examples. The problems you describe are corporate software development process problems and not problems with Jira or bug trackers in general. It's a dysfunctional company welding their dysfunction onto Jira, and Jira gets the bad rap. Most of the time when people on HN complain "I hate Jira!" what they really mean is "I hate my company's inflexible software development process." Jira just happens to be the UI surface that this horrible process is exposed through, so naturally they take their hatred out on Jira.
Here are a few process examples I've seen (taken from real companies):
Company A: Bug tracker contains a handful of bugs and features, but you can pretty much commit whatever you want, whenever you want, without a ticket. Lots of work, major and minor, being done totally untracked through anything outside of git log.
Company B: Everything you touch requires a ticket, full stop. Ticket creation and assignment is a laborious process as you described in your comment. Sprint scope enforced ruthlessly. Sudden changes in scope and dependencies must wait until the next sprint.
Company C: Strictly one ticket per commit. But if you need to make the change, just create the ticket, document your change there, and close the ticket. No big deal. If you're not working on the right stuff, your eng lead or project manager will notice when they browse through the assigned and closed tickets.
Company D: Just like Company C, but without the "one ticket per commit" rule. You could commit whatever you wanted as long as you could point to a ticket that described what it was for, and you could use that ticket over and over and close it when you were ultimately done.
Company A was total chaos, and we constantly missed deadlines and chased quality problems. Only eng really had a clue about what work was done, in progress, or in the backlog. The eng leads simply kept it all in their heads and documenting/communicating was an afterthought. Company B was frustrating and bureaucratic, but we at least managed to ship most of the scope on time and with reasonable quality. Not great eng morale but management was happy with output. Company C was the best. Really easy to derive project status by just looking at the bug tracker. The "create a ticket" habit was drilled in to you during orientation and was just not seen as a big deal. Company D was kind of a mixed bag. Eng loved it, but it was hard for the managers to track progress because you always had all these "mega-bugs" open listing commit after commit after commit, and there was no indication of % completion.
I didn't mention the actual bug tracker for any of these companies, because it really doesn't matter. You can use any bug tracker to support any of those processes. There is nothing Jira-specific here.
The problem with company C style work is when you do really small incremental changes. I have had 40+ commits for a single issue, being very gradually rolled out.
The time taken to manage tickets in that case would easily have exceeded the time spent on the task itself.
This is correct. "one JIRA ticket = one git Pull Request" is not a good system even when the work can be rolled out in one go, since it encourages PRs that are overly large, long-lived branches and late integration with merge issues. Rather encourage having an idea of where you're headed with the chain of commits, and review and merge a sequence of smaller steps, and ideally validate each of them by deploying to production. This is easier to review, easier to merge and less risk to deploy.
If JIRA is not a good fit to this model, too bad, that's JIRAs problem. Don't make you dev process worse to appease JIRA.
"Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets."
It's for developers too.
As a developer I want to know what the history of work on a certain issue was, who requested it and who worked on it in the past (not just at the code level, the information for which should be in version control logs, but also at non-code levels like approval, review, etc), what the communication was with other stakeholders, etc.
Much of this information is useful to me to figure out who to talk to if I have some questions which the documentation or sourcecode does not answer, and also how to communicate how/what was done on this issue.
This is the strength of a ticket tracking system, and that strength helps everyone.
I can't speak for Atlassian dogfooding, but I don't find this to be a very true statement:
> While Atlassian has great confidence for how you should run your projects
JIRA really doesn't. It's extremely flexible, which I think is where it earns a lot of it's bad rep. You can really map your entire mental model to it's statuses and workflows if you want to (but you shouldn't).
The teams that I've been on that have had success with JIRA are ones where JIRA only encompasses the minimal amount of process as possible to represent the status of an story/bug/initiative with as little extra added as possible. The other key thing I've noticed is using it as consistently as possible so it can actually become the central repository (found a bug? make a bug ticket. have an idea thats starting to take shape? make a story ticket. fix a bug? put the ticket number in the commit). Seems like common sense, but usually needs to be strictly enforced, especially with individuals that are on the fringes of the development process (such as subject matter experts).
Every team has their own process that is tailored to their needs, process is decided by devs, not managers, managers only do "I'd like to have this kind of visibility" requests some times and I yet to see those requests introducing any kind of burden, usually very miniscule things.
We have very simple process in our team with two issue types for devs - task and bug. We have two week long sprints and put tasks from backlog into them.
Statuses are: open, in progress, code review, done.
If I forgot to move a ticket than a team lead or feature lead will do that for me whenever they are at it.
Besides this there are epics but devs don't deal with them, feature leads and team leads and PMs do.
This is all running on an instance that is deployed every 4 hours with changes from master and goes through the same upgrade process our customers would go.
There's special set of very high-level tickets but we don't deal with those, those are for for people 3 levels above.
Sprint planning is about 30 minutes because backlog grooming is done for devs by feature leads and team leads and that's pretty much the only obligatory meeting.
JIRA using JIRA.... is it too easy to claim this finally explains the total lack of end user experience in JIRA? I mean just look at all the comments here complaining about performance, search, dependencies or broken WYSInotWYG editors. The four primary features of such a tool. This has been the state of every jira installation i've ever used the past years.
I'm sure your internal burn down charts are straight and nice though.
But as top level says, this is not the tools fault alone, more the process it encourages.
By the time we're in planning, only things to discuss is estimation and priority, it takes virtually no time. We have a whole hour booked and spend half of it to just hang out, pretty much the only time where the whole team is present in one meeting.
Atlassian whole point is team centricity. The team decides the process, the team decides the metrics, the team decides what to deliver and how fast. The team decides what are the QA rituals. Yes, there checks to fix a disfunctional team but I have never seen those applied. So there are as many processes as teams in Atlassian.
Been chewing on your replies. Thanks for pushing back.
Atlassian really should be bragging about their internal processes, cultures. Popularize your Agile equivalent of Toyota's Production System. Seed an ecology of people spreading your techniques.
Embed some ethnographers and anthropologists in some random teams. Keep the cameras rolling. Show the good and the bad. Model how orgs should and could become learning orgs.
Was lucky to see a few situations where it was the team that decided to use JIRA, as well as other situations where a team decided not to use JIRA - because they didn't like it and their process was achievable without
I legitimacy want to see this. Hire some film students, have them embed with some teams for some sprints, post the footage.
If Atlassian really does walk the talk, why aren't you already bragging about it? I just peeked at Atlassian's YouTube stuff. Nicely produced. So that's something.
I'm not even going to move the goal posts, or play No True Scotsman. Show how any team actually using JIRA, like a Twitch stream or something, and I'll cheerfully send you $100.
Forgive me, but I'm struggling to accept that anyone creating and maintaining and supporting JIRA and Confluence could abide by them. Sure, I've worked on crap products before. In anger, under protest. I never accepted it.
Good point, not sure why we don't make more of a fuss about it. I think there should be some content about how our HR teams use Jira coming out soon so that could be a good first step.
Ironically, I was part of the group that just did the first ever official Atlassian Twitch stream the other day! Seems like an easy way to fire off content without needing a lot of approvals and checks. I'll chat with some people on the marketing side to see how hard it would be to just walk through our own setups. Saw this in a comment somewhere, but confirming we have a culture where process and setup are determined mostly on a department-by-department basis (at least for the non-tech side of the house). Our Marketing org generally works in an "agency" model where there are teams responsible for specific marketing disciplines (SEO, Video, Branding, etc etc).
Just on a side note, I'm happy to walk you through how we use it personally — Zoom, email, or whatever. Always trying to learn how we can make Jira better and try to share advice where I can.
Totally, I'll bring it up with some people post-break! The JSW marketing team is really open to any kind of work that'll help product usability. Interesting fact, a couple of them are actually prior Jira Admins.
> And I've also never worked anywhere that had a better option than JIRA.
Agree with most of what you say aside from this bit. I find most similar systems are in the same ballpark in terms of being able to track what I care about.
Mainly:
- Is the ticket ready for me to work on? (Do I have the designs I need to work it?)
- Who is working on a given ticket right now?
- Am I done with a ticket?
- Is the ticket ready for QA?
- Did QA reject the ticket and I need to fix something on the ticket?
Pivotal does these things fairly well. There is also the obligatory pointing system, but the above is the bulk of what I care about. Pivotal also lets me create queries so I can zero in on the work which I'm doing as opposed to the entire project.
"status" => current column on GitHub project. This includes "is the ticket ready for me", "am I done with a ticket", "is the ticket ready for QA", "did QA reject the ticket", etc. -- each of these is a column in the project board.
I haven't used GitHub for this, so I'll take your word for it.
The fact that there are a lot of ways to track these issues well was exactly my point.
You need some way of tracking these things. I've used JIRA and it got the job done. I've also used other tools which worked as well. What doesn't scale is not tracking issues.
A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer never has to write to it. The only JIRA a developer will be happy using is a JIRA they don’t have to work with.
No, a git commit is not transparent to product, QA, devops, infosec teams.
Opening a jira issue to document a change that everyone should be aware of can take me literally one minute, and I've even assigned it to the sprint and version.
"Developers don't like JIRA, they love GitHub": these are some generalizations that can often be true. However, you can also automate JIRA using your VCS of choice. You somehow make the assumption that only GitHub git + GitHub issues can be automated.
See a nibling comment. In short: GitHub is developer friendly by default whereas JIRA is not. Ideally automation is set up in a way that QA, devops, infosec, customer service etc. get all the documents they need generated and cataloged automatically. It a) saves headaches from the developer and—more importantly— b) prevents pesky developers from making mistakes during the process (e.g. mis-categorize, etc.).
You can automate the same thing with JIRA if you use bitbucket. I even saw process automation with Github and JIRA. This is just an excuse I heard from devs 100 times.
If you use Atlassian's git-based Bitbucket you get the same thing. It's very much like what gitub would be if you asked a project manager to design it. But that's very much an IBM-like approach, where they entice you into buying additional software because of their walled garden.
You can complete JIRA tickets just by using a commit title format, and I don’t buy that there is a better system for QA to report the bugs or feedback themselves...
QA can be automated in the same way using CI/CD. A QA engineer should be able to read the existing process documents from the git history and have confidence in the CI/CD. In fact a QA engineer’s job is made easier if a robot is cataloging the process (as human developers are prone to errors and sloppy work).
Regarding feedback, a developers dream is to never have to ask for one or give one. Tickets should be well formed and ready for the developer to start work efficiently. A customer service engineer is in the perfect spot to ease the work of the developer. If a developer has question they can ask the customer service engineer which in effect is responsible to document the process.
Note that I pick JIRA apart here for no specific reason, it is possible to use GitHub as inefficiently as JIRA and vise versa. However GitHub has developer friendly workflow set up by default, whereas JIRA does not. In fact I’ve never seen a JIRA workflow that is developer friendly.
A git commit is a "how," not a "what" or a "why." That's where JIRA comes in (if used properly). I don't love JIRA, but (IMHO) when it's used properly, it's a great tool.
>>> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits.
Hard disagree. Unless you're writing software for clients a crapton of ceremony goes into JIRA tickets when 99.9% of them will never be looked at again once marked closed.
>>> If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money.
JIRA is used when companies have no trust in their devs. We all use Git. There's a perfect, permanent record of anything I ever touch. Yet management is always worried we're going to "get distracted". As if that wouldn't be incredibly obvious.
It's like hiring a plumber to fix something then following them around the house to make sure they don't straighten your artwork or do the dishes while they're at at.
There's a pervasive theme that "PM knows best" among companies obsessed with JIRA. The best companies I worked at had no project managers at all and things ran great.
I once worked with a developer on a relatively small team of 10 people or so (3 other devs) who said it was impossible and pointless to estimate effort for tasks.
He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done.
It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard.
After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes.
It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams.
This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on.
This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.
You want devs to not care about anything but fixing technical problems though.
At the end of the day: technical problems can have hard constraints that dictate the usefulness of your product and the people who have the skills to investigate and fix them should be dedicated to using those skills to fix such problems. Worrying about users, funders and other teams is what Product/Project and Engineering managers are meant for.
I do agree with you that it’s not practical to spend infinite time on fixing a problem. But it’s not strange for an engineer to think that way; in fact engineers who are willing to dig deep and at least root cause the issues (if not outright fix them) are very valuable to have.
The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.
in my company we actually do estimate work and many people are so bad at it. however we learned from that and our trainees need to track how much time they spend on issues and then we talk about that after two weeks, so they get an understanding why something takes x or y and they can learn to estimate work.
estimates do not need to be perfect, but we encourage everybody to estimate more time that they think instead of less. so for the estimate they need to think about the problem and do not code like monkeys without any kind of plan on how to fix the specific problem/task.
Right, the goal of estimating in this since isn’t to have perfect estimates, but to get people thinking about how much time it takes.
It’s also important to not “grade” people on their estimates or treat them with great precision. Just an ongoing rough ballpark helps with planning. Although oddly I found that estimates got better over time.
> Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets.
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits.
This is patently false, as evidenced by every business in existence that doesn't use issue trackers, including most non-tech divisions of current businesses and most tech businesses until the rise of agile. And I question the value add of these things; my current company was built without them, and it's only as we've matured (well after the product was built and mostly refined) that issue tracking was used.
> Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets.
As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based around short-term thinking.
First, it provides multiple negotiations for every work stream: "What tickets are part of this project?" and inevitably "what tickets do we need to cut to get this project out the door faster?" The developer quality of life tickets are the easiest for non-engineers to jettison. What's worse, sometimes they're right to want to get rid of those tickets. Quite honestly, developers often don't do the math on "Will we ever get the time back we spend fixing this?"
Second, JIRA-based systems are designed to try to make everything take the minimum possible time. This is a good thing, but developers can bear the burden of it. Quick iteration is good, but it turns into a situation where the most you can undershoot a task is by hours or a few days, but if something is much harder than you expect, it could overrun by weeks. I think this is a necessarily reality of business, and that "evidence-based scheduling" a-la Joel Spolsky is an innovation that could have eased this pain by introducing "how bad are long-tail effects?" into project planning. But as-is, you're in a situation where you're either meeting expectations (since the ticket took more-or-less what people thought), or you're visibly holding a project back (because it was tightly scheduled to within an inch of its life). So the development experience becomes this weird commodity that sometimes has really visible failure modes.
And finally, since JIRA projects/epics/whatever are often prioritized by expected value, it's difficult to raise large engineering concerns. Again, this is a good thing, because time spent engineering is time not spent helping the customer. But because the focus of JIRA is so granular, it's difficult to break out of that. Imagine a company in the 80s that wrote desktop software in assembly, and some engineer is like, "This is crazy, we should invest the time to write modules in C". How do you climb out of that? In the language of agile development, you actually need a lot of foresight to break out of this local maxima, because your prototype will be demonstrably worse - "so we need to set up this compiler toolchain everywhere, and interface with our existing assembly code, which the compiler toolchain doesn't make easy, and it introduces ABI concerns, and your prototype looks worse than just going with this. I think we can safely call this a failed experiment." When the only project language you have is trees, it's difficult to talk about forest. I think this is why healthy engineering organizations that I've worked for tend to spend about 30% of their time working on more ambitious stuff. But it's something that needs to come from the top-down, because the tools won't provide it.
So to developers, the structure imposes a system where successes are minor, failures are visible, it's hard to get negotiation leverage, you lose the forest for the trees, and they need to fight tooth-and-nail for quality of life improvements (or they get a week thrown down from above, as a treat, to address any technical debt).
This is so nicely formulated, thank you so much! I'm just thinking, isn't what you describe the general problem of agile methods/processes, and not Jira's, as it's just one of tools built to assist in agile implementation?
That's an excellent question. To me, the difference is "is agile development part of our process?" or "is agile our entire process?" I once worked on a development team that did a great job of using agile as a narrowly-scoped thing that applied to the act of producing work. They viewed picking their large product and engineering changes through a different lens, which was trying to constantly put yourself on a holistically better footing with both your customers and the engineering codebase. It wasn't "agile" in the sense that it didn't follow any specific methodology - it was top-down, not iterative, etc. But the work to meet the objectives could be done with agile development.
So to me, it's a question of how good teams are at isolating agile development to be scoped to just development. Can they separate strategic thinking (which JIRA basically tries to prevent) from commoditizing development (which JIRA excels at)? If you just rely on the tool that makes work easy, you're not going to get there.
I've not used JIRA in the long time, but in general I find source coontrol with issue tracking to be highly useful for working out why a particular change was made, several months after the fact, even if I wasn't the developer responsible (or even in the team).
> But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets.
Yeah. The problem is they now have to report at least 50% less progress because half of s dev’s mental power is dedicated to ignoring or updating Jira.
Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.
>and what happens when JIRA does not reflect the actual priority as observed by devs?
Why do you believe devs alone define the "actual priority"? This stuff is collaborative, and I've worked with many devs who don't have the first clue as to what needs to be built by when in order to keep the business thriving.
> Why do you believe devs alone define the "actual priority"? This stuff is collaborative,
I do not believe that, of course it is collaborative. Some things are emergent, some are not. Some can be neatly broken down into fixed length tasks, some cannot. Some are planned, some are not. Some are top-down, some are bottom up. Some are obvious business function items, some are leftfield ideas.
I'm just feeding back that attempting to mediate and regulate that collaboration via JIRA is a bad idea. A common, and bad idea.
Developers absolutely should not be deciding what is 'priority'. It's very unlikely they have access to the metrics, wider business strategy, internal and external stakeholders, necessary to determine this. That is the job of the Product Manager.
Have you read David Allen’s Getting Things Done and looked at that system?
You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward.
Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING.
These core mechanics work.
Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown structure fit into a project management iron triangle, per your middle management point.
Of course, middle management is just trying to lie to senior management that writing software isn’t invention because invention isn’t predictable — but senior management wants perfect predictability so they know they’re hitting their bonus, by pleasing C-level execs, whose packages depend on pleasing shareholders. Everyone’s building a Jenga tower of predictably hitting the numbers.
So if you don’t like JIRA, blame shareholders. :-)
Jira / Kanban works for some projects while Waterfall works for others. Some projects need high levels of governance while others move faster with low levels of governance. Some projects can get away without time-commitments, but others have dependencies and must hit deadlines, and this must be tracked.
And just because GTD is great for managing my personal workload, doesn't mean that it's great at coordinating the work of 100 people.
(I say this as a person that generally believes in Agile, is a huge proponent of GTD, and have also been on a dev team where Agile and Kanban was applied where traditional Prince2 would have been a better fit).
I agree with your larger point but pointing to GTD as evidence that the "core mechanics" work is questionable. Many of its biggest advocates have abandoned it.
> Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an addiction. “On more than a few days, I wondered what, precisely, I was trying to accomplish,” he wrote. [...] It seemed to him that it was possible to implement many G.T.D.-inflected life hacks without feeling “more competent, stable, and alive.”
It doesn't sound like Mann is disagreeing with the core mechanics of GTD in those posts, it sounds like he is saying that there are diminishing returns with applying 'personal productivity' methodologies, and you can get obsessed with tweaking your personal workflow to an extent where you no longer get payback.
This is a trap I have fallen into before - where you are effectively procrastinating by trying to optimise and system-tweaking your personal GTD system rather than just actually-getting-stuff-done.
Having said all that, GTD helps me personally massively. It's not for everyone, but for lots of people in senior jobs that gets so much 'stuff' in that they struggle to keep up, it's really important to have a systematic way to process it all and not drop anything. I find people who don't have a system like GTD or similar will tend to work from their inbox and end up dropping stuff.
That article is interesting, but really just talks about one guy's journey with GTD (Mann), and another guy's great-but-different proposal for higher-than-individual level changes.
I don't use GTD in any explicit fashion, but to throw my n=1 in the ring, the overall concept of personal productivity changed my life. Anything can be taken to a harmful extreme, and I was (at least) annoying for the first few years. But I grew out of it and kept the good parts, and I have no doubt that, for me, this sort of thing was hugely beneficial.
> You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do.
Stuff you might or might not complete is basically, everything. That's not a meaningful category list.
> These core mechanics work.
They work like a water-filled car coasting downhill. It looks like it's water-powered (or JIRA-powered) but it's just the gravity well of "looking busy" for the most part.
Maybe the in-car water fountain could be considered water-powered in practice, but that's a derail. Management gets approximations from JIRA because that's what they want, but JIRA doesn't provide it. A tool with a dependency graph could do much better.
I’ve been thinking for a while that the ideal developer view would be just a 1 dimensional queue. You have 1 ticket at slot 0 that you work on and if someone wants you to work on something urgent out of order they’ll insert it at slot 1, otherwise you just keep popping off the queue. Managers and scrum priests could add more complexity to the metadata and the ordering as much as they want but the developer view would stay the same
> Fixing a bug without filing a JIRA ticket is in itself progress.
When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it.
Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason)
When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.
I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket.
With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket.
I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself!
8 person teams are usually the recommended max team size anyway under Agile (two pizza team).
> someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too.
I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now.
> I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets).
In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it.
But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.
So... "shouting across the room" for a ticket which is so trivial it doesn't need to be documented is OK, but telling someone to "fuck off" for doing it is not?
Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.
Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room.
The best teams I have worked with tend to be more collaborative.
There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will get handled quicker because usually multiple people can take care of the task and the one who has free time first can handle it.
An atmosphere where interrupting people randomly is commonplace is almost never good for productivity.
> The best teams I have worked with tend to be more collaborative.
Collaborating doesn't require interrupting people in the middle of a task.
> An atmosphere where interrupting people randomly is commonplace is almost never good for productivity.
Almost everywhere I have worked there has been a way to signify that you don't want to be disturbed and you are working in the zone, be it setting do not disturb on slack or wearing headphones.
It's not an either/or situation, and if John has the credentials to a server and sits opposite me and doesn't have headphones in, I'm asking him to pop them across rather than raising a ticket to him.
Maybe it's just a poor turn of phrase, but when someone talks about "shouting" across the table to get some minor issue fixed, that isn't the kind of place where good coding happens.
With regards to your previous comment, I already said above
> "The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now...."
—and—
> "In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it."
If you are a developer and your workplace is filled with interruptions because people lack credentials or things are poorly documented, then your productivity is going to be terrible.
Agree 100%. JIRA is supposed to be a means, not an end itself. Half of my organization believes they are generating value by adding new issues into JIRA. JIRA helps reinforce a dogmatic attitude that the "hows" are more important than the "whys", and thus issues that could be succinctly described in 20 words get expanded into templated "given/when/then" verbiage.
One of the core Agile principles is "individuals and interactions over processes and tools". JIRA is more-or-less value neutral, but the management caste, possibly fearful of the sort of healthy conflict that comes with negotiating the priority of features and fixes, tends to resort to inputing all their information into JIRA believing that it's a substitute for actual communication.
Every Agile resource I've read has emphasized the point that nothing is equal to actual conversation between stakeholders. Whether it's JIRA or one of its competitors, when you have a tool that discourages conversations or pretends to act as a proxy for collaboration between stakeholders, you're going to court failure. Easy to blame JIRA, but it's this whole tool-based mindset.
Every single job I've worked that used Jira, also used google sheets to "map" actual work to Jira work. It has always blown my mind. All the meetings to update the google sheet, and then to update Jira, and then to ask why the two aren't in sync. It feels like I'm taking crazy pills. Why are we using a manual tool (google sheet) to keep track of the work, that's in our work tracking technology? What?
Because there’s so much friction to do anything in Jira. It’s horrible for any kind of planning or really anything that’s not set in stone. I just keep a text editor with my current and next tasks and then update jira at the end of day based on it.
The biggest problem with Jira, is that they give you the gun and the bullets to shoot yourself in the foot, while trusting you not to do it... The reality is that most teams (or let's be real, managers) can't be trusted not to shoot themselves in the foot here.
Adding more features and more process in general is going to be a net negative for developer productivity. But how well Jira (or similar tools) works for you is completely up to how you use it. Most teams I've seen that hate Jira et al usually have an overly complicated process, with far too many "states" for a ticket, a million mandatory fields, multiple assignees, etc. This naturally results in people spending far more time in the tool, which is time they could be spending actually doing productive work. Conversely, teams that like Jira tend to have very few ticket statuses/fields. Standups are quick, sprint planning is quick, everyone wins. Unless your job was moving things around in Jira for 20+ hours / week... in which case you'll need to find something else to do.
Our folk wisdom metaphors for QA/Test and change management are wrong. Sure, given enough thrust, even pigs can fly. But polish a turd and it's still a turd. [1]
JIRAs turrible implementation isn't even as bad as the CRM, ERP, enterprise products of yore. Turrible, sure. But I've seen worse. Much worse.
[1] I was a QA Manager for a while. Someday I may publish (explain) the play books my teams used for shrink wrapped releases. (Spoiler: I replaced a lot of heavy weight CRUD based mgmt with lightest weight artifacts. Like just printing all the bugs, taped to the wall, and using approval voting to prioritorize.) Until then, Bryzek's new "testing in production" strategy is the only QA/Test workflow that seems directionally correct in our new agile SaaS world.
Jira is middle-management-ware, a term I made up (I think) for software that serves the needs of middle management, or, at least, the needs middle management thinks it has, which comes to the same thing as long as you're selling to them.
What are those needs? Metrics. Being able to see who's doing what, and how quickly, and what still needs to get done. Being able to make charts and graphs and summarized reports for the next-higher level of management, so they can say that their team is productive and their team isn't falling behind.
It also serves the needs of the companies, like Adaptavist, which have attached themselves to Jira to sell add-ons and generally bring the state of the software up to where middle managers (in my experience) think it ought to be out of the box.
I could imply that this is deliberate, that Atlassian is Not Adding some features to scratch the backs of those other companies, but That Would Be Wrong, I'm sure.
I just had this discussion this week. I'm doing work in Jira to build metrics, rather than metrics being tracked from what naturally occurs in Jira. While I understand that most of these problems come from the setup and the decision to use Jira a certain way, I feel the system itself encourages busy work.
As a developer, I've felt the Fogbugz way of doing this most closely mapped to my natural workflow. It is also built around the concept of a single person "owning" a ticket, providing a natural flow from person to person through the lifecycle of a ticket. This can be done in Jira, of course, but it is a mental drain as it requires more bookkeeping.
edit: I guess what I'm saying is that Fogbugz in particular is a bit more opinionated and lines up with what I think is good. Jira naturally guides management to all sorts of extra crap.
I only used JIRA briefly and it took up way too much time to adequately document our work. I didn't want to leave any work out as I wanted to show all the work being done. Eventually my manager just wanted some very high level stuff absent of any detail and it mostly died out. My new manager just wants a few bullet points once a week on what you've been up to. I feel like I can convey the same information in like 3 minutes instead of using a complicated tool. The advantage is JIRA automatically tracks this stuff for you as opposed to email.
I think it mainly caters to micromanagers and allows them to justify additional head count "look at how large our back log is". It doesn't matter that 99% of the backlog isn't very relevant work and hasn't been touched in 2 years for a reason.
We can say laptops are bad because they let people create bad software too. Jira is far from perfect but there isn’t much that solves what it can in an integrated manner.
Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?
I'd say less encourages.. And more easily enables.
You know the saying that money doesn't change people.. It reveals what already there...
Same ca be said to let people make the mess they already probably make.
A disciplined workflow in any technology takes effort and thought. I don't feel like I've ever stopped trying to improve it. Sometimes with jira, other times in spite of it.
I fully agree that the problem is the "JIRA mentality". Specifically, that a developer should be managed with a task list instead of giving them roles/responsibilities in the organization and letting manage the tasks themselves. Sadly, almost all project management tools fall into this trap. A whole different type of tool is necessary to get us out of this rut.
The irony is that I always had my own task list that I kept in parallel to Jira that allowed me to break a Jira issue down into subtasks, subsubtasks, down to any depth of n(sub)-tasks. The best part was that there was no "process" for my task list. It was always just TODO and DONE. Nobody had to review my list or approve it and I could delete and add entries as needed with zero friction.
What really sucks is the cheeryleading and evangelism for it almost like a cult by the very people who are not responsible for resolving issues. Side channeling by email/phone with expenditure of social capital to devs in the know is quicker with our mutual wink wink agreement to file and close the Jira ticket to appease the higher ups above. Absolutely ludicrous.
This is the major problem I see. Just like misleading code comments pollute a code base, bad tickets and fantasy tasks pollute any useful information you might get from a ticket older than a couple weeks.
If we're really being agile "moving something to the backlog" would just delete the ticket. If its important enough, you'll write it up again.
I plan on working on the tickets assigned to me on that day, yesterday, and the next day. If I have blockers I'll type up a slack message. It's not that hard.
That's the problem. You have to actually use Jira to get any value out of it. And better use it properly. That is do it accordingly with your process or the lack of it.
We used to call that anti-pattern "playing Jira Tetris" at a previous workplace. It's excellent at the creating the illusion of productivity. Some people really fall into the trap deep.
I work in the med-tech industry and Jira is a very good fit for that industry. Most compliance issues are solved by defining a way of working that uses a project management system like Jira. Someone else read how to label a product with CE-label and HIIPA, and all I have to do is report my work in Jira. Don't have to understand CE-labeling or HIIPA.
For compliance it must be possible to find who made a change, why they made that change, and how they validated and tested that change. In a heavily regulated industry like medical, it is very useful to have a tool like Jira when the audit comes up.
I still accept your point tough, if you need to go fast and break things (you know, innovate and prototype things), jira is a real blocker and the "jira mentality" slows things down, for better or worse.
Exactly. Computers having infinite capacity is sometimes harmful. One of the things I like best about kanban approaches, especially with physical cards is that they discourage putting in too much. When I look back on previous boards (e.g., [1]), my main thought is we still had too much room. We wrote up and carried along so many cards we never got to. But even so, that's way better than something like Jira, because the limited board meant limited opportunity to distract ourselves with meta-work.
I also don't particularly like Jira. The problems you have, however, seem to be with the very idea of tracking what needs to be done, has been done, or really having any kind of process at all by which a team coordinates their efforts.
That's a very different kind of problem. Unless you spend your career work on projects where you're the sole engineer and the PM/PO doesn't know what they're doing, I think that you're probably going to have a difficult time if you can't reconcile yourself to the utility of this sort of process.
There needs to be a balance between productive work and management overheads. I've worked at hundreds of organisations as a consultant, and what I've found works is the following: 1 manager per 5 real workers where each worker spends 20% of their time on meta-work such as change requests or project tracking.
I've seen many examples of both extremes:
Sometimes I see people working totally unsupervised, essentially just playing and tinkering with whatever random technology seems interesting to them that day. This can be a huge waste of the company's money. Surprisingly often these people are counter-intuitively very productive despite the apparent time wasting. If you take away the 20% management overheads, someone being unproductive 20% or even 40% of the time is either the same or only slightly less productive overall!
On the other hand, the bureaucratic hells of 80%-90% overheads are all too common. These are the organisations where managers would say with a straight face that the floggings will continue until morale improves. These places can be so soul crushing that all of the talented staff leave for better jobs, which is not only a brain drain but also leaves the worst employees behind. Eventually management redoubles their oversight to try and squeeze some productivity out of the remaining dregs, but this just results in even the mediocre staff jumping ship, leaving only the most unskilled, unmotivated, and unproductive staff remaining. Jira often becomes one of the whips used in places like this to flog the remaining unfortunates.
TL;DR: Some management is required but the extremes are bad, and the extreme of too much management is much worse.
Its Jira combined with outsourced or contract developers that only care about getting that feature added. Our app is a mess, loaded with technical debt and hugely difficult to support and use. 90% of devs dont care, they do add their one piece of new functionality and move on to the next one or next project.
> It encourages micro-management. It encourages more and more process.
I think it's a case of there being multiple truths, and depending where you sit on the food chain you'll sing one and not the others:
1. If you're a highly competent dev it gets in the way and wastes valuable time
2. If you're a project manager with thousands of moving parts and a diverse array of talent from almost useless to God-tier it can help keep things on track
3. If you're a rookie you can at least quantify and digest which tasks require your attention and not feel overwhelmed
4. By virtue of some common personality flaws you over-estimate how good you are, underestimate what you need to do, and work on the wrong task and still say it's a pile of shit despite it being exactly what you need
Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.
I don't know if better software can replace stupid management but I've been quite happy with Youtrack. That said you can do some extensive micromanagement with that as well, though it requires some coding to do the truly intricate stuff, which just might be enough to prevent the managers from getting any funny ideas ;-)
it's weird why youtrack doesn't come up more often in these types of discussions. It's pretty good, and interestingly enough they now have a "lite" ui mode to simplify it. It's not perfect though, but I've found it hard to find anything better.
There are literally hundreds of competitors out there. But first you have to describe what you like about it. 10-15 years ago everyone would have used something like Request Tracker (RT). There is Redmine, Pivotal Tracker, Trac, Bugzilla. Those are just a few that I recall using. I've probably used more than that.
There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow.
Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone, but from my point of view I have a simple process for evaluating tools:
1) Can I use it at all? 2) How many of the features I want does it have?
I'm pretty sure Jira would score great on the second question, but since it hard fails the first, I'll never know. And it's been slow for so many years now, I assume they have no interest or ability to fix it. And their slow drift towards cloud installs over letting people self host isn't helping them either since, embarrassingly, their cloud instances seem to be even slower.
(Incidentally, there's a lot of competition in that space, but I've been pretty happy with Clubhouse. I wouldn't mind a few more features, but it's good enough. More importantly, the UI is clean and snappy, and that hides a multitude of sins.)
Do you know that this post is actually breaking the JIRA ToS? Seriously, it's in their ToS that you can't complain about how slow JIRA is...
> Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products
> Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone
My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think.
You don't like that the ticket form has 50 fields you don't need? No problem! All you need to do is to convince your manager to contact support and tell them to track less data about your progress. I bet your manager will love that.
And once they got the foot on the door, who is going to convince the company to migrate away from them?
>My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think.
That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.
I honestly wish it was that simple for us but convincing management is a fairly sales-driven approach and our marketing model is heavily self-serve. We do have a product called Jira Align that's targeted closer to what you're describing. I'd attribute more of the spread to the concept of "Jira is the defacto" fwiw.
Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself.
Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".
As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible.
When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning off the permission checks, you replace all of this communication with the equivalent of 'return true'.
Unless you're running a multi-department enterprise-wide Jira ($deity have mercy on your soul), you're better off eliminating permissions entirely and controlling access to the instance at the network. In other words, if only your developers need access to it, do not add your developer user group to the various site permissions, set the permission to everyone instead, and ensure only your developer's subnets can touch it in the first place.
It is a fundamentally poor design for permission checks to require additional network round-trips. A user's group memberships need only be evaluated once when they log on, with a refresh every few minutes at most.
Access control lists can be easily cached, and then most access checks can be performed entirely in-memory.
Instead of evaluating the full ACL every time, an additional trick is to take the cryptographic hash of the ACL and use that as a cache key. This both deduplicates the ACLs (which tend to be repetitive), and also allows (ACL,UserId) tuples to be efficiently cached.
This way, a page with even a hundred controls becomes effectively a hundred hashtable lookups the second time it is viewed, and even the first time it is opened the overhead is no more than a millisecond.
If turning off security makes a noticeable difference like you said, Atlassian has done none of these basic things. It indicates to me an incredible level of negligence.
About 6 years ago I maintained the LDAP integration code for Atlassian Crowd, which is/was reused by Jira (& Confluence).
Jira (both Cloud and Server) does cache permissions, heavily. Jira effectively has a local cache of user and group relationships for all users who have access to a given blah.atlassian.net Jira, and caches lookup results in a shared cache too. It's complicated by having well over a hundred thousand active Jira sites spread over several hundred stateless servers, which does make effective caching a bit trickier.
AFAICT Jira Cloud's slow feel currently stems largely from the front-end, amplified by the debacle that is modern front-end engineering. It's tricky to get 300+ engineers to ship fixes and enhancements in a multi-million line codebase over 15 years old on a good day. Feature creep in design systems, constant ecosystem churn, and poor build tools all conspire to make it that much harder to prevent performance regressing.
But even knowing all that - yeah, I wish that Jira's performance was 5x better too :)
Disclaimer: am still employed by Atlassian but all views are my own, things may have changed a bit since I haven't touched any Jira code in ages, etc.
The permission performance issue I was commenting on (apparently) resides in the back-end code of the on-premises Jira server.
The front-end code issues other people have raised seem like the type that could be solved by simply turning on Gzip or Brotli compression for static JavaScript content in the web server.
All of this seems to be incredibly basic tuning to have been overlooked, especially given that every public discussion of Jira mentions its slow performance!
As for the Jira Cloud: I just did some quick experimentation. I spun up a free-tier account and created an empty issue. This is the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, high-performance client link, same region as the Atlassian PaaS server, etc...
At least here, most of the traffic is coming from a CDN that enables compression, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of.
Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form!
This required 1.2MB of uncacheable content to be transferred.
With the cache off, a total of 27.5 MB across 151 files taking 33 seconds is required!
The total text displayed on the screen is less than 1 KB.
The page took 4.35 seconds of CPU time on a gaming desktop PC with a 3.80 GHz CPU and a gigabit fibre Internet connection.
A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds!
Is no one responsible for performance at Atlassian?
It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit, every time I...
A customer I am currently working with has a JIRA instance which literally, looking at the firefox network inspector right now, takes 13.04 seconds before it's done loading. It takes at least 10 seconds before the page will even let me scroll. I can't even comprehend how they have managed to get this poor of performance.
Does it keep reloading batch.js? Is it because the URL is changing or is it just not getting cached at the browser? Answering these questions is a first step to speed up Jira.
This is like web optimisation 101. What you did is a clever workaround, but it shouldn't be necessary! Why isn't the Jira server sending compressed content in the first place? If those javascript files are static, they could even cache the compressed versions for extra speed!
Yes, it's slow as balls. I run my own Jira for ~100 users and, despite throwing as much hardware at it and its PostgreSQL database as possible, it's still extremely slow clicking around and trying to use it. Database operations that would have been fast against simple MySQL 15 years ago on a single core server take seconds. What is it doing that makes it so slow?? The PostgreSQL server has most of the working set of data cached into 64GB of memory, for pete's sake, and still it's not enough to make it fly.
Cloud Jira is unusably slow in comparison, too, and when the Atlassian server licenses are not available any more (soon!) and we're forced with having to migrate, I'm not sure what to do. Bite the bullet and just accept the abysmal performance for an easy migration, pay through the nose for the Data Center license, or get people running on a new tool?
Slow, unresponsiveness, and worst of all lagged resizing caused my biggest daily annoyances in Jira.
Several times a week, I click a task, and just want to click the link to an associated epic, or something. But that link keeps dipping and dodging my mouse.
I joined another team which used Asana, and it's much better, although certain things can still be slow.
> there's one huge one: It's slow. Really, really slow
This is spot on.
Its the same reason I hate Sharepoint - every implementation I've used was always incredibly slow, so I would only ever use it when my arm was forced.
I miss old school "legacy" style apps that cached stuff so moving around the app is quick.
Even simple apps like slack suck these days as it always takes a few seconds to move around windows, why the hell can't it cache things? IRC clients in the 90s did about the same amount of stuff and they never lagged swapping servers or channels.
I would guess because in slack the history can change when irc is basically a read only log. Slack has threads, edits, deletes and emojis etc. that will change the history so you can’t cache it
This is my biggest gripe. It's slow and clunky. Confluence is also terrible (slow and clunky). Mkdocs, which is markdown powered, is much better for documentation.
My remaining issues with jira are not with jira at all. Jira can fix its slow ass software, it's feature backlog and I can use mkdocs over confluence. Jira can't fix poor project requirements and management.
How fucking dumb are you if you can't even write a bug report? It's what happened, what I expected, and a how to reproduce bullet list.
Atlassian has been losing money in every quarter for quite a few quarters. But its market capitalization has been generally increasing so shareholders who sold their stock probably made money.
I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.
Unrelated, but... we've got a jira input field that keeps moving the cursor to the end of the input field on each keypress. Perhaps that all do that(?), but it's noticeable when I'm pasting in a URL and want to change the beginning part of the URL.
Example: server-abc.example.com, need to change to server-def.example.com - changing the A then moves the cursor to after the .com, which is also beyond the end of the input box, and thus invisible.
Every bullet point says "Missing...", but I feel like the main issue about Jira is that it has waaay to many features, and that it's super slow!
The only bullet point I do agree with, is that Jira is missing an easy (or IMHO a minimalist / simple) interface. The tool is a mess, and the people using it are probably also using it in the wrong way, making the whole situation way worse.
Don't get me wrong, I like Jira to some extent, but its performance and messy UI are really making my life harder rather than simpler.
I think you are right: the SLOWNESS is a killer. In fact, I think it is THE show-stopper flaw.
I recently succeeded in an 18-month-long effort to coordinate moving off of JIRA at work. We moved to clubhouse.io and it's been great. We were also looking closely at GitHub Issues + something like ZenHub for the missing project-management features — and that would have been great, too.
As soon as we moved off of JIRA, the amount of communication that started happening in the most relevant place — the bug tracker thread — increased by like... I don't know, something like 20x or 50x.
In our years on JIRA (the hosted plan) virtually nobody every discussed the details of the bugs on JIRA. We filed tickets there, and checked them off when done, and used it to review what had gotten done after each iteration — but nobody used it day-to-day. If discussion was to happen about a bug, it happened on Slack (which is horrible for ever finding it again, but it is fast).
The reason, I believe, is simply that JIRA is waaaayyy tooooo slow. Nobody wanted to use it day-to-day. You made a list of stories at the beginning of the iteration, and you checked it again at at the end of the iteration, to mark the ones you did done. I did this too.
Now, all the discussions directly about the bugs/features in the tracker happen directly on the tracker. Which, I recalled, was how it used to be several years ago before we moved to JIRA (from GitHub issues).
There is a lot of other stuff that is clunky about JIRA but I think we could have probably dealt with it, if it wasn't so slow that every interaction — even simple things like "find and open the bug I was working on most recently" or "see what is assigned to me this iteration" — felt like rm -rf node_modules && npm install and you somehow find yourself checking twitter before it even opens...
> I think you are right: the SLOWNESS is a killer. In fact, I think it is THE show-stopper flaw.
I think there are multiple clones of JIRA that literally just focus on the performance part. I think at this point it's unrealistic to expect major performance improvements in a timely fashion with JIRA.
The interface used to be simpler and less in the way of getting things done. Then they added personas, UX and tried to "help" the user. You now need more clicks to accomplish the same stuff while information is more hidden than before also.
There's no way to cater every possible workflow without feature bloat. However, the space is ripe for simpler, more accessible solutions that supports work across multiple projects.
It's not for engineers. Or anyone in particular. They're building to check off boxes in order to sell top down to C-level execs that never touch the stuff.
Atlassian products are all like this, and each one is a horrible trash fire.
Confluence is the worst wiki product I've ever used. Gross syntax, slow, clunky plugin system, awkward permissions. Install MediaWiki and be done with it.
Bitbucket is slow and feels like it's from the 90s. It doesn't seem to do multithreading well - sometimes force pushed branch rebases pick up a new, unrelated author. A bug that hasn't been fixed in years, and only one of many. How many times will merging not actually work?
Jira is a special kind of hell. It's like every team needs their own embedded Atlassian solutions engineer to get it into a usable state. Not an EM or PM, but a specially dedicated role just to deal with Jira nonsense. Why even bother?
Atlassian is like Salesforce for business process, but if it were written by all-remote temp contractors churning through Jira tickets themselves.
Agree with this. My hypothesis is that they’re just ridiculously slow at adopting newer UX principles. The product was successful initially (good for them) and it was just never made much better.
The horrible response times and user hostile UI is shocking, especially if you look at their competitors. It gets in your way all the fucking time. But because they’re embedded in enterprises they don’t need to change much. It’s a big mess.
> Confluence is the worst wiki product I've ever used.
BUT... the direct integration with the ticket system - highlight a list, and make linked tickets (which keep the status info 'live' in the confluence doc) is pretty powerful, and allows a lot of people to keep their business docs, and get status updates without ever having to learn other parts of the system.
A former PM prioritized issues in the backlog by making a ticket and giving it a name like "Groom these next" or "Prioritized for January release", placing it in the backlog, then placing the tickets to be prioritized above it
They also hid bugs from being counted in reports by marking them as stories but that's another conversation
If you want something that is simple use kanban-board like trello, github, an excel spreadsheet or whatever.
The complexity comes from the demand of Jira's paying professional customers.
Eventually Jira will grow too complex and bane the way for simpler tools probably of a different paradigm. Much like how Jira replaced things like HP Quality Center or the tools of Rational Unified Process.
It's funny because I have never seen the mentioned Firefox error on any Jira instance. The problem is mostly server-side: it's slow as hell! I'm personally using go-jira [0], but even that is slow: the problem as I said is not (only) the frontend, but the backend.
I was feeling the same way. Maybe we can get a Steve Jobs of agile development and create the "Iphone of Software Development Management Software". What I (drunkenly) mean is that the customer might not always know best when it comes to UX, especially when your early adopters/feedback providers are human management nerds.
Sniff around a bit and you will find that what is even worse is why it is slow. Even the most simple operations call out to multiple sites. Quitting Jira requires more than three dozen sites to respond in order to actually work. Jira is an example of just how much the modern APIs are fun yay methodology sucks in actual practice.
For most it seems "missing easy user interface" meaning there is an interface. And what they're wanting to do is part of a complex system therefore it's easy to understand why an easy interface isn't there, it's not a simple thing in the first place.
If you want to try something in this space that's really snappy and responsive, checkout out Kitemaker (YC W21) [0]. I'm a founder and happy to chat with anyone that has any feedback/feature requests: hi@kitemaker.co
I was looking at the homepage reading text that explained the Picture Gallery ("when users can reuse images... more likely to...") and then the whole page refreshed with a completely different design. I was on the page for probably about 30 to 60 seconds.
Hi! That’s just a video playing on a loop taking you through the various screens. The “image gallery” is just showing our work item screen and then it jumps to some other screens. Thanks for the feedback though! It may be that this isn’t clear enough
Some constructive advice, your homepage is messy, the ratios and spacing are really off and makes it hard to digest and focus on your features. This will directly impact your actual product. Please don't be insulted , I've spend 20 years in design/branding and want you to succeed but this homepage isn't doing it, you need a brand book with some strict guidelines.
I am reading this comment thread and honestly I don't know that I agree. I think JIRA, like most tools, is as good or bad as you make it. I've been at numerous companies using JIRA that don't seem to have most of the issues referenced here. The only thing I've ever felt like JIRA really lacked in was in a good UX for embedding code snippets or other technical details into issue comments. Native support for Markdown in comments would be a good win.
I actually like JIRA and Confluence and have generally had good experiences using them in multiple companies. One of the main things I like is the integration between the two, and Confluence's concept of spaces so you can have some things publicly facing and other things private, which allows you to use Confluence documentation as user-facing docs, which references JIRA issues directly for known issues, and can write requirements/specs/PRDs in Confluence and reference them easily within a JIRA issue.
The only real problem JIRA/Confluence have is being very very slow. They've gotten marginally better over the years, but they're still terribly slow compared to competing offerings.
There are three problems I notice with JIRA, of which two are entirely the product's fault. The first one you already mentioned: abysmal speed. The second is how JIRA forces certain ways of working which are clunky or intuitive (or by extension, out-of-the-box workflows are difficult to change).
The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary. Most developers do not need this info, and do not have the power to easily change things. All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket. I would believe this is not impossible to avoid, but I do feel a simpler structure using labels, milestones and issue tracker is far, far easier and less prone to being misused. GitLab and Github can both do this as far as I know.
And sure, JIRA integrates nicely with other products (Bitbucket, Bamboo, Confluence). Other products have these integrations on a more modular level and still load faster and have small QoL differences over JIRA. Maybe big corps need a bit more, but JIRA seems to be too focused on managers and suffers from feature creep to the detriment of user experience.
> is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary
Omg, finally someone has said it, I thought I was weird. This is the imperative problem with JIRA, it is not made to help the developers but to satisfy management which is buying the software. +1 for this comment. I have seen its usage in 7 companies and in each and every case instead of simplifying developers workflow it was complicating it due to management wanting to have their data which, at the end, didnt bring anything for the product but were just enabler to make their cute graphs that enabled them to not be involved into development cycle (as they should be) but rather bring out statistics "out of their shoe - JIRA".
And this is also my only (ok, except the slowness which should be understandable for any web browser js application) comment over the JIRA, I dont care what the tool is, how much time it takes (at the end, I am not paying for it), but how much it diverges from the tool that SHOULD help the development while in its essence it mostly helps the management to track their data.
Pretty much. We can divert a little to support customers reporting issues, though I don't feel JIRA is much friendlier here compared to GitLab once you get the hang of both. The only one I see benefiting from this monstrosity is management and upper layers, and they indirectly pay for this through lower morale and retention rates. If you really need the graphs that badly, you might as well spend a few hundred man hours to write a script that imports data, run some data science logic and draw them. And maybe put all that info.
> All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket
that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted
That comes back to the earlier point I made: developers often not having the power to change this. Others (and myself) already mentioned this is not a problem of JIRA itself, but rather JIRA being predominantly sold to management types that do not relinquish control and overconfigure the system.
I would love to see the insides of what we have configured, and toss the junk out. It ain't happening in the next 20 years, and I sure as heck don't plan to stay that long at a company putting little value in the experience of its employees.
Also even just within JIRA it can be inconsistent - I realised that to make monospaced text you need to use:
- backticks when creating a Jira ticket, e.g. `hello`
- double curly-braces when editing a Jira ticket, e.g. {{hello}}
... or vice versa. I cannot honestly remember which way round it is. Of the complaints I have about Jira this is probably the least annoying - but it really shows how irritating the product is.
I haven't used JIRA recently, but as far as I remember the difference existed because they were rolling out a "new" editor, which was active when editing tickets, but wasn't available when creating new ones.
I remember this caused me some data corruption when editing a comment created with the old version of the editor using the new editor. It was a mess.
I have to very much agree with this comment. I thoroughly enjoy using JIRA and Confluence. The two go hand in hand very well.
As many others have mentioned thought, it is abysmally slow. At least their Cloud offering is, which is the core product we use at my job. I've used older on-prem deployments though and they were lightning fast. Seems that they're deprecating this solution by 2024 though.
I recently completed a JIRA survey, and slowness was my number one complaint. Hopefully the Product teams read through those surveys or peruse HN. Everything else about JIRA works great for our Software Development needs.
As a PM, all I really want out of the tools that I use is to be inspired by them. If I have to use it daily, it better have ideas for me to borrow. Jira does not inspire. It's what software looks like when it has no opinion. I hate it.
From your description, it sounds like this would have Slack's problem (which resulted in one of the most upvoted HN threads of all time, https://news.ycombinator.com/item?id=21589647). I've tried Googling around a bit to find an example of Jira Cloud's Markdown environment, but couldn't find one. (I am certainly biased, though, by my strong loathing of Jira.)
I've used both jira and tracker across a few different spots and can confirm that Tracker is refreshingly lightweight.
To me, tracker is an easier user experience for focusing on a stream of stories. And a more streamlined experience for work assignment means more time writing code to solve problems.
Jira sucks but it's not because of these reasons. In fact if you fixed each item here, it would be worse.
Jira sucks because it is unopinionated and infinitely customizable. As a result, everybody who believes they've discovered the perfect project management setup (spoiler: they haven't) is empowered to cook up their vision via an inscrutable set of customizations. This leads to a bunch of inconsistencies between projects and endless bikeshedding. I imagine all this dynamic configuration is also the reason their cloud hosted version is so painfully slow.
There is no magical one-size-fits-all project management setup. Having a tool that is customizable to match your team's workflow is a great win in my book. I've never encountered any organizations where there is endless bikeshedding regarding Jira. Would you care to give an example?
Yeah, I've had really positive experiences with Jira, and I think it's only because the person who configured it knew what they were doing. It was also a smaller company so the limited complexity of the project could have also helped.
I also have a low opinion of jira, but I don't agree with this list at all. I refuse to use jira because it is over-engineered and is generally used as a crowbar to foist non-technical influence upon technical teams, at least in the sites I've seen. Jira is in my opinion a fatal source of friction to the production of reasonable software.
That's not what I'm getting from this list.
Worse, almost all of the points (all maybe? Haven't checked) declare that something is "missing".
Please god no.
Jira isn't missing more features. When you make a list like this, some product manager at Atlassian is going to turn it into a bunch of scrum epics and jira will be even worse in 12 months.
Yup. Jira seems to be a tool around creating process. Management loves that shit because they believe if they put enough checkboxes and fields into a ticket eventually things will be good (or something). It drives me nuts to no end how stupidly complex people want to make the development process.
What should, IMO, have almost no interaction with the ticketing system, ends up being a chore for development which adds 0 value to the final product.
Every project I’ve ever worked on, features are finished, apps and websites are shipped, clients are happy and pay the bills, yet the burn down just goes straight to the right and never down. Sometimes right and up if people added more tickets during the sprint.
We look at it at the end of the sprint and say ah well and continue on our way.
Then sometimes a PM type decides it’s a problem but nothing ever changes it.
Well it's at least an indicator something has gone terribly wrong. Your project management software, one of the flagship features of which is reporting - now tells you essentially "no work is being done". Somebody in management panics, the team is told to get its act together and some variation of "improve the numbers". Yet features are getting shipped and clients are happy. The two most frequent (bad) options teams take to get out of this are:
1) Ignore the burndown chart / any other reports. Everything is fine on the business side, so let's just accept that the reports are broken and not spend time trying to fix them.
2) Have everyone invest more time into using the system (usually on an ongoing basis), so that it produces the correct looking down-and-to-the-right chart.
The problem is that with #1, the software is arguably not producing much value, if any. The problem with #2 is that you're spending extra energy and effort to make the software happy, even though outside of the software it seems like your team is working well, shipping features and keeping customers happy - all of which are more important than a pretty graph.
Hit the nail on the head with this. It's sort of like a gimmie "problem" that can be weaponized if anyone is in the mood, but mostly just ignored entirely.
Yeah, that's right. Before we escaped JIRA, my team would often do that, too, even for regular sprints. Make a checklist in a collaborative editor tool like Google Docs or Notion, and just do the day to day work there.
Then somebody would have to copy it to JIRA so the work would get tracked.
But very little of the planning, work breakdown, day to day updates, or discussion actually happened on JIRA because it was literally like a hundred times slower (with the convoluted UI compounded by incessant "wait... is it even loading?... oh, OK, it finally loaded" at each step of the way).
I manage a team of devs but my clients love to use Jira. So I typically use something like Board Genius to sync between Github issues and Jira. This also let's me keep my devs out of Jira so they can just focus on actual work and not worry all the discussions that happen in Jira between my clients and project management.
alias jo="jira open"
alias js="jira show"
jos() {
ticket="$1"
if [ $# -eq 0 ]
then
jira open
else
jira open PROJECT_NAME_HERE-"$ticket"
fi
}
jss() {
ticket="$1"
if [ $# -eq 0 ]
then
jira show
else
jira show PROJECT_NAME_HERE-"$ticket"
fi
}
jqlf() {
jql="$1"
chrome https://__PROJECT_NAME_DOMAIN_HERE__.atlassian.net/issues/?jql="$jql"
}
alias jm="jira mark"
alias jcs="jira create --project PROJECT_NAME_HERE --type 10001 --priority 3" # create story
alias jcb="jira create --project PROJECT_NAME_HERE --type 10004 --priority 3" # create bug
alias jce="jira create --project PROJECT_NAME_HERE --type 10000 --priority 3" # create epic
alias jjq="jira jql" # custom query
alias jql="jira jql" # custom query
# example:
# jjq 'project = PROJECT_NAME_HERE AND sprint = 158 AND "Epic Link" not in (PROJECT_NAME_HERE-4695, PROJECT_NAME_HERE-4373) AND status in ("Push to PROD") ORDER BY cf[10008] ASC'
Let me walk that back a bit - I have no experience of the cloudy version which unanimously seems to be derided as slow. Atlassian - you might wanna fix that. Like yesterday.
But server (& datacentre) editions - best in class for my money.
In terms of features, the Rally / Agile Central (did that just re-brand again?) rollup roadmap view is the only missing feature i crave. Atlassian should just merge the portfolio product into jira.
As for everything else - speed is absolutely fine if hosted well.
I tend to council people to try to use less features not more - often jira features are used to attempt to work around challenges that are best addressed by talking to people instead.
It integrates with everything, no matter what source control, build pipeline or IDE tooling is in use, there’s integration with jira.
The REST API is absolutely usable (mostly for workflow automation and analysis purposes).
Server starts heading towards EOL in February 2021 unfortunately. They’ve said that they will support it for three years after that date but you’ll only be able to renew licences (not buy new ones), the pricing is going up and you can’t change tiers.
Datacenter is still supported but I think they’re jacking up the price of that too.
> But server (& datacentre) editions - best in class for my money.
Well, performance wise they're as bad as the cloud version. Even when you give the instance a lot of CPU / Memory. The problem is not only the Spring application itself, the DB seems to be missing some indexes or the queries are super badly optimized. God only knows what's really happening under the hood, but my self hosted Jira instance isn't any better (I've tried them both, cloud and on-prem).
No, cloud is slow and has been slow for years. On-premise is quick enough, but only if you ensure you have no slow bottle-necks (DB, spinning disks, heavily shared virtualization).
Jira doesn't use Spring--you may be confusing it with Confluence which does.
The Structure add-on does a great job of rolling up. The Portfolio product was way too difficult to use--they rebuilt it so maybe things might be different now.
I agree there are/were the best in class for the money--but with Atlassian throwing all their resources into cloud now, raising the prices on on-premise, I worry for its future. I suspect we're only going to get timid features--nothing bold that might improve the UX/UI, or anything that will break the migration path to Cloud, which is their end-goal.
If I was starting out again, I'd probably examine YouTrack where there's at least some assurance they are investing in its future.
I kinda agree. I am fine with using Jira. Now when I know the workflow I would not bother with another tool for the same things that we are forced to use Jira for.
That said I would rather to "issue tracking and planning" in a checked in text file and maybe have some bug tracking tool rather then working with Jira.
Every time I upvote a submission by the title without reading it I regret it, and this time is no exception. Some of the items don't even make sense as written. The fourth item, for example, has two huge issues. 1. It's about Confluence, which is a different Atlassian product. There's some Jira/Confluence integration, but they are not the same thing. 2. "you have to save the other user changes also and while viewing the confluence, if you want to edit, the user will be redirected to other pages." That sentence is gore.
As others have said here, the main problem is just that it’s really slow.
Apart from that, I think the only item on this list that really puts its finger on a key problem is #1, inability to manage dependencies between projects. You try to work around Jira’s problems by splitting the work into separate projects, but then they’re almost completely siloed, and Jira doesn’t help you connect them up.
The other problem I have with it is that it’s too fussy about the hierarchy of issue types. You have sub-tasks, stories, epics, and initiatives. Each one has special semantics and certain supported operations. If you started defining some work at the wrong level of granularity, too bad, because switching everything to a different tier is complicated and massively slow (literally a multi-page wizard, a progress bar and a confirmation screen when making a “mass edit”, i.e. a trivial edit to two or more issues).
Hierarchical issues is a good idea, because that’s a very natural way to break down and refine work estimates, but it should just be an arbitrary tree, not a strict and limited set of tiers.
Too much complexity, not enough generality. (And not enough speed.)
Looks like the complexity is a consequence of its generality. Much like Word it serves so many different cases that many people end up using only subsets of features. Yet the code must support all possible cases.
Competitors too will likely drift into the same quagmire unless they're unashamedly opinionated.
Choice of administrative services can definitely be a symptom of a larger problem. When most of the services used are unfriendly to the user and one is expected to use these every day, especially with alternatives available, that doesn't tell me they value their workers a lot.
Perhaps. Could also be that management uses the tools they are familiar with, even if overkill. I use Git for one man projects even though Subversion or even just periodic rsync would suffice.
Software development and deployment process and the tools used to follow (or circumvent, as the case may be) are a large portion of the work of a software developer.
It makes a huge difference in my happiness if I'm fighting with procedures and tools all day, or fighting with user impacting problems all day.
I imagine this is true for people who don't share my process and tool preferences, too.
Are you asking if people care about the tools they're going to have to work with to practice their profession? Yes, of course.
I imagine you do as well! If you were looking for a job and they were programming in VB 6 and using CVS for version control I would imagine you (or almost everyone if not you) would say 'hmmm I'm not sure that's how I want to spend my day'.
I know I don't want to spend my precious hours on Earth trying to remember which markup syntax this particular input box uses in Jira today.
CVS and VB6 are more central to my role as an IC. So to me the issue tracker is not significant. Though I agree the inconsistency in JIRA input formats is a bit maddening
What’s killing Jira and the other tools in Atlassian’s suite for us is them killing off the on-premises server products. Some of the companies I work with have defense security requirements and just can’t use it in the cloud (unless they followed a lot of stringent requirements that are not on their roadmap, and I assume they would charge a lot more for that).
The cloud versions are also far more expensive and while I’ve always liked the software in general (apart from it being dog slow), a big draw was how cost effective the server products were. So I’m about to start evaluating GitLab, YouTrack, etc. to start moving these companies off Jira, Bitbucket and Confluence in the next year or so.
Great article. As you are likely not native English, just as a tip you can actually simplify a lot of statements by removing the word ‘the’. As one example:
> When the users need the features from Jira and request them to configure the plugins for many application scenarios, which contribute to the overall complexity of UIs.
Becomes
> When users need features from Jira they request plugins, which contributes to UI complexity.
The first has incorrect use of the definite article (the users, the features), but to be honest it’s less about specific grammar syntax/rules and more about making writing easier to understand and more concise.
When you say “need the features”, that immediately makes me think “which features?” because it reads as if you are referring to some previously mentioned features.
> Missing Easy Search Option for Finding Issues in the Project
Really? I think search is one of the most compelling features.
I find most of the time when I can't find something, it's because of different terms used, such as searching for "schedule task failing" vs the ticket saying "job run error". (Usually once I eventually find it I just edit the ticket to have the other keywords I tried)
The UI for selecting advanced search is acceptable.. it's not the easiest thing - for example searching open vs closed on GitHub is an much simpler - but it also exposes a lot more of the fields.
Personally I use the text-based JQL interface most of the time. It's very powerful, and as the name implies, anyone that knows SQL will find it familiar. A quick example, an easy way to find bugs closed in the version you're releasing but that weren't correctly tagged: `(type = bug) and (fixversion is null) and (status changed to closed after 2020-12-02)`.
And search you do is updated in the url (easy to share with others), and even better, if you paste that url into Confluence, it turns into an embedded dynamic list. This is great for release notes, or making category pages of certain types of tickets (eg: all open bugs related to feature x, or all bugs older than 6 months with more than a few comments, etc). Yeah you can build reports with this, but I find these are more accessible and used when they're organized within a logical structure in the wiki vs buried in a flat list of dozens or hundreds of other reports.
It has a markup language that accomplishes the same thing effectively but has a completely different syntax. This is super annoying when you are bouncing between pull requests in Atlassian Bitbucket and JIRA tickets. I have tried to create a heading with # only to end up with an <ol> at least a hundred times.
I imagine this is because JIRA (2002) predates Markdown (2004), or at least its mainstream popularity when GitHub adopted it.
Is that an excuse? If we have to make a fair comparison, HTML 5 is newer than both: is that a reason why one shouldn't not update the procuct?
As an additional side note, Jira updates are NOT free. You have to pay for a license fee every year to get the updates + support, but the product unfortunately remains kind of the same: super slow and with missing basic features (e.g: Markdown)
The new rich text editor still confuses me when it comes to newlines and quote blocks, in months since it's been gradually rolled out, I still can't remember if it's Shift+Enter or Enter to end the quote block and what kind of newlines work with quotes, if it's the selected text or a hidden paragraph that quotes are applied to and so on. Just let me edit the raw markdown as before or expose the underlying markup model when editing.
I've made the switch back to Redmine for my personal projects. By now it has full Markdown support for issues and wiki. Faster than Jira, and easier to use.
The one thing that annoys me is that even after all these years of JIRA they still haven't fixed their shitty WYSIWYG editor. I can't count the number of times I've written something and then end up with random asterisks all over the place because it failed to figure out what is bold or what's in a list or whatever.
What is missing in my opinion? It is consistency between the atlassian products and/or adherence of industry “standards”
Confluence and JIRA use a different markup language for posts and none of them uses Markdown (in any flavour), which I would also use to write in-code documentation, like in a README file
The larger problem is that you cannot (AFAICT) edit the markup directly in Confluence or JIRA. I believe this used to be possible, but has been removed in the cloud version, and will die with the server version.
The markup you write gets turned into in-editor "objects" (for lack of a better term) as you type it out. This makes editing an incredibly painful experience. I am occasionally asked to document something on Confluence for a client and every time I feel like I am fighting a battle just to make a basic document.
For example, I strongly dislike their implementation of ordered list editing. They have tried to make the ordered list editing mode "smart", but it mostly just gets in the way, and is harder than writing it out manually. Additionally, you cannot embed other "objects" in an ordered list. If you attempt to insert a file object, or something similar, it splits your ordered list into two, with the second list starting its ordering at the beginning. This would seem to defeat the purpose of having a rich editor with embeddable objects, since I cannot use them if I am making an ordered list, such as set of "how to" steps.
I usually give up an hour in and switch to writing in my text editor instead, but even then Confluence will mangle my input in surprising ways when I paste it in. Rule #1 of making an editor in my book is that it has to be, at a minimum, as easy and useful as a basic text editor. Microsoft Word and LibreOffice, in spite of their faults, are quite good at this. I would guess most software shops could not implement a WYSIWYG editor at that level of polish, and they would be better off just providing editable markup.
JIRA is a bit like linux. It only really sings when you have a skilled admin to set it up and maintain it.
I have used a whole bunch of ticket/project managing tools in a number of different orgs. By far the most useful is JIRA.
taiga.io comes close, but lacks the admin interface and multi project overview that jira has.
Trello is ok, but terrible for large teams, or large projects. Subtasking is a pain and there is no real concept of a sprint. its ok for replacing notes on a board, but terrible for recording state.
Some of these criticisms are valid, but compared the competition[1], I'd choose JIRA 7 times out of 10.
[1] dont get me started on the "clever" people that decided to make their own in house solution, kneecapping the entire planning ability of a 70k person org.
My smaller team settled on Asana and I really like it. It's much more approachable than JIRA, and while not as powerful, much more so than Trello. Subtasks/relating tasks to other projects is great and I can easily see a birds-eye view of my upcoming pipeline (referencing tickets on other projects) at any time.
Does anyone here get to use Basecamp? It looks awesome and I’ve read up on their Shape Up process but have yet to find any organizational support for it in my professional experiences.
The ui is a little non-intuitive, but good for small teams. For repetitive process work or small distributed teams, I also like Azendoo or even Asana (which has the reports that managers crave)
Jira sucks because middle management wants to be able to look at stats about stuff like estimated vs achieved points to get a fake feeling of control and hide the fact they are useless powerpoint generators.
[Current Atlassian employee here] This might be biting off more than I can chew, but if anyone has tangible ways they think Jira can be improved for non-tech team members I'd love to hear them. Happy to chat via email or Zoom about them and try to add some of the fixes into the upcoming roadmap.
Based on everything I've sorta-kinda-summarized here, the #1 thing you guys could do is speed up Jira Cloud.
My company uses it and tolerates it, but at this point it now takes 8-10s to load a single issue from the board view, and ~5s to toggle the edit state. There is basically not a single action I can perform that takes less than 5s to execute, and some take more (backlog, etc. view take upwards of 30s to load a few hundred issues).
This is just not OK. And we're using hosted, Next-Gen. No fancy customizations.
Every. Single. Click. takes 5s+ to register a reaction. I'm on a gigabit internet connection and have a 16" MacBook Pro with all the dials turned up (eg it is NOT me).
Whew. At 8 seconds I'd probably call for the tool to be removed. I had a similar experience while at Atlassian at one point and then we found a way to speed up the (Jira Core) boards by ~5 seconds after changing some JQL for the board logic. That change should be in effect for your org but you'd need to use Classic Business projects.
Fun fact, next-gen might actually be a reason why your instance is running slower. A side-effect of NG can be the slowdown from each project with its own custom fields and that effect multiplied hundreds of NG projects across an organization. Then (I think), when loading your project it calls all the fields to see which fields it should show. Not an ideal rec, but I'd check out Classic projects and see if that speeds things up for you and your org.
Speeding up Jira Cloud is a top priority for Atlassian this year so you should see some improvements coming. I'm working on a new view right now in Jira and we've been able to load about 100 issues in ~1-2 seconds. It lazy loads, but we can flip through 500 easily once you've scrolled to the bottom. Should be able to get that in your hands this coming year.
I appreciate you jumping into a thread like this and it's great to hear that effort is being invested to speed up Jira Cloud.
However:
> we've been able to load about 100 issues in ~1-2 seconds.
I'm sure there are a ton of things that go into speeding things up and I don't mean to diminish the amount of work involved, but might I suggest raising the performance bar even higher?
Is there a world where loading 100 issues takes 300ms for example? Anything over that typically tends to give users the impression of things being slow.
Haha fair enough. The issue will be, and currently mostly is, the effect you see on performance at scale. Small instances don't have instantaneous interactions but they're still much faster. Here's a quick video (https://imgur.com/a/8ZJrhMZ) of a dev instance (slower than prod) with the new feature. Loading of this view feels way faster than the board does.
The work I'm doing is separate from the performance improvements, so hopefully the two initiatives combined will get us a lot closer to what you're asking for! Again, we'll have to see what it looks like in production at scale, but I'm optimistic it'll be a much better experience.
I'll chime in and say thank you as well! (Both for your work on this and for addressing it in this thread). Looking forward to seeing the improvements too.
Is it Jira that sucks or the management methodologies that cause it to be such a dumpster fire? Scrum-style management is the norm now: it is increasingly difficult to escape it now. So this means project managers are chasing burndown metrics and the like, and organizing everything on boards that are tweaked to death.
Atlassian is basically the centre of the so-called "Agile" industry these days. Jira is just a reflection of it.
1. When editing a comment, the textarea is tiny and placed in a pop-up, instead of in the page. Can't resize that to see the comment better.
2. After disabling shortcut overrides, the shortcuts are simply disabled, along with the default browser behaviour for them.
3. Refreshing a page resets scroll-status. Seriously, webdevs, stop hijacking normal browser scroll behaviour. You always make it worse, never better.
4. If your login session times out when you're writing a comment, you can't publish it, but the error message isn't clear about the reason why. There was some button in the error message that caused you to lose the entire contents of the comment you were writing. Happened to me several times after writing comments 8+ paragraphs long. It's infuriating.
The problem with Jira is management shifting overton windows over time and making it into a blocker to work instead of a tracker of work. I just checked, on one of my main work boards, to create a new ticket, there are 33 fields to fill out, at least half of which are mandatory. In the middle of a highsev incident, I absolutely hate the time sink, and have been trying to figure out ways to automate away jira as much as possible. I think Jira can be used correctly, but over time PHB's ruin it's potential.
The other problem with Jira is the Atlassian push into confluence that tends to go with it. Confluence is so infuriating. Oh what, you want to do a simple operation like copy-paste data from one section of a table to another? Fuck you. You want built in markdown? Fuck you. You want to embed github pages? Thats a plugin and an ordeal to get approved...etc
People always talk about how it's just a wysiwg and so its for the non-techs, but the thing is it's so specific and non-standard they are still having to learn how to use it anyway. Why not just get them working on github wikis or something?
Also: ffs, stop trying to do "smart searching" for me! It's literally the most useless feature ever, and has never returned anything close to what I was looking for. Yay for having to learn JQL just to do a semi-advanced search. How many query languages do we need to know these days?
Why do I get the impression that either Zapel or clubhouse sponsors this domain? :)
Anyway, from personal experience of working with large, distributed teams and (later) leading team that included developers, designers (who had no idea what software development workflow is), and electrical engineers, I have to say that still there is no replacement for Jira. And I'm saying that after trying dozens of alternatives.
Now, maybe things got changed in the last five years, but something where Jira still shines IMHO:
* Self-hosted, free for small teams, you get access to *every* release they made. All these cloud-hosted solutions sound nice until they close the shop.
* Almost infinitely configurable. Going from Jira to enter-your-favorite-simple-tool feels like going from Emacs to the chalkboard. Your CEO likes workflow X, sure. Your designer wants workflow Y, no problem. Your plumber used to Z, done. Irreplaceable when you work with the teams from different fields.
* Bazillion plugins, integrations, name it. You are still missing something, go and write a plugin in any JVM language you like. It probably will work for all Jira versions with small modifications.
* Management, CEOs, even front-end desks like it. Easy to sell, no matter the price. I had a harder time selling Zimbra (which is free) to CEO than Jira, because every CEO knows about Jira :D
Right, it got slow over time (I believe the main reason is clunky UI), but you have to pay the price for all those features. If I'm Atlassian, I'd probably add some optional light add-on UI, as Jenkins did with Blue Ocean.
Atlassian is in the process if killing off the self-hosted Server versions of their products.
It used to be really annoying that the plugins were split between Server and Cloud. You'd find the prefect plugin for your task and then find it was only available for Cloud or Server.
I disagree. What makes JIRA a pain is that it has too much. It tries to be a solution for every possible workflow and ends up being a slow, clunky, and confusing solution for all of them.
I personally think the best thing Atlassian could do is spin of JIRA into multiple apps which all use the same core, but have different interfaces designed for different workflows. Of course, that's much easier said than done with such a ubiquitous monolith as JIRA.
For us Jira became the only option for scaling engineering.
Do not bother about if you have less then 3-4 teams. But if you scale, essentially it is the only solution we found which can fit everyone needs, and give deep enough insights about engineering metrics. And obviously Jira can be very light or very complex. It gives you a lot of building blocks and it is your choice how to use it.
What I don't like about Jira is that eventually everything ends up in a poorly structured pool of "Work complete" tasks.
I regularly come across situations of the form "we finished Task XYZ a few months ago, but I want to come back to it." Maybe the ticket has an attachment we need for long-term documentation purposes or a test detail we need the next time we review the code.
Jira search rarely finds anything useful-- the S/N ratio is terrible with non-development tasks mentioning XYZ, yet ignoring actual XYZ tasks due to poor naming and heirarchy. I usually instead look at the code itself, see in the git history "This was modified in ticket 345675" and then use that to index Jira back to the info I want. From there maybe I can walk between linked blockers and sub-tasks to get what I want.
My pre-Jira experience was on Basecamp v1/v2. I appreciated the forum-style layout, because it tends to allow for a few key things:
* "Search" and "browse" are both well supported use cases
* Old content remains usable and structured, rather than dropping off a cliff after the last ticket closed.
* Content can be grouped as it makes sense-- say you get a customer feedback item that touches on three eventual tasks. It would have to be (possibly sliced up and) attached to all three tickets in a Jira model.
* It felt "discussion-first"-- the discussion of what to do and how we want to do it is central. This tends to archive some of the subtle choices and gotchas that won't appear automatically in a ticket.
I always dreamed of a system that basically added lightweight ticket/kanban model on top of Basecamp. I can see the value of tickets as a trackable unit of work, but it feels like this would be little more than a few tiny tags decorating a readable discussion flow.
Is there a better product out there that can communicate what the development team is doing to non-technical people?
I like Jira when I don't have to use it. For example, setting up GitHub automation so that changes from Git will cause tickets in Jira to transition to the next stage. Or, automating a transition from "Pending Estimate" when a Jira user assigns story points to a ticket. The automation features in Jira are far beyond anything I've ever used before (one might even consider it an "IFTTT for project management"), and on most teams I've been on, very much under-utilized. I can even automate starting the process of development when design is finished, as when the design ticket is marked "Done", the development ticket it's linked to will change to "Pending Estimate", as it's now possible for a developer to estimate how long it will take to implement the given design.
I would like to try a more visual and spatial approach to project planning software. Most of the major solutions, like JIRA, are more like interacting with a RDBDMS through a UI. (Although I admit JQL is very useful, so I don't want to throw that away entirely.)
Here's another product I found recently that allows users to draw out their project plan, and have it turned into management-friendly reports automatically:
Jira has two different WYSIWYG fields for issue descriptions. The one in the edit-issue form understands Markdown, but the one in the create-issue form doesn't. It's been this way for at least a couple of years.
Jira could become perfect in every other way, and would still suck if they don't fix this.
Co-founder of Zepel.io [0] here. Thank you for giving Zepel a shoutout in the Jira alternatives section of the landing page. Would love to get feedback from the community regarding our App.
As a dev working in a team with "sprints" and creating/ solving tickets, I find the interface awful.
I remember 10+ years ago jira had straightforward tables, it was much quicker to add, remove, close issues. I’d open a bookmark to a page with a simple table listing of all issues assigned to me.
I don’t know what the heck is going on, now the ui is this awful "modern clean" style with popups everywhere, sidebars, everytime i look at an issue it’s cramped in a tiny column, or i have to open in a new page. The whole ui is so slow and clunky, you have to expand/collapse content all 5he time. All in the name of what? Is scrolling down a page so difficult for a user? How does Amazon make money?
When I got my first job reporting to a non-technical executive and had authority to pick the PM tool, I thought this was my chance to find the Tool That Didn't Suck. Going down that rabbit hole led me to the sad truth that it'll be impossible to make a project management tool that the engineer likes until the engineer stops perceiving project management data entry as busy work. Finding a new tool ameliorates this until the novelty of working in a new UI has worn off.
Engineers are an autonomous bunch, and the best coders among us despise doing anything that isn't actually writing code. Unfortunately, like doc writing, there is more to being a good engineer than writing code.
I was a JIRA admin for a waterfall-based company (Japanese). They did process hard. Agile was a cussword, and the JIRA workflows were standalone engineering efforts; complete with custom JIRA plugins, written in Java, because even JIRA couldn't handle some of the process.
I guarantee that it would have had most of the folks here, whimpering under their standing desks.
It was the Tenth Circle of Hell.
It gave me a sort of PTSD, so that, now I'm on my own, I try not to write anything down, and, if I do, it's usually a small list on a whiteboard.
If I never see JIRA again, I will die a happy man.
That said, it is like blaming the asphalt for the eminent domain seizures for a road. It's a symptom.
Don't think it's mentioned, but actually what I hate most about it is that there are plugins that seem to do useful stuff, but they're paid-for plugins that also require the IT department to do something.
It's hard to imagine a more hopeless prospect that even one of these two things occurring (people agreeing that we should pay for something, and IT doing it in a timely fashion), but both at the same time and just because some lowly IC (or even whole team) wants them to is far beyond the realm of possibility.
I got pulled in as the acting sysadmin of an on-prem atlassian suite at my last job after the I.T. dept lost everyone who knew how to use linux. The worst part of doing upgrades by far were the 3rd party addons everyone had added to Confluence etc, they always screwed up the upgrade process.
I didn't really mind using JIRA to track my daily dev work, it seemed fine to me. It was annoying that each team had different custom fields etc and seemed a bit unwieldy in that respect.
The community/FOSS version mainly lacks the kind of reporting that jira has (the paid/Enterprise version has some basic reports, such as burndown charts). It's not perfect, but it's fast, simple and has an easy API and webhooks.
In the field I work in (CRM/webdev/consulting), JIRA used to be everywhere. Now all those shops have moved to Gitlab.
Phabricator is pretty good except it has pretty much zero CI integration. Kind of annoying.
You also have to pay to even comment on issues. I think that's a pretty great way of getting companies to pay for support but it's also annoying if you want to work with other freeloaders on issues.
Also it's written in PHP which means you aren't ever going to want to read or modify the code. No different to GitHub, or probably even GitLab but I can definitely imagine modifying Gogs/Gitea.
OP mentioned "non-cloud", so I assumed they wanted it self-hosted. You don't have to pay anyone for commenting in Phabricator when you're self-hosting it.
Err, I think you misunderstood. You have to pay to comment on issues about Phabricator. On their official bug tracker. Like, if you find a bug, or a solution for a known bug, you can't tell them without paying.
Doesn't have anything to do with cloud hosting our self-hosting.
Jira is not all that bad. With Jira It's easier to write stories outside of the tool and copy/paste in. If you have a side hustle or small team Jetbrains YouTrack is free to 10 users (I think) and it's awesome.
When I read the list of reasons "Why Jira Sucks" what came to mine was the Charlie Kaufman movie "Synecdoche, New York". In that movie, a playwright keeps expanding the scope of a play to more and more encompass the scope of reality itself. Likewise, some of the points (1, 2, 3, 5...) in the writer of "Why Jira Sucks" wants Jira to be bigger, to encompass the variety of ways work can flow.
> Missing Easy User Interface to Edit and Update Confluence
There is no “easy” UI for this. The problem to solve is merge conflicts, and Atlassian (rightly in my view) clearly decided that real-time collaborative editing of the draft beats forcing users to do merge conflict resolution when saving changes. Wikipedia takes that latter strategy and it's a huge hassle.
We're getting off our old ticket/wiki project system this coming year as it's being sunsetted. Jira is one of the alternatives we're investigating, because several staff have used it in other jobs. I also used it for a brief time, and I was not in love with it. I often felt like it was arguing with me.
There are so many systems out there. Right now we're also evaluating YouTrack from JetBrains and OpenProject.org (which is a fork of a fork of RedMine).
We don't want to have to move again any time soon, so while we're evaluating features we're also trying to predict stability and viability. To that end, when available, I'm including in our evaluation notes 1) when the company making the system started; 2) when the system was launched; 3) how many staff the company has.
JetBrains started in 2000, YouTrack launched in 2009, and they have over 900 employees. OpenProject launched in 2012. Both seem to be stable and under active development.
ClickUp has a lot of features and looks nice (we haven't dug into it yet). But they launched in 2017, and raised Series A funding in June 2020. So they're young. That doesn't mean they're bad. It just means they're less known, and have not proved long-term viability. On the plus side, it also means they don't have the 18 years of cruft in the system that Jira (launched in 2002) seems to have.
In my experience the right project management system can really help developers, so I always want to hear everybody's experiences, good and bad.
JIRA is just fine. Can't really go bad with it. If you have limited needs, you can try GitHub or GitLab Issues. But for a team which may end up growing, JIRA will work. It has good integration with GitHub/GitLab, and with Smart Commits enabled, most of workflows can be baked into it. It's slow, but judging by this thread, I suspect Atlassian customers are complaining about it too, so hopefully it'll be heard.
After months of frustrations dealing with JIRA, our team switched to Youtrack[1], it is more than 2 years now using it and we are extremely happy with this tool. Best yet, it is supper affordable for small teams.
I haven't encountered a bug/feature tracker that doesn't suck. They're really designed for managers so that they have some glimpse into what the people they are managing are working on. Something designed solely for engineering teams would be much simpler I think.
It looks like one of may marketing websites, in this case build by clubhouse or zeppel. And I'll be frank, clubhouse does not work at all for complex software projects. Maybe it can fit some web consultancies flows or similar, but it is build for VERY specific niche.
Since many people are also complaining about Jira UI, I've been working on a CLI app during the holidays in a hope to speed up my Jira workflow to some extent: https://bit.ly/38P12bv
I remember when I was working in a start up we used a simple Excel spreadsheet to track bugs. We eventually transitioned to Jira and it was good.
I now work in a much bigger company and we use an Excel spreadsheet to track the Jira bugs. It’s very annoying.
If anything, Jira tries to do too much. It is like Excel, tries to fit every need in its domain. That it still has limits does not mean it sucks. Quite tiring when people reach for that word for nitpicks and personal opinions.
Jira is by far the worst software I'm forced to use. The fact that I can't even reliably find old tickets, not even by search which should be a last resort, is enough for me. It's a steaming pile of crap.
Am I the only one who has never had an issue with Jira? Sure, there are some things that could be better. But, overall, I find I'm content with Jira.
My belief from seeing many organizations struggle with Jira is they have process issues that need to be addressed outside of Jira. Jira is simply the place where their process becomes visualized and put into place - so it gets blamed for the breakdowns.
Reading through this list, I can picture exactly why this user is having these complaints. Some of these a definitely UX frustrations, but many of these seem to be fundamental process issues or contradictions. For example, the website claims "missing easy setup" - while also listing a bunch of things that demonstrate the complexity of their Jira setup.
-----
tldr: If you're having the issues the author lists, you should probably check your process. Jira is doing you the favor of highlighting where it's broken.
I'm surprised this doesn't mention things like the poor performance, or the fact that some screens expect text in textile format whereas others use markdown
Does anyone else think that Airtable is headed down the same path? Hot mess in terms of trying to do a lot, and never being able to find out what i actually need?
Everyone in our company hates redmine. We were doing great before when we used trello, but managers want to track and feel they have control of the projects.
It would be nice if any of the alternatives would be in line with Jira cost for a large enterprise. I can’t recommend this to anyone if our cost for issue tracking would quadruple overnight. Not to mention the migration costs...
If you want a normal software engineering process, where you want to check in with your colleagues after 1-2 weeks on the progress etc. it's not going to happen. The normal concepts of sw. eng. aren't in Monday. It's more like a clunky to-do for non-techy people. Simple things are extremely hard in Monday. For example seeing all the tasks from all projects assigned to you -> hard. I'd rather stick with GitHub/JIRA
My workplace uses Monday.com and some folks like it but I personally find it clunky and underwhelming. In my opinion, it tries to do too many things and doesn't do any one thing particularly well. If you are just wanting a kanban board, you are better off sticking with Trello. If you are wanting bug tracking, feature requests, etc, you are better off with things like GitHub Issues and other specialized tools. YMMV of course.
Jira is a generic issue tracker for any industry, not a bug tracker for software development. That’s why in 2020 it doesn’t work for software any more.
Trello is great for small projects and for personal lists and boards. I certainly wouldn't want to manage a complex project with a large software team from Trello.
I haven’t used any of those IDEs, but really, is Minecraft your example? A game with graphics so simple it should work on a Pentium 4 but requires a very beefy computer instead because it’s written in Java.
They rewrote it (not sure if in C++ or C#) for the windows store and it works perfectly on computers that can barely run the Java version.
You might not be familiar with how modern computer graphics work. Objects and textures are loaded into the GPU and managed with an API like OpenGL and shader programs written in languages such as GLSL. Java, in this case, serves as the engine that ties everything together and runs the core game logic.
Microsoft rewrote it because they're not a Java shop. Microsoft Games Studio not only uses C#, but their mission is to increase adoption throughout the industry as it feeds into Microsoft's ecosystem. Microsoft is about developer mindshare.
C# and Java are incredibly similar languages. They're almost indistinguishable. Pointing to C# as if it's substantially different from Java makes me think you've never used either.
Java minecraft did have issues. Professional game streamers were having issues due to the pause-the-world garbage collection.
I don't mean to over hype the issue, minecraft became on of the most successful games in history riding on Java. But the re-write to C++ was not just because Microsoft is a C++ shop. The C++ rewrite delivered measurable performance gains, making it much better on low end devices especially.
I know exactly how it works. Java runs the game logic, and it does so so slowly that the game skips frames. If you’re claiming that the game logic and the code that runs the graphics are completely untied and run independently that’s wrong. The graphics code cannot paint another frame if it does not know where the objects are because the game logic, written in Java, is lagging behind.
C# is much faster than Java. Comparing them in real life performance situations (and not synthetic benchmarks) is almost a joke.
As opposed to C#, Java (alongside C/C++) is widely used in low-latency applications for high-frequency trading and HPC. Almost no one uses C# for high performance software.
Source: have been doing low-latency engineering for over 15 years.
It's quite apparent your experience with Java language/runtime is outdated and/or shallow. Maybe try reading up on it before making strongly opinionated comments like this?
It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process.
tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it gets taken for the central thing. This is an illusion. Fixing a bug without filing a JIRA ticket is in itself progress. Moving a JIRA card without any other change is not. Yet the second is what's visible and therefor what's rewarded.
Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host.
In case the cancer metaphor didn't make it very clear, I don't like JIRA much. Yet if JIRA were to die today, the middle management who live by JIRA would replace it with something else equally bad, if not worse.
Filling in missing features won't and can't fix that.