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.
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.
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 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.
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.
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”.
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.
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". Their recommendations may not 100% work for your organization, and that's okay -- tailor it with an eye to outcomes for your team.
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.
That being said, my current manager is super awesome about minimizing our JIRA involvement so I really shouldn't be complaining atm.
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.
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.
 https://en.wikipedia.org/wiki/Managerialism, and also see https://www.amazon.com/dp/B00A76WZ96/
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
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.
 e.g.: https://www.computerworld.com/article/3412380/the-hottest-en...
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
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.
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 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.
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.
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?
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.
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!”
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.
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.
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.
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.
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.
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.
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.
"Fixing a bug or delivering a feature where you haven't documented the process ... is as good a running a web site nobody visits."
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.
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.
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."
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...
It's a shitty documentation system because it's extremely hard to find that organically, but people do use Jira as documentation.
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.
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.
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.
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/
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.
Yes I'm an assembly line robot and the plant foreman. Jira and delegation helped me pull off both
I would go crazy with the amount of things I would have to remember, their status, how to prioritize, how something was previously done and when, etc.
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.
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".
What's going on is commits and merges.
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.
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.
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
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.)
I would, but that's a detail that a senior dev like yourself should be able to figure out without people just providing it for you.
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.
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 say this as someone who loathes JIRA but still exists in the real world where you need to collaborate to design something.
Anything is better than Jira including post it notes on a wall.
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.
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 time taken to manage tickets in that case would easily have exceeded the time spent on the task itself.
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.
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.
How does JIRA help with that?
I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA.
My $100 bet: They don't.
While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.
> 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).
Funny. Can I get $100 please?
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.
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.
> Sprint planning is about 30 minutes...
That's like saying Santa Klaus is real.
I want to believe you. I really do.
I am sorry if you find it that much hard to believe.
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.
You've gotten me really curious now. Got a link or a blog or something I can read about that?
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.
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.
I wish I was sarcastic when I said I agree. Seeing a working 30 min sprint planning. Instant hit.
My intent is to use Atlassian Approved Agility Methodology™ to push back against noobs.
I've released a lot of software. I'm tired of having these debates with the plebes.
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.
- 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.
"Ticket" => GitHub issue
"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.
"who is working on it" => assignee(s)
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.
It doesn't support custom attributes, workflows, approval hierarchies, statuses etc.
There is a reason ZenHub had to be invented after all.
Workflows: set up one or more project boards and PR merge restrictions
Approval hierarchies: where the above is inadequate, use CODEOWNERS files.
Statuses: use project columns and labels
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.
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.
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.
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.
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.
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.
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.
So much for Agile!
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.
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).
That was so wise I am almost crying. The "local maximas" hurt my engineering soul. It is inferiating in the long term.
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.
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.
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.
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.
JIRA tends to shape management into bad management. That is the grain of the tool.
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).
> 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.”
 https://www.newyorker.com/tech/annals-of-technology/the-rise... (or https://beta.trimread.com/articles/59839)
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.
I spent a little time trying to find an actual study, however non-rigorous, about GTD, and this was the only real contender: https://www.researchgate.net/publication/222552899_Getting_T...
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.
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.
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.
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).
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.
Great team dynamic if one of the members is blocked or has an issue because of something that another person wrote, and they get told to fuck off.
Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.
The best teams I have worked with tend to be more collaborative.
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.
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.
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...."
> "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.
which means more writing to be done. not everbody knows what was SAID an hour ago.
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.
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. 
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.
 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 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.
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?
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.
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.
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.
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.
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.
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.
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
It's maybe not so good at the front end of the process.
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.)
> Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products
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?
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.
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".
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.
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.
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.
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?
What’s the opposite of “delightful”?
deleterious fits in an alliterative way
See also my comment from 2018: https://news.ycombinator.com/item?id=18511497
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?
I joined another team which used Asana, and it's much better, although certain things can still be 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.
This would probably be a bit more resource intensive, but I have network and CPU bandwidth to spare.
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.
Some plugins like big picture even have their own databases that need to be updated separately from the plugin, and can cause performance issues.
Start jira in safe mode and check the performance. Then check your plugins one at a time until you find the culprit.
They also have some nice built in tools that often help you find the source of these problems.
It's a product, but it's also a platform, and sometimes the stuff that is built on the platform causes the platform to buckle.
You don’t know how good you have it with JIRA.
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.
Now everyone uses service now with 50 unnecessary subtickets and multi second delays moving around the web interface.
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.