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.
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.