[HN Gopher] Why Jira Sucks
___________________________________________________________________
Why Jira Sucks
Author : svikashk
Score : 302 points
Date : 2020-12-31 08:46 UTC (14 hours ago)
(HTM) web link (whyjirasucks.com)
(TXT) w3m dump (whyjirasucks.com)
| SideburnsOfDoom wrote:
| 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.
| polote wrote:
| Any better software to replace it ?
| contravariant wrote:
| 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 ;-)
| keithnz wrote:
| 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.
| d23 wrote:
| Napkins and crayons.
| deckard1 wrote:
| 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.
|
| https://en.wikipedia.org/wiki/Comparison_of_issue-
| tracking_s...
| tootie wrote:
| 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.
| gurkendoktor wrote:
| > And developers are expensive as hell.
|
| 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.
| orzig wrote:
| 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.
| josephg wrote:
| 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.
| firepoet wrote:
| That is such bad Agile. No wonder people have such bad
| feelings about it. :-(
| kiksy wrote:
| Nice. This would likely solve a huge chunk of push back
| against JIRA.
| ori_b wrote:
| Yes, I'd also enjoy jira if the company would pay someone
| else to use it for me.
| my_usernam3 wrote:
| Oh man I think I need a new pair of underpants just
| thinking about that!
|
| That being said, my current manager is super awesome
| about minimizing our JIRA involvement so I really
| shouldn't be complaining atm.
| wpietri wrote:
| > 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.
| debaserab2 wrote:
| > 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.
| ypeterholmes wrote:
| Redmine is great.
| jvvlimme wrote:
| No, it's not. From a Product Owner point of view, it's a
| piece of shit. Hard to set priorities, hard to follow
| progress. I'll take jira any day.
| donio wrote:
| 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.
| ogre_codes wrote:
| > 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.
| TimTheTinker wrote:
| GitHub does all of this very well.
|
| "Ticket" => GitHub issue
|
| "status" => current column on GitHub project. This includes
| "is the ticket ready for me", "am I done with a ticket",
| "is the ticket ready for QA", "did QA reject the ticket",
| etc. -- each of these is a column in the project board.
|
| "who is working on it" => assignee(s)
| ogre_codes wrote:
| 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_.
| threeseed wrote:
| It only does it well if you have extremely basic needs.
|
| It doesn't support custom attributes, workflows, approval
| hierarchies, statuses etc.
|
| There is a reason ZenHub had to be invented after all.
| prepend wrote:
| 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.
| pm90 wrote:
| 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.
| [deleted]
| [deleted]
| dblohm7 wrote:
| > 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.
|
| So much for Agile!
| OwlsParlay wrote:
| 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).
| pmoriarty wrote:
| _" 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 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.
| TheFunkyMonk wrote:
| I'm a developer and I can't remember anything so I love JIRA.
| I just grab a ticket and have everything I need to work on
| it.
| SideburnsOfDoom wrote:
| You are an assembly line robot.
| kiaulen wrote:
| 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.
| SideburnsOfDoom wrote:
| > 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".
| turbinerneiter wrote:
| Exactly.
|
| What's going on is commits and merges.
|
| They live in GitLab. There is also tickets in GitLab,
| which all developers are happy to use. There is a wiki as
| well, which, gosh, is just markdown in another repo!
| Markdown you can build beautiful PDFs from! And websites!
|
| But nope, we need JIRA and confluence, because for some
| reason GitLab isn't good enough. Now the tickets are
| separate from the actual work, there is another platform
| with a complex and slow ui, and our docs formerly
| markdown are now in some proprietary confluence RTF,
| which can export to word and PDF - with no custom
| styling.
| [deleted]
| novok wrote:
| 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.
| turbinerneiter wrote:
| 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.
| [deleted]
| pm90 wrote:
| 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?
| TheFunkyMonk wrote:
| Do you prefer to... not have all the details in front of
| you for a task you're about to work on?
| stefanmichael wrote:
| 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
| reificator wrote:
| > _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 would, but that's a detail that a senior dev like
| yourself should be able to figure out without people just
| providing it for you.
| jeff303 wrote:
| How do you prefer to gather the context for something
| that may have been hashed out months or years ago by
| different people?
| SideburnsOfDoom wrote:
| The idea that a task can and should be "hashed out months
| or years ago by different people" is part of the JIRA
| mentality. And it is absurd.
| xxpor wrote:
| ... have you ever worked on a project involving multiple
| teams?
|
| I say this as someone who loathes JIRA but still exists
| in the real world where you need to collaborate to design
| something.
| [deleted]
| Hallucinaut wrote:
| 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.
| aprdm wrote:
| 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.
| grogenaut wrote:
| 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
| blargmaster42_8 wrote:
| Have done the same and it was glorious!
| aprdm wrote:
| Totally. I actually don't know how people that work in
| big enough organizations can possibly not like Jira (or a
| tool like it).
|
| I would go crazy with the amount of things I would have
| to remember, their status, how to prioritize, how
| something was previously done and when, etc.
| xeromal wrote:
| 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.
| guenthert wrote:
| > My identity isn't wrapped up in programming.
|
| 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.
| wpietri wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/Managerialism, and also see
| https://www.amazon.com/dp/B00A76WZ96/
| namdnay wrote:
| 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
| ajkjk wrote:
| 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.
| closeparen wrote:
| 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.
| ajkjk wrote:
| 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.
| ryandrake wrote:
| > 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?
| ajkjk wrote:
| 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.
| namdnay wrote:
| > 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!"
| Joeri wrote:
| 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.
| mdoms wrote:
| > 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.
| marcc wrote:
| 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.
| xxpor wrote:
| 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.
| jeddy3 wrote:
| Wow.
|
| 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.
| Kwpolska wrote:
| 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.
| pm90 wrote:
| 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.
| d23 wrote:
| 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.
| marcc wrote:
| 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.
| stefanmichael wrote:
| The original poster in the thread we're in:
|
| "Fixing a bug or delivering a feature where you haven't
| documented the process ... is as good a running a web
| site nobody visits."
| johannes1234321 wrote:
| 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.
| milesvp wrote:
| 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.
| johannes1234321 wrote:
| 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.
| coredog64 wrote:
| 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.
| pm90 wrote:
| 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.
| asciident wrote:
| 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.
| ajkjk wrote:
| 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.
| maccard wrote:
| 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.
| ajkjk wrote:
| 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.
| antaviana wrote:
| 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/
| aqme28 wrote:
| Elaborating on your point.
|
| 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."
| tootie wrote:
| 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.
| prepend wrote:
| 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.
| pm90 wrote:
| 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)
| magicalhippo wrote:
| > 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...
| curryst wrote:
| 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.
| ryanbrunner wrote:
| 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.
| jakevoytko wrote:
| > 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).
| rightbyte wrote:
| > When the only project language you have is trees, it's
| difficult to talk about forest.
|
| That was so wise I am almost crying. The "local maximas"
| hurt my engineering soul. It is inferiating in the long
| term.
| SideburnsOfDoom wrote:
| > If devs aren't working on priority items
|
| 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.
| EpicEng wrote:
| >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.
| SideburnsOfDoom wrote:
| > 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.
| grendix wrote:
| It's kind of weird how the subtext to every conversation
| in this topic is bad management, yet nobody wants to come
| out and say it.
| SideburnsOfDoom wrote:
| You're not wrong, but also "we shape our tools, and
| thereafter our tools shape us". ( Marshall McLuhan )
|
| JIRA tends to shape management into bad management. That
| is the grain of the tool.
| x0x0 wrote:
| It's a common symptom of devs who undervalue the rest of
| the business. And who think that code magically turns
| into dollars without effort.
| eriktate wrote:
| 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.
| runarberg wrote:
| 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.
| cratermoon wrote:
| 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.
| aplummer wrote:
| 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...
| xxpor wrote:
| The real disease is everyone having this separate QA
| step. QA is part of developing a feature. Do it yourself.
| runarberg wrote:
| 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.
| tomashertus wrote:
| 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.
| avel wrote:
| 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.
| runarberg wrote:
| 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.).
| dpcx wrote:
| 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.
| nemetroid wrote:
| A proper commit message should always have the "why"
| (and, if necessary, the "what").
| runarberg wrote:
| And even if it isn't, how is it a developers job to
| explain why when there is a linked ticket in the commit
| message from product explaining it.
| specialist wrote:
| > _...you haven 't documented the process..._
|
| How does JIRA help with that?
|
| I'd _LOVE_ an unauthorized documentary revealing how
| Atlassian dog foods JIRA.
|
| My $100 bet: They don't.
|
| While Atlassian has great confidence for how _you_ should run
| your projects, what they do internally bears no resemblance
| to that sage advice.
| p2t2p wrote:
| 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.
| ccwilson10 wrote:
| Welp... fun fact, every team (even the non-tech teams) uses
| Jira so I'll happily send over my venmo account :p
| specialist wrote:
| You can split the prize money with u/p2tp2.
|
| 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.
| ccwilson10 wrote:
| 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.
| rightbyte wrote:
| > I legitimacy want to see this.
|
| I wish I was sarcastic when I said I agree. Seeing a
| working 30 min sprint planning. Instant hit.
| ccwilson10 wrote:
| 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.
| specialist wrote:
| Heh. Totally.
|
| My intent is to use Atlassian Approved Agility
| Methodology(tm) to push back against noobs.
|
| I've released a lot of software. I'm tired of having
| these debates with the plebes.
| debaserab2 wrote:
| 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).
| p2t2p wrote:
| > They don't.
|
| Funny. Can I get $100 please?
|
| Every team has their own process that is tailored to their
| needs, process is decided by devs, not managers, managers
| only do "I'd like to have this kind of visibility" requests
| some times and I yet to see those requests introducing any
| kind of burden, usually very miniscule things.
|
| We have very simple process in our team with two issue
| types for devs - task and bug. We have two week long
| sprints and put tasks from backlog into them. Statuses are:
| open, in progress, code review, done. If I forgot to move a
| ticket than a team lead or feature lead will do that for me
| whenever they are at it.
|
| Besides this there are epics but devs don't deal with them,
| feature leads and team leads and PMs do.
|
| This is all running on an instance that is deployed every 4
| hours with changes from master and goes through the same
| upgrade process our customers would go.
|
| There's special set of very high-level tickets but we don't
| deal with those, those are for for people 3 levels above.
|
| Sprint planning is about 30 minutes because backlog
| grooming is done for devs by feature leads and team leads
| and that's pretty much the only obligatory meeting.
| specialist wrote:
| Sure. Post the video(s) and a Venmo account.
|
| > _Sprint planning is about 30 minutes..._
|
| That's like saying Santa Klaus is real.
|
| I want to believe you. I really do.
| p2t2p wrote:
| 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.
| aprdm wrote:
| What they described isn't different of how it worked in
| my previous two companies that used Jira...
| adrr wrote:
| 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.
| ryandrake wrote:
| 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.
| wpietri wrote:
| 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.
|
| [1] https://williampietri.com/writing/2015/the-big-board/
| mnd999 wrote:
| 100% this. JIRA is bad because it encourages managers to use it
| to do stupid things, not because it's inherently bad software.
| [deleted]
| [deleted]
| j45 wrote:
| 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?
| musicale wrote:
| 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.
| ogre_codes wrote:
| > 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.
| Closi wrote:
| 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).
| ogre_codes wrote:
| > 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.
| Closi wrote:
| > If I did, they would likely tell me to fuck off because
| they are busy with some other task.
|
| Great team dynamic if one of the members is blocked or
| has an issue because of something that another person
| wrote, and they get told to fuck off.
| ogre_codes wrote:
| 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.
| Closi wrote:
| Each to their own, I wouldn't want to work at a place
| where we were just working on our own stuff in the same
| room rather than collaborating.
| aard wrote:
| 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.
| eddieh wrote:
| 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.
| Terretta wrote:
| 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. :-)
| Supermancho wrote:
| > 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.
| Closi wrote:
| One size fits all never works in reality.
|
| 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).
| benzible wrote:
| 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."
|
| [1] https://www.newyorker.com/tech/annals-of-technology/the-
| rise... (or https://beta.trimread.com/articles/59839)
| orzig wrote:
| 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 spent a little time trying to find an actual study,
| however non-rigorous, about GTD, and this was the only real
| contender: https://www.researchgate.net/publication/2225528
| 99_Getting_T...
|
| I don't use GTD in any explicit fashion, but to throw my
| n=1 in the ring, the overall concept of personal
| productivity changed my life. Anything can be taken to a
| harmful extreme, and I was (at least) annoying for the
| first few years. But I grew out of it and kept the good
| parts, and I have no doubt that, for me, this sort of thing
| was hugely beneficial.
| Closi wrote:
| 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.
| bird_monster wrote:
| 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?
| Sodman wrote:
| 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.
| specialist wrote:
| Exactly right.
|
| 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.
|
| https://www.infoq.com/podcasts/Michael-Bryzek-testing-in-pro...
| bww wrote:
| 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.
| jiggawatts wrote:
| 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.
| blinktag wrote:
| 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.
| catears wrote:
| 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.
| rasengan0 wrote:
| 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.
| LanceH wrote:
| 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.
| 7thaccount wrote:
| 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.
| kjd1231 wrote:
| What bothers me is if I use JIRA, why do I have a meeting every
| single day telling you what I'm working on. If you care, look
| at JIRA.
| joegahona wrote:
| To discuss blockers and what you'll be working on that day.
| Also many engineers aren't good about updating tickets,
| ruining it for everyone.
| kjd1231 wrote:
| 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.
| jayd16 wrote:
| >it is a LARP of the work
|
| 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.
| msla wrote:
| I agree, but it will never change.
|
| 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.
| tpmx wrote:
| 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.
| [deleted]
| [deleted]
| Philip-J-Fry wrote:
| The one thing that annoys me is that even after all these years
| of JIRA they still haven't fixed their shitty WYSIWYG editor. I
| can't count the number of times I've written something and then
| end up with random asterisks all over the place because it failed
| to figure out what is bold or what's in a list or whatever.
| aldanor wrote:
| Plus you have to learn their stupid formatting rules no one
| else uses, e.g. to insert code.
|
| If it's so targeted at developers, why not use a monospace
| editor in markdown with easy code highlighting instead of the
| abomination they have?
| losthobbies wrote:
| I remember when I was working in a start up we used a simple
| Excel spreadsheet to track bugs. We eventually transitioned to
| Jira and it was good. I now work in a much bigger company and we
| use an Excel spreadsheet to track the Jira bugs. It's very
| annoying.
| maxdo wrote:
| No decent dashboards
| danny_taco wrote:
| I used to agree, but then I tried all the alternatives. And as
| others have mentioned, it's as good as one configures it to fit
| the team needs.
| KaiserPro wrote:
| JIRA is a bit like linux. It only really sings when you have a
| skilled admin to set it up and maintain it.
|
| I have used a whole bunch of ticket/project managing tools in a
| number of different orgs. By far the most useful is JIRA.
|
| taiga.io comes close, but lacks the admin interface and multi
| project overview that jira has.
|
| Trello is ok, but terrible for large teams, or large projects.
| Subtasking is a pain and there is no real concept of a sprint.
| its ok for replacing notes on a board, but terrible for recording
| state.
|
| Some of these criticisms are valid, but compared the
| competition[1], I'd choose JIRA 7 times out of 10.
|
| [1] dont get me started on the "clever" people that decided to
| make their own in house solution, kneecapping the entire planning
| ability of a 70k person org.
| omosubi wrote:
| a single JIRA instance is used for a 70k person org?
| TheFunkyMonk wrote:
| My smaller team settled on Asana and I really like it. It's
| much more approachable than JIRA, and while not as powerful,
| much more so than Trello. Subtasks/relating tasks to other
| projects is great and I can easily see a birds-eye view of my
| upcoming pipeline (referencing tickets on other projects) at
| any time.
| amazonfurr wrote:
| I tried to submit one alternative but can't get hold o them.
| Anyone can help?
| ngrilly wrote:
| Try linear.app and it will clarify why Jira sucks :)
| veidr wrote:
| I hadn't heard of this one, so I checked their website.
|
| I found it interesting that the first bullet point (at least
| when I loaded the site) was: < 100ms
| Built for speed Synchronized in real-time ...
| ...No spinners or waiting.
|
| That indeed is why Jira sucks, in my opinion (and apparently
| many other people, judging by comments in this thread).
| Aeolun wrote:
| It would be nice if any of the alternatives would be in line
| with Jira cost for a large enterprise. I can't recommend this
| to anyone if our cost for issue tracking would quadruple
| overnight. Not to mention the migration costs...
| robinjones wrote:
| Jira costs are going to skyrocket soon too since they are
| sunsetting Jira Server. Opportunity is ripe for competitors.
| andrewl wrote:
| We're getting off our old ticket/wiki project system this coming
| year as it's being sunsetted. Jira is one of the alternatives
| we're investigating, because several staff have used it in other
| jobs. I also used it for a brief time, and I was not in love with
| it. I often felt like it was arguing with me.
|
| There are _so many_ systems out there. Right now we 're also
| evaluating YouTrack from JetBrains and OpenProject.org (which is
| a fork of a fork of RedMine).
|
| We don't want to have to move again any time soon, so while we're
| evaluating features we're also trying to predict stability and
| viability. To that end, when available, I'm including in our
| evaluation notes 1) when the company making the system started;
| 2) when the system was launched; 3) how many staff the company
| has.
|
| JetBrains started in 2000, YouTrack launched in 2009, and they
| have over 900 employees. OpenProject launched in 2012. Both seem
| to be stable and under active development.
|
| ClickUp has a lot of features and _looks_ nice (we haven 't dug
| into it yet). But they launched in 2017, and raised Series A
| funding in June 2020. So they're young. That doesn't mean they're
| _bad_. It just means they 're less known, and have not proved
| long-term viability. On the plus side, it also means they don't
| have the 18 years of cruft in the system that Jira (launched in
| 2002) seems to have.
|
| In my experience the right project management system can really
| help developers, so I always want to hear everybody's
| experiences, good and bad.
| wkoszek wrote:
| JIRA is just fine. Can't really go bad with it. If you have
| limited needs, you can try GitHub or GitLab Issues. But for a
| team which may end up growing, JIRA will work. It has good
| integration with GitHub/GitLab, and with Smart Commits enabled,
| most of workflows can be baked into it. It's slow, but judging
| by this thread, I suspect Atlassian customers are complaining
| about it too, so hopefully it'll be heard.
| justinzollars wrote:
| Have you measured how much javascript comes down the wire? Jira
| takes 30 seconds to load on my mac.
| baxtr wrote:
| I don't like Jira any longer, too. Slow and overloaded. It feels
| ancient. So, what are some good alternatives you use?
| etimberg wrote:
| I'm surprised this doesn't mention things like the poor
| performance, or the fact that some screens expect text in textile
| format whereas others use markdown
| mkl95 wrote:
| I hate Jira because every company I've worked for that uses it is
| a feature factory. But maybe that's just me.
| Aeolun wrote:
| I don't know who the author is, but they clearly have completely
| different issues with Jira than I have.
| JosefAssad wrote:
| I also have a low opinion of jira, but I don't agree with this
| list at all. I refuse to use jira because it is over-engineered
| and is generally used as a crowbar to foist non-technical
| influence upon technical teams, at least in the sites I've seen.
| Jira is in my opinion a fatal source of friction to the
| production of reasonable software.
|
| That's not what I'm getting from this list.
|
| Worse, almost all of the points (all maybe? Haven't checked)
| declare that something is "missing".
|
| Please god no.
|
| Jira isn't missing more features. When you make a list like this,
| some product manager at Atlassian is going to turn it into a
| bunch of scrum epics and jira will be even worse in 12 months.
| cogman10 wrote:
| Yup. Jira seems to be a tool around creating process.
| Management loves that shit because they believe if they put
| enough checkboxes and fields into a ticket eventually things
| will be good (or something). It drives me nuts to no end how
| stupidly complex people want to make the development process.
|
| What should, IMO, have almost no interaction with the ticketing
| system, ends up being a chore for development which adds 0
| value to the final product.
| LeonidBugaev wrote:
| For us Jira became the only option for scaling engineering. Do
| not bother about if you have less then 3-4 teams. But if you
| scale, essentially it is the only solution we found which can fit
| everyone needs, and give deep enough insights about engineering
| metrics. And obviously Jira can be very light or very complex. It
| gives you a lot of building blocks and it is your choice how to
| use it.
| Tomis02 wrote:
| What kind of engineering metrics? Do you have any examples?
| fmakunbound wrote:
| It's so fucking SLOW.
|
| I'm sure it has something to do with Angular or modern JavaScript
| development, somehow.
|
| I'd rather poke my eye out than navigate around in Jira.
| bzb6 wrote:
| They programmed it in Java, so its performance is sad
| bitcharmer wrote:
| The nineties called, they want their java jokes back.
| bzb6 wrote:
| Consider yourself lucky that you have never had to use Jira.
| bitcharmer wrote:
| I've been using Jira for many years in different
| organisations. Just pointing out that Java has nothing to
| do with how bad Jira has become.
| echelon wrote:
| IntelliJ, Clion, and the host of JetBrains IDEs are written
| in Java, and they're the best IDEs on the planet. Better
| than VisualStudio.
|
| Minecraft Java Edition is fantastic.
|
| Java is just a tool. Atlassian isn't a good workshop.
| bzb6 wrote:
| I haven't used any of those IDEs, but really, is
| Minecraft your example? A game with graphics so simple it
| should work on a Pentium 4 but requires a very beefy
| computer instead because it's written in Java.
|
| They rewrote it (not sure if in C++ or C#) for the
| windows store and it works perfectly on computers that
| can barely run the Java version.
| echelon wrote:
| You might not be familiar with how modern computer
| graphics work. Objects and textures are loaded into the
| GPU and managed with an API like OpenGL and shader
| programs written in languages such as GLSL. Java, in this
| case, serves as the engine that ties everything together
| and runs the core game logic.
|
| Microsoft rewrote it because they're not a Java shop.
| Microsoft Games Studio not only uses C#, but their
| mission is to increase adoption throughout the industry
| as it feeds into Microsoft's ecosystem. Microsoft is
| about developer mindshare.
|
| C# and Java are incredibly similar languages. They're
| almost indistinguishable. Pointing to C# as if it's
| substantially different from Java makes me think you've
| never used either.
| bzb6 wrote:
| I know exactly how it works. Java runs the game logic,
| and it does so so slowly that the game skips frames. If
| you're claiming that the game logic and the code that
| runs the graphics are completely untied and run
| independently that's wrong. The graphics code cannot
| paint another frame if it does not know where the objects
| are because the game logic, written in Java, is lagging
| behind.
|
| C# is much faster than Java. Comparing them in real life
| performance situations (and not synthetic benchmarks) is
| almost a joke.
| bitcharmer wrote:
| As opposed to C#, Java (alongside C/C++) is widely used
| in low-latency applications for high-frequency trading
| and HPC. Almost no one uses C# for high performance
| software.
|
| Source: have been doing low-latency engineering for over
| 15 years.
|
| It's quite apparent your experience with Java
| language/runtime is outdated and/or shallow. Maybe try
| reading up on it before making strongly opinionated
| comments like this?
| TheAnswerMan wrote:
| Java minecraft did have issues. Professional game
| streamers were having issues due to the pause-the-world
| garbage collection.
|
| I don't mean to over hype the issue, minecraft became on
| of the most successful games in history riding on Java.
| But the re-write to C++ was not just because Microsoft is
| a C++ shop. The C++ rewrite delivered measurable
| performance gains, making it much better on low end
| devices especially.
| lome_co wrote:
| is it ethical to link this without linking 'why skype is bad' by
| rms?
| TazeTSchnitzel wrote:
| > Missing Easy User Interface to Edit and Update Confluence
|
| There is no "easy" UI for this. The problem to solve is merge
| conflicts, and Atlassian (rightly in my view) clearly decided
| that real-time collaborative editing of the draft beats forcing
| users to do merge conflict resolution when saving changes.
| Wikipedia takes that latter strategy and it's a huge hassle.
| noarchy wrote:
| Is it Jira that sucks or the management methodologies that cause
| it to be such a dumpster fire? Scrum-style management is the norm
| now: it is increasingly difficult to escape it now. So this means
| project managers are chasing burndown metrics and the like, and
| organizing everything on boards that are tweaked to death.
|
| Atlassian is basically the centre of the so-called "Agile"
| industry these days. Jira is just a reflection of it.
| DrBazza wrote:
| Jira is a generic issue tracker for any industry, not a bug
| tracker for software development. That's why in 2020 it doesn't
| work for software any more.
|
| And it's slow. And the UI is awful.
| tmaier wrote:
| What is missing in my opinion? It is consistency between the
| atlassian products and/or adherence of industry "standards"
|
| Confluence and JIRA use a different markup language for posts and
| none of them uses Markdown (in any flavour), which I would also
| use to write in-code documentation, like in a README file
| oftenwrong wrote:
| The larger problem is that you cannot (AFAICT) edit the markup
| directly in Confluence or JIRA. I believe this used to be
| possible, but has been removed in the cloud version, and will
| die with the server version.
|
| The markup you write gets turned into in-editor "objects" (for
| lack of a better term) as you type it out. This makes editing
| an incredibly painful experience. I am occasionally asked to
| document something on Confluence for a client and every time I
| feel like I am fighting a battle just to make a basic document.
|
| For example, I strongly dislike their implementation of ordered
| list editing. They have tried to make the ordered list editing
| mode "smart", but it mostly just gets in the way, and is harder
| than writing it out manually. Additionally, you cannot embed
| other "objects" in an ordered list. If you attempt to insert a
| file object, or something similar, it splits your ordered list
| into two, with the second list starting its ordering at the
| beginning. This would seem to defeat the purpose of having a
| rich editor with embeddable objects, since I cannot use them if
| I am making an ordered list, such as set of "how to" steps.
|
| I usually give up an hour in and switch to writing in my text
| editor instead, but even then Confluence will mangle my input
| in surprising ways when I paste it in. Rule #1 of making an
| editor in my book is that it has to be, at a minimum, as easy
| and useful as a basic text editor. Microsoft Word and
| LibreOffice, in spite of their faults, are quite good at this.
| I would guess most software shops could not implement a WYSIWYG
| editor at that level of polish, and they would be better off
| just providing editable markup.
| ratherbefuddled wrote:
| 1. Unbearably slow. 2 -> n. Whatever.
|
| None of the missing features matter in the slightest in the face
| of the completely unusable performance.
| blargmaster42_8 wrote:
| Use Azure DevOps instead
| noja wrote:
| Can someone - anyone - recommend a better product (non-cloud)?
| yakubin wrote:
| Phabricator.
| IshKebab wrote:
| Phabricator is pretty good except it has pretty much zero CI
| integration. Kind of annoying.
|
| You also have to pay to even comment on issues. I think
| that's a pretty great way of getting companies to pay for
| support but it's also annoying if you want to work with other
| freeloaders on issues.
|
| Also it's written in PHP which means you aren't ever going to
| want to read or modify the code. No different to GitHub, or
| probably even GitLab but I can definitely imagine modifying
| Gogs/Gitea.
| yakubin wrote:
| _> You also have to pay to even comment on issues._
|
| OP mentioned "non-cloud", so I assumed they wanted it self-
| hosted. You don't have to pay anyone for commenting in
| Phabricator when you're self-hosting it.
| mgbmtl wrote:
| Gitlab (self-hosted).
|
| The community/FOSS version mainly lacks the kind of reporting
| that jira has (the paid/Enterprise version has some basic
| reports, such as burndown charts). It's not perfect, but it's
| fast, simple and has an easy API and webhooks.
|
| In the field I work in (CRM/webdev/consulting), JIRA used to be
| everywhere. Now all those shops have moved to Gitlab.
| waylandsmithers wrote:
| What about the burn down charts?
|
| Every project I've ever worked on, features are finished, apps
| and websites are shipped, clients are happy and pay the bills,
| yet the burn down just goes straight to the right and never down.
| Sometimes right and up if people added more tickets during the
| sprint.
|
| We look at it at the end of the sprint and say ah well and
| continue on our way.
|
| Then sometimes a PM type decides it's a problem but nothing ever
| changes it.
| Jolter wrote:
| That's not really not a problem with the software though, is
| it?
|
| Draw your burndown chart on paper and you'll have exactly the
| same problem.
| [deleted]
| dig1 wrote:
| Why do I get the impression that either Zapel or clubhouse
| sponsors this domain? :)
|
| Anyway, from personal experience of working with large,
| distributed teams and (later) leading team that included
| developers, designers (who had no idea what software development
| workflow is), and electrical engineers, I have to say that still
| there is no replacement for Jira. And I'm saying that after
| trying dozens of alternatives.
|
| Now, maybe things got changed in the last five years, but
| something where Jira still shines IMHO: * Self-
| hosted, free for small teams, you get access to *every* release
| they made. All these cloud-hosted solutions sound nice until they
| close the shop. * Almost infinitely configurable.
| Going from Jira to enter-your-favorite-simple-tool feels like
| going from Emacs to the chalkboard. Your CEO likes workflow X,
| sure. Your designer wants workflow Y, no problem. Your plumber
| used to Z, done. Irreplaceable when you work with the teams from
| different fields. * Bazillion plugins, integrations,
| name it. You are still missing something, go and write a plugin
| in any JVM language you like. It probably will work for all Jira
| versions with small modifications. * Management, CEOs,
| even front-end desks like it. Easy to sell, no matter the price.
| I had a harder time selling Zimbra (which is free) to CEO than
| Jira, because every CEO knows about Jira :D
|
| Right, it got slow over time (I believe the main reason is clunky
| UI), but you have to pay the price for all those features. If I'm
| Atlassian, I'd probably add some optional light add-on UI, as
| Jenkins did with Blue Ocean.
| sam_bristow wrote:
| Atlassian is in the process if killing off the self-hosted
| Server versions of their products.
|
| It used to be really annoying that the plugins were split
| between Server and Cloud. You'd find the prefect plugin for
| your task and then find it was only available for Cloud or
| Server.
| camsjams wrote:
| Um did anyone look at the OP's submissions? Clearly they are
| linked with Zepel.io:
| https://news.ycombinator.com/submitted?id=svikashk
|
| I sense a lawsuit from Atlassian poised at Zepel incoming.
| anotherevan wrote:
| RT @HackerNewsOnion: California has ruled it illegal to conceal a
| company's JIRA subscription for the purpose of attracting
| engineers.
|
| https://twitter.com/HackerNewsOnion/status/98160924222131814...
| paulryanrogers wrote:
| Do people really avoid companies based on their choice of
| administrative services?
| chrisseaton wrote:
| Are you asking if people care about the tools they're going
| to have to work with to practice their profession? Yes, of
| course.
|
| I imagine you do as well! If you were looking for a job and
| they were programming in VB 6 and using CVS for version
| control I would imagine you (or almost everyone if not you)
| would say 'hmmm I'm not sure that's how I want to spend my
| day'.
|
| I know I don't want to spend my precious hours on Earth
| trying to remember which markup syntax this particular input
| box uses in Jira today.
| paulryanrogers wrote:
| CVS and VB6 are more central to my role as an IC. So to me
| the issue tracker is not significant. Though I agree the
| inconsistency in JIRA input formats is a bit maddening
| BlargMcLarg wrote:
| Choice of administrative services can definitely be a symptom
| of a larger problem. When most of the services used are
| unfriendly to the user and one is expected to use these every
| day, especially with alternatives available, that doesn't
| tell me they value their workers a lot.
| toast0 wrote:
| Software development and deployment process and the tools
| used to follow (or circumvent, as the case may be) are a
| large portion of the work of a software developer.
|
| It makes a huge difference in my happiness if I'm fighting
| with procedures and tools all day, or fighting with user
| impacting problems all day.
|
| I imagine this is true for people who don't share my process
| and tool preferences, too.
| SkyPuncher wrote:
| In my experience, their PM tools tell a lot about the
| possible complexity/overhead of their process.
|
| Jira and the other behemoths tend to come with a lot of
| process/formality. Tends to be borderline waterfall.
|
| The lighter-weight tools tend to be used by teams that
| actually run an Agile process.
| locusofself wrote:
| I got pulled in as the acting sysadmin of an on-prem atlassian
| suite at my last job after the I.T. dept lost everyone who knew
| how to use linux. The worst part of doing upgrades by far were
| the 3rd party addons everyone had added to Confluence etc, they
| always screwed up the upgrade process.
|
| I didn't really mind using JIRA to track my daily dev work, it
| seemed fine to me. It was annoying that each team had different
| custom fields etc and seemed a bit unwieldy in that respect.
| Lazare wrote:
| 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.)
| waiseristy wrote:
| 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.
| probably_wrong wrote:
| > _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?
| xxpor wrote:
| >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.
| toper-centage wrote:
| I think trello is fine. Its so simple and fast and not
| trying to overachieve. Or did Atlassian already screw it
| up?
| npunt wrote:
| Not really, but they did recently migrate the login to
| Atlassian so what was once a quick one-step process
| becomes a multi-page, multi-redirect mess.
| ccwilson10 wrote:
| 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".
| dan-robertson wrote:
| See also, a comment from someone who worked on JIRA:
| https://news.ycombinator.com/item?id=25212441
| kwertyoowiyop wrote:
| 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...
|
| What's the opposite of "delightful"?
| SoylentYellow wrote:
| excruciating
| _Understated_ wrote:
| > What's the opposite of "delightful"?
|
| Unpleasant?
| 3np wrote:
| Delightless
| muststopmyths wrote:
| >What's the opposite of "delightful"?
|
| deleterious fits in an alliterative way
| Tempest1981 wrote:
| Painful?
| GoldenStake wrote:
| 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.
| systematical wrote:
| 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.
| pigeonbacon wrote:
| 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
|
| https://www.atlassian.com/legal/cloud-terms-of-service
|
| JIRA sucks
| Kwpolska wrote:
| The OP never stated they're using it on Atlassian's cloud,
| and Jira is available for on-premises deployments too, where
| those terms don't apply.
| bombcar wrote:
| This is phenomenally hilariously bad, but quite common (I
| believe Oracle has a "no benchmarks" clause).
| eplanit wrote:
| It's the mainframe app of our time.
| bdavis__ wrote:
| nah. mainframe apps are very snappy with that text only
| interface.
| imbnwa wrote:
| Its a poorly optimized Angular app IIRC
| anonymousCar wrote:
| 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.
| core-questions wrote:
| 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?
| frombody wrote:
| Jira is typically not slow. It's usually the plugins you have
| installed.
|
| Some plugins like big picture even have their own databases
| that need to be updated separately from the plugin, and can
| cause performance issues.
|
| Start jira in safe mode and check the performance. Then check
| your plugins one at a time until you find the culprit.
|
| They also have some nice built in tools that often help you
| find the source of these problems.
|
| It's a product, but it's also a platform, and sometimes the
| stuff that is built on the platform causes the platform to
| buckle.
| antaviana wrote:
| > Atlassian seems to make a lot of money
|
| 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.
| Karunamon wrote:
| 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.
| [deleted]
| bserfaty wrote:
| It always seems to me that Jira was used to produce Jira itself
| and that's why it turned out this way.
| rgoulter wrote:
| Allegedly, they use post-it notes.
| https://twitter.com/isislovecruft/status/1292331568330022913
| CivBase wrote:
| Missing... missing... missing...
|
| I disagree. What makes JIRA a pain is that it has too much. It
| tries to be a solution for every possible workflow and ends up
| being a slow, clunky, and confusing solution for all of them.
|
| I personally think the best thing Atlassian could do is spin of
| JIRA into multiple apps which all use the same core, but have
| different interfaces designed for different workflows. Of course,
| that's much easier said than done with such a ubiquitous monolith
| as JIRA.
| ozim wrote:
| JIRA does not suck, it is people who are using it. The same with
| programming languages and frameworks.
|
| We all suck just accept it and try to improve yourself and others
| point by point in that new 2021!
| LeonidBugaev wrote:
| It looks like one of may marketing websites, in this case build
| by clubhouse or zeppel. And I'll be frank, clubhouse does not
| work at all for complex software projects. Maybe it can fit some
| web consultancies flows or similar, but it is build for VERY
| specific niche.
| arnonejoe wrote:
| Jira is not all that bad. With Jira It's easier to write stories
| outside of the tool and copy/paste in. If you have a side hustle
| or small team Jetbrains YouTrack is free to 10 users (I think)
| and it's awesome.
|
| https://www.jetbrains.com/youtrack/?gclid=EAIaIQobChMIx5iu7O...
| hakfoo wrote:
| What I don't like about Jira is that eventually everything ends
| up in a poorly structured pool of "Work complete" tasks.
|
| I regularly come across situations of the form "we finished Task
| XYZ a few months ago, but I want to come back to it." Maybe the
| ticket has an attachment we need for long-term documentation
| purposes or a test detail we need the next time we review the
| code.
|
| Jira search rarely finds anything useful-- the S/N ratio is
| terrible with non-development tasks mentioning XYZ, yet ignoring
| actual XYZ tasks due to poor naming and heirarchy. I usually
| instead look at the code itself, see in the git history "This was
| modified in ticket 345675" and then use that to index Jira back
| to the info I want. From there maybe I can walk between linked
| blockers and sub-tasks to get what I want.
|
| My pre-Jira experience was on Basecamp v1/v2. I appreciated the
| forum-style layout, because it tends to allow for a few key
| things: * "Search" and "browse" are both well supported use cases
| * Old content remains usable and structured, rather than dropping
| off a cliff after the last ticket closed. * Content can be
| grouped as it makes sense-- say you get a customer feedback item
| that touches on three eventual tasks. It would have to be
| (possibly sliced up and) attached to all three tickets in a Jira
| model. * It felt "discussion-first"-- the discussion of what to
| do and how we want to do it is central. This tends to archive
| some of the subtle choices and gotchas that won't appear
| automatically in a ticket.
|
| I always dreamed of a system that basically added lightweight
| ticket/kanban model on top of Basecamp. I can see the value of
| tickets as a trackable unit of work, but it feels like this would
| be little more than a few tiny tags decorating a readable
| discussion flow.
| fullstackwife wrote:
| We are trying to unsuck Jira for users with an alternative UI,
| allowing them to manage Jira issues on a virtual whiteboard. [1].
|
| [1] https://spartez-software.com/products/whiteboards-for-jira
| oftenwrong wrote:
| I would like to try a more visual and spatial approach to
| project planning software. Most of the major solutions, like
| JIRA, are more like interacting with a RDBDMS through a UI.
| (Although I admit JQL is very useful, so I don't want to throw
| that away entirely.)
|
| Here's another product I found recently that allows users to
| draw out their project plan, and have it turned into
| management-friendly reports automatically:
|
| https://www.gameplan.global/
|
| No comment on whether or not this is actually good, since I
| have never tried it, but it presents a refreshing concept.
| bitcharmer wrote:
| Spartez rings a bell. Aren't you the very people who create
| software for Atlassian?
| konic wrote:
| Yes, but no. You can check some details here https://spartez-
| software.com/blog/2020/10/27/two-spartez-com...
| vxNsr wrote:
| This looks like it's mostly yes.
| silvestrov wrote:
| 1. It is dog slow.
|
| 2. It is dog slow.
|
| 3. It is dog slow.
|
| ...
|
| When my team had an important as-quickly-as-possible sprint, we
| dropped Jira and switched to Google Docs as it was much easier
| and faster than Jira.
|
| My conclusion was that Jira doesn't do much for developers that
| can't be done in some Google Docs/Sheets.
| papaf wrote:
| _It is dog slow._
|
| We had a product manager who used to write tickets in OneNote
| and then copy and paste into JIRA when things were quieter in
| the evening.
| enra wrote:
| Working on a much faster issue tracker: https://linear.app
|
| We build it so that almost everything you do in the app instant
| (<100ms)
| buttscicles wrote:
| Linear is the real deal. Love the keyboard shortcuts & speed.
| veidr wrote:
| Yeah, that's right. Before we escaped JIRA, my team would often
| do that, too, even for regular sprints. Make a checklist in a
| collaborative editor tool like Google Docs or Notion, and just
| do the day to day work there.
|
| Then somebody would have to copy it to JIRA so the work would
| get tracked.
|
| But very little of the planning, work breakdown, day to day
| updates, or discussion actually happened on JIRA because it was
| literally like a hundred times slower (with the convoluted UI
| compounded by incessant "wait... is it even loading?... oh, OK,
| it finally loaded" at each step of the way).
| dplgk wrote:
| I manage a team of devs but my clients love to use Jira. So I
| typically use something like Board Genius to sync between
| Github issues and Jira. This also let's me keep my devs out of
| Jira so they can just focus on actual work and not worry all
| the discussions that happen in Jira between my clients and
| project management.
| kazinator wrote:
| Sorry, no; a bug tracking system can be missing all those things
| and still not exhibit that intangible Jira suckage.
|
| Simply adding more things to Jira that are supposedly missing
| won't fix it.
| postexitus wrote:
| does anybody use monday.com ? it looks very capable at high level
| (and addresses some of those observability issues stated in the
| site)
| wkoszek wrote:
| If you want a normal software engineering process, where you
| want to check in with your colleagues after 1-2 weeks on the
| progress etc. it's not going to happen. The normal concepts of
| sw. eng. aren't in Monday. It's more like a clunky to-do for
| non-techy people. Simple things are extremely hard in Monday.
| For example seeing all the tasks from all projects assigned to
| you -> hard. I'd rather stick with GitHub/JIRA
| mtberatwork wrote:
| My workplace uses Monday.com and some folks like it but I
| personally find it clunky and underwhelming. In my opinion, it
| tries to do too many things and doesn't do any one thing
| particularly well. If you are just wanting a kanban board, you
| are better off sticking with Trello. If you are wanting bug
| tracking, feature requests, etc, you are better off with things
| like GitHub Issues and other specialized tools. YMMV of course.
| Marazan wrote:
| Missing the ability to assign more than one person to a card.
| Hovertruck wrote:
| For some quick catharsis, have a look at
| https://jiralover.tumblr.com/
| waylandsmithers wrote:
| Does anyone here get to use Basecamp? It looks awesome and I've
| read up on their Shape Up process but have yet to find any
| organizational support for it in my professional experiences.
| ci5er wrote:
| The ui is a little non-intuitive, but good for small teams. For
| repetitive process work or small distributed teams, I also like
| Azendoo or even Asana (which has the reports that managers
| crave)
| denysvitali wrote:
| Every bullet point says "Missing...", but I feel like the main
| issue about Jira is that it has waaay to many features, and that
| it's super slow!
|
| The only bullet point I do agree with, is that Jira is missing an
| easy (or IMHO a minimalist / simple) interface. The tool is a
| mess, and the people using it are probably also using it in the
| wrong way, making the whole situation way worse.
|
| Don't get me wrong, I like Jira to some extent, but its
| performance and messy UI are really making my life harder rather
| than simpler.
| m0llusk wrote:
| Sniff around a bit and you will find that what is even worse is
| why it is slow. Even the most simple operations call out to
| multiple sites. Quitting Jira requires more than three dozen
| sites to respond in order to actually work. Jira is an example
| of just how much the modern APIs are fun yay methodology sucks
| in actual practice.
| my_usernam3 wrote:
| I was feeling the same way. Maybe we can get a Steve Jobs of
| agile development and create the "Iphone of Software
| Development Management Software". What I (drunkenly) mean is
| that the customer might not always know best when it comes to
| UX, especially when your early adopters/feedback providers are
| human management nerds.
| ghayes wrote:
| Have you tried Linear[0]? It's a well-designed, streamlined
| tool similar to JIRA.
|
| [0]: https://linear.app/
| that_guy_iain wrote:
| For most it seems "missing easy user interface" meaning there
| is an interface. And what they're wanting to do is part of a
| complex system therefore it's easy to understand why an easy
| interface isn't there, it's not a simple thing in the first
| place.
| throwaway4good wrote:
| If you want something that is simple use kanban-board like
| trello, github, an excel spreadsheet or whatever.
|
| The complexity comes from the demand of Jira's paying
| professional customers.
|
| Eventually Jira will grow too complex and bane the way for
| simpler tools probably of a different paradigm. Much like how
| Jira replaced things like HP Quality Center or the tools of
| Rational Unified Process.
| toolslive wrote:
| why oh why does it have to be this sloooow ?
| veidr wrote:
| I think you are right: the SLOWNESS is a killer. In fact, I
| think it is THE show-stopper flaw.
|
| I recently succeeded in an 18-month-long effort to coordinate
| moving off of JIRA at work. We moved to clubhouse.io and it's
| been great. We were also looking closely at GitHub Issues +
| something like ZenHub for the missing project-management
| features -- and that would have been great, too.
|
| As soon as we moved off of JIRA, the amount of communication
| that started happening in the most relevant place -- the bug
| tracker thread -- increased by like... I don't know, something
| like 20x or 50x.
|
| In our years on JIRA (the hosted plan) virtually nobody every
| discussed the details of the bugs on JIRA. We filed tickets
| there, and checked them off when done, and used it to review
| what had gotten done after each iteration -- but nobody used it
| day-to-day. If discussion was to happen about a bug, it
| happened on Slack (which is horrible for ever finding it again,
| but it is fast).
|
| The reason, I believe, is simply that JIRA is waaaayyy tooooo
| slow. Nobody wanted to use it day-to-day. You made a list of
| stories at the beginning of the iteration, and you checked it
| again at at the end of the iteration, to mark the ones you did
| done. I did this too.
|
| Now, all the discussions directly about the bugs/features in
| the tracker happen directly on the tracker. Which, I recalled,
| was how it used to be several years ago before we moved to JIRA
| (from GitHub issues).
|
| There is a lot of other stuff that is clunky about JIRA but I
| think we could have probably dealt with it, if it wasn't so
| slow that every interaction -- even simple things like "find
| and open the bug I was working on most recently" or "see what
| is assigned to me this iteration" -- felt like rm -rf
| node_modules && npm install and you somehow find yourself
| checking twitter before it even opens...
|
| Speed matters!
| tvanantwerp wrote:
| I once had a user show me his CPU spike by 50% by merely
| scrolling up and down a JIRA page. It was stunning.
| that_guy_iain wrote:
| > I think you are right: the SLOWNESS is a killer. In fact, I
| think it is THE show-stopper flaw.
|
| I think there are multiple clones of JIRA that literally just
| focus on the performance part. I think at this point it's
| unrealistic to expect major performance improvements in a
| timely fashion with JIRA.
| [deleted]
| kevsim wrote:
| If you want to try something in this space that's really snappy
| and responsive, checkout out Kitemaker (YC W21) [0]. I'm a
| founder and happy to chat with anyone that has any
| feedback/feature requests: hi@kitemaker.co
|
| 0: https://kitemaker.co
| dotancohen wrote:
| I was looking at the homepage reading text that explained the
| Picture Gallery ("when users can reuse images... more likely
| to...") and then the whole page refreshed with a completely
| different design. I was on the page for probably about 30 to
| 60 seconds.
|
| Firefox 84 on Kubuntu Linux, no relevant addons.
| kevsim wrote:
| Hi! That's just a video playing on a loop taking you
| through the various screens. The "image gallery" is just
| showing our work item screen and then it jumps to some
| other screens. Thanks for the feedback though! It may be
| that this isn't clear enough
| dotancohen wrote:
| I see, thanks. I scroll with the keyboard, not the mouse,
| so I did not notice that the next screenful was entirely
| a video.
| wyck wrote:
| Some constructive advice, your homepage is messy, the
| ratios and spacing are really off and makes it hard to
| digest and focus on your features. This will directly
| impact your actual product. Please don't be insulted ,
| I've spend 20 years in design/branding and want you to
| succeed but this homepage isn't doing it, you need a
| brand book with some strict guidelines.
| kevsim wrote:
| Not insulted at all! Very useful feedback.
| catdog wrote:
| > Every bullet point says "Missing...", but I feel like the
| main issue about Jira is that it has waaay to many
|
| It says "missing" but it mostly talks about those existing
| features lacking any polish.
|
| > and that it's super slow!
|
| It is and it really sucks or to quote Firefox "A web page is
| slowing down your browser, what do you want to do, wait or stop
| it".
| denysvitali wrote:
| It's funny because I have never seen the mentioned Firefox
| error on any Jira instance. The problem is mostly server-
| side: it's slow as hell! I'm personally using go-jira [0],
| but even that is slow: the problem as I said is not (only)
| the frontend, but the backend.
|
| [0]: https://github.com/go-jira/jira
| Can_Not wrote:
| Definitely. JIRA often feels like it's running an eletron app
| inside of my browser and inside of the server.
| imbnwa wrote:
| A former PM prioritized issues in the backlog by making a
| ticket and giving it a name like "Groom these next" or
| "Prioritized for January release", placing it in the backlog,
| then placing the tickets to be prioritized above it
|
| They also hid bugs from being counted in reports by marking
| them as stories but that's another conversation
| throwaway4good wrote:
| So much project management is about gaming internal politics
| and managing information flow between lower and higher parts
| of the hierarchy.
|
| These tools market themselves as creating transparency but
| they are in practice often used to hide or excuse things.
|
| I suppose that is why they all take the tragic path from
| being heralded as new and fresh in the beginning to
| absolutely being hated in the end.
|
| Goes for methodologies as well (I remember the agile
| manifesto ... look at where we are now).
| loopz wrote:
| The interface used to be simpler and less in the way of getting
| things done. Then they added personas, UX and tried to "help"
| the user. You now need more clicks to accomplish the same stuff
| while information is more hidden than before also.
|
| There's no way to cater every possible workflow without feature
| bloat. However, the space is ripe for simpler, more accessible
| solutions that supports work across multiple projects.
| echelon wrote:
| It's not for engineers. Or anyone in particular. They're
| building to check off boxes in order to sell top down to
| C-level execs that never touch the stuff.
|
| Atlassian products are all like this, and each one is a
| horrible trash fire.
|
| Confluence is the worst wiki product I've ever used. Gross
| syntax, slow, clunky plugin system, awkward permissions.
| Install MediaWiki and be done with it.
|
| Bitbucket is slow and feels like it's from the 90s. It
| doesn't seem to do multithreading well - sometimes force
| pushed branch rebases pick up a new, unrelated author. A bug
| that hasn't been fixed in years, and only one of many. How
| many times will merging not actually work?
|
| Jira is a special kind of hell. It's like every team needs
| their own embedded Atlassian solutions engineer to get it
| into a usable state. Not an EM or PM, but a specially
| dedicated role just to deal with Jira nonsense. Why even
| bother?
|
| Atlassian is like Salesforce for business process, but if it
| were written by all-remote temp contractors churning through
| Jira tickets themselves.
| pm90 wrote:
| Agree with this. My hypothesis is that they're just
| ridiculously slow at adopting newer UX principles. The
| product was successful initially (good for them) and it was
| just never made much better.
|
| The horrible response times and user hostile UI is
| shocking, especially if you look at their competitors. It
| gets in your way all the fucking time. But because they're
| embedded in enterprises they don't need to change much.
| It's a big mess.
| mongol wrote:
| If anything, Jira tries to do too much. It is like Excel, tries
| to fit every need in its domain. That it still has limits does
| not mean it sucks. Quite tiring when people reach for that word
| for nitpicks and personal opinions.
| offtop5 wrote:
| Jira is just fine.
|
| But if you find a company where they want to create their own
| ticket tracker in house, run. It means they're pennywise pound
| foolish
| gauthamshankar wrote:
| Co-founder of Zepel.io [0] here. Thank you for giving Zepel a
| shoutout in the Jira alternatives section of the landing page.
| Would love to get feedback from the community regarding our App.
|
| [0]:https://zepel.io/
| iblaine wrote:
| Did someone at Zepel.io create this Why Jira Sucks site?
| softinio wrote:
| I was hoping to find a list of alternatives that are serious
| contenders as part of this thread.
|
| What alternatives are people using?
| iplaman wrote:
| their tweeter account suspended :(
| ccwilson10 wrote:
| [Current Atlassian employee here] This might be biting off more
| than I can chew, but if anyone has tangible ways they think Jira
| can be improved for non-tech team members I'd love to hear them.
| Happy to chat via email or Zoom about them and try to add some of
| the fixes into the upcoming roadmap.
| nlh wrote:
| Based on everything I've sorta-kinda-summarized here, the #1
| thing you guys could do is speed up Jira Cloud.
|
| My company uses it and tolerates it, but at this point it now
| takes 8-10s to load a single issue from the board view, and ~5s
| to toggle the edit state. There is basically not a single
| action I can perform that takes less than 5s to execute, and
| some take more (backlog, etc. view take upwards of 30s to load
| a few hundred issues).
|
| This is just not OK. And we're using hosted, Next-Gen. No fancy
| customizations.
|
| Every. Single. Click. takes 5s+ to register a reaction. I'm on
| a gigabit internet connection and have a 16" MacBook Pro with
| all the dials turned up (eg it is NOT me).
| ccwilson10 wrote:
| Whew. At 8 seconds I'd probably call for the tool to be
| removed. I had a similar experience while at Atlassian at one
| point and then we found a way to speed up the (Jira Core)
| boards by ~5 seconds after changing some JQL for the board
| logic. That change should be in effect for your org but you'd
| need to use Classic Business projects.
|
| Fun fact, next-gen might actually be a reason why your
| instance is running slower. A side-effect of NG can be the
| slowdown from each project with its own custom fields and
| that effect multiplied hundreds of NG projects across an
| organization. Then (I think), when loading your project it
| calls all the fields to see which fields it should show. Not
| an ideal rec, but I'd check out Classic projects and see if
| that speeds things up for you and your org.
|
| Speeding up Jira Cloud is a top priority for Atlassian this
| year so you should see some improvements coming. I'm working
| on a new view right now in Jira and we've been able to load
| about 100 issues in ~1-2 seconds. It lazy loads, but we can
| flip through 500 easily once you've scrolled to the bottom.
| Should be able to get that in your hands this coming year.
| jabo wrote:
| I appreciate you jumping into a thread like this and it's
| great to hear that effort is being invested to speed up
| Jira Cloud.
|
| However:
|
| > we've been able to load about 100 issues in ~1-2 seconds.
|
| I'm sure there are a ton of things that go into speeding
| things up and I don't mean to diminish the amount of work
| involved, but might I suggest raising the performance bar
| even higher?
|
| Is there a world where loading 100 issues takes 300ms for
| example? Anything over that typically tends to give users
| the impression of things being slow.
| ccwilson10 wrote:
| Haha fair enough. The issue will be, and currently mostly
| is, the effect you see on performance at scale. Small
| instances don't have _instantaneous_ interactions but
| they 're still much faster. Here's a quick video
| (https://imgur.com/a/8ZJrhMZ) of a dev instance (slower
| than prod) with the new feature. Loading of this view
| feels way faster than the board does.
|
| The work I'm doing is separate from the performance
| improvements, so hopefully the two initiatives combined
| will get us a lot closer to what you're asking for!
| Again, we'll have to see what it looks like in production
| at scale, but I'm optimistic it'll be a much better
| experience.
| kabes wrote:
| Jira sucks because middle management wants to be able to look at
| stats about stuff like estimated vs achieved points to get a fake
| feeling of control and hide the fact they are useless powerpoint
| generators.
| cowmix wrote:
| I'm old enuff to remember when Jira was brought in through the
| back door and was forced on management.
| donkeyballs wrote:
| Those were the days.
| SkyPuncher wrote:
| Am I the only one who has never had an issue with Jira? Sure,
| there are some things that could be better. But, overall, I find
| I'm content with Jira.
|
| My belief from seeing many organizations struggle with Jira is
| they have process issues that need to be addressed outside of
| Jira. Jira is simply the place where their process becomes
| visualized and put into place - so it gets blamed for the
| breakdowns.
|
| Reading through this list, I can picture exactly why this user is
| having these complaints. Some of these a definitely UX
| frustrations, but many of these seem to be fundamental process
| issues or contradictions. For example, the website claims
| "missing easy setup" - while also listing a bunch of things that
| demonstrate the complexity of their Jira setup.
|
| -----
|
| tldr: If you're having the issues the author lists, you should
| probably check your process. Jira is doing you the favor of
| highlighting where it's broken.
| tomphoolery wrote:
| Is there a better product out there that can communicate what the
| development team is doing to non-technical people?
|
| I like Jira when I don't have to use it. For example, setting up
| GitHub automation so that changes from Git will cause tickets in
| Jira to transition to the next stage. Or, automating a transition
| from "Pending Estimate" when a Jira user assigns story points to
| a ticket. The automation features in Jira are far beyond anything
| I've ever used before (one might even consider it an "IFTTT for
| project management"), and on most teams I've been on, very much
| under-utilized. I can even automate starting the process of
| development when design is finished, as when the design ticket is
| marked "Done", the development ticket it's linked to will change
| to "Pending Estimate", as it's now possible for a developer to
| estimate how long it will take to implement the given design.
| k__ wrote:
| I think, tools like Jira would be evaluated 10x more favourably
| if they just weren't so damn slow.
|
| Same goes for Asana and Slack.
| Aeolun wrote:
| Asana and Slack were both fast once upon a time.
| sgt wrote:
| Completely misses the point. The reasons why JIRA sucks are:
|
| 1. It is slow
| nn3 wrote:
| 2. It has too many buttons
| nicwolff wrote:
| Jira has two different WYSIWYG fields for issue descriptions. The
| one in the edit-issue form understands Markdown, but the one in
| the create-issue form doesn't. It's been this way for at least a
| couple of years.
|
| Jira could become perfect in every other way, and would still
| suck if they don't fix this.
| tristor wrote:
| I am reading this comment thread and honestly I don't know that I
| agree. I think JIRA, like most tools, is as good or bad as you
| make it. I've been at numerous companies using JIRA that don't
| seem to have most of the issues referenced here. The only thing
| I've ever felt like JIRA really lacked in was in a good UX for
| embedding code snippets or other technical details into issue
| comments. Native support for Markdown in comments would be a good
| win.
|
| I actually like JIRA and Confluence and have generally had good
| experiences using them in multiple companies. One of the main
| things I like is the integration between the two, and
| Confluence's concept of spaces so you can have some things
| publicly facing and other things private, which allows you to use
| Confluence documentation as user-facing docs, which references
| JIRA issues directly for known issues, and can write
| requirements/specs/PRDs in Confluence and reference them easily
| within a JIRA issue.
|
| The only real problem JIRA/Confluence have is being very very
| slow. They've gotten marginally better over the years, but
| they're still terribly slow compared to competing offerings.
| papaf wrote:
| _Native support for Markdown in comments would be a good win._
|
| In the Atlassian ecosystem, the markup languages are
| constrained by the following equation: JIRA
| Markup != Confluence Markup != Bitbucket Markup
| smcl wrote:
| Also even just within JIRA it can be inconsistent - I
| realised that to make monospaced text you need to use:
|
| - backticks when _creating_ a Jira ticket, e.g. `hello`
|
| - double curly-braces when _editing_ a Jira ticket, e.g.
| {{hello}}
|
| ... or vice versa. I cannot honestly remember which way round
| it is. Of the complaints I have about Jira this is probably
| the least annoying - but it really shows how irritating the
| product is.
| Phelinofist wrote:
| Cannot confirm, I always create issues with {{...}}
| smcl wrote:
| "or vice versa. I cannot honestly remember which way
| round it is"
| nicwolff wrote:
| It's vice versa, and this may be a small thing but it's my
| top example of how little they care about usability or
| product quality!
| smcl wrote:
| One hundred percent - it's such a little thing, but as a
| developer it says a lot about the code beneath the
| product
| julenx wrote:
| I haven't used JIRA recently, but as far as I remember the
| difference existed because they were rolling out a "new"
| editor, which was active when editing tickets, but wasn't
| available when creating new ones.
|
| I remember this caused me some data corruption when editing
| a comment created with the old version of the editor using
| the new editor. It was a mess.
| smcl wrote:
| This honestly would not surprise me. I'm kinda glad
| there's _an_ explanation, but I'm also annoyed it's a
| stupid one
| dangoor wrote:
| Jira Cloud has a new editor that is Markdownesque. Type as if
| you're using Markdown, and it will do the formatting you'd
| expect.
| Smaug123 wrote:
| From your description, it sounds like this would have Slack's
| problem (which resulted in one of the most upvoted HN threads
| of all time, https://news.ycombinator.com/item?id=21589647).
| I've tried Googling around a bit to find an example of Jira
| Cloud's Markdown environment, but couldn't find one. (I am
| certainly biased, though, by my strong loathing of Jira.)
| Aeolun wrote:
| The new bitbucket markdown editor works fine actually, so
| I'd hope they used that.
| dangoor wrote:
| FWIW, I prefer Jira's editor to Slack's.
| turbinerneiter wrote:
| Yeah, and in the end, you can export it as a word or PDF
| document.
|
| Holy hell, what a tragedy. I used to write markdown and have
| pandoc typeset a pdf in the company design. Now I have word.
| vxNsr wrote:
| > _competing offerings._
|
| Any suggestions for that similar synergy? Doc/Issue
| Tracker/Code base integration?
| jgalentine007 wrote:
| I use pivotal tracker. Not all the features of Atlassian, but
| I've completed several projects with it, and it doesn't get
| in the way.
| zaxfoster wrote:
| I've used both jira and tracker across a few different
| spots and can confirm that Tracker is refreshingly
| lightweight.
|
| To me, tracker is an easier user experience for focusing on
| a stream of stories. And a more streamlined experience for
| work assignment means more time writing code to solve
| problems.
| BlargMcLarg wrote:
| There are three problems I notice with JIRA, of which two are
| entirely the product's fault. The first one you already
| mentioned: abysmal speed. The second is how JIRA forces certain
| ways of working which are clunky or intuitive (or by extension,
| out-of-the-box workflows are difficult to change).
|
| The biggest problem I have, by far, is just how easy it is to
| create bureaucracy-intense workflows in JIRA and make
| management believe these are absolutely necessary. Most
| developers do not need this info, and do not have the power to
| easily change things. All the fields when making a simple
| ticket, the dozens of sub-tasks, the ticket inside a ticket
| inside a ticket. I would believe this is not impossible to
| avoid, but I do feel a simpler structure using labels,
| milestones and issue tracker is far, far easier and less prone
| to being misused. GitLab and Github can both do this as far as
| I know.
|
| And sure, JIRA integrates nicely with other products
| (Bitbucket, Bamboo, Confluence). Other products have these
| integrations on a more modular level and still load faster and
| have small QoL differences over JIRA. Maybe big corps need a
| bit more, but JIRA seems to be too focused on managers and
| suffers from feature creep to the detriment of user experience.
| stiray wrote:
| > is just how easy it is to create bureaucracy-intense
| workflows in JIRA and make management believe these are
| absolutely necessary
|
| Omg, finally someone has said it, I thought I was weird. This
| is the imperative problem with JIRA, it is not made to help
| the developers but to satisfy management which is buying the
| software. +1 for this comment. I have seen its usage in 7
| companies and in each and every case instead of simplifying
| developers workflow it was complicating it due to management
| wanting to have their data which, at the end, didnt bring
| anything for the product but were just enabler to make their
| cute graphs that enabled them to not be involved into
| development cycle (as they should be) but rather bring out
| statistics "out of their shoe - JIRA".
|
| And this is also my only (ok, except the slowness which
| should be understandable for any web browser js application)
| comment over the JIRA, I dont care what the tool is, how much
| time it takes (at the end, I am not paying for it), but how
| much it diverges from the tool that SHOULD help the
| development while in its essence it mostly helps the
| management to track their data.
| BlargMcLarg wrote:
| Pretty much. We can divert a little to support customers
| reporting issues, though I don't feel JIRA is much
| friendlier here compared to GitLab once you get the hang of
| both. The only one I see benefiting from this monstrosity
| is management and upper layers, and they indirectly pay for
| this through lower morale and retention rates. If you
| really need the graphs that badly, you might as well spend
| a few hundred man hours to write a script that imports
| data, run some data science logic and draw them. And maybe
| put all that info.
| baud147258 wrote:
| > All the fields when making a simple ticket, the dozens of
| sub-tasks, the ticket inside a ticket inside a ticket
|
| that's mostly down to the current JIRA configuration, same
| with the workflows used. One thing that I found great at my
| current office was letting the team configure their Jira
| projects as they wanted
| BlargMcLarg wrote:
| That comes back to the earlier point I made: developers
| often not having the power to change this. Others (and
| myself) already mentioned this is not a problem of JIRA
| itself, but rather JIRA being predominantly sold to
| management types that do not relinquish control and
| overconfigure the system.
|
| I would _love_ to see the insides of what we have
| configured, and toss the junk out. It ain 't happening in
| the next 20 years, and I sure as heck don't plan to stay
| that long at a company putting little value in the
| experience of its employees.
| tlapinsk wrote:
| I have to very much agree with this comment. I thoroughly enjoy
| using JIRA and Confluence. The two go hand in hand very well.
|
| As many others have mentioned thought, it is abysmally slow. At
| least their Cloud offering is, which is the core product we use
| at my job. I've used older on-prem deployments though and they
| were lightning fast. Seems that they're deprecating this
| solution by 2024 though.
|
| I recently completed a JIRA survey, and slowness was my number
| one complaint. Hopefully the Product teams read through those
| surveys or peruse HN. Everything else about JIRA works great
| for our Software Development needs.
| giancarlostoro wrote:
| Jira is basically the Excel of task management. As my coworker
| says if Excel I also attribute to Jira: it is the most abused
| tool.
| lacoolj wrote:
| this list has some good items on it but it's very poorly
| organized. don't mention 3 different things as _one_ item
| (looking at you number 11)
| madrox wrote:
| When I got my first job reporting to a non-technical executive
| and had authority to pick the PM tool, I thought this was my
| chance to find the Tool That Didn't Suck. Going down that rabbit
| hole led me to the sad truth that it'll be impossible to make a
| project management tool that the engineer likes until the
| engineer stops perceiving project management data entry as busy
| work. Finding a new tool ameliorates this until the novelty of
| working in a new UI has worn off.
|
| Engineers are an autonomous bunch, and the best coders among us
| despise doing anything that isn't actually writing code.
| Unfortunately, like doc writing, there is more to being a good
| engineer than writing code.
| ctrager wrote:
| When I read the list of reasons "Why Jira Sucks" what came to
| mine was the Charlie Kaufman movie "Synecdoche, New York". In
| that movie, a playwright keeps expanding the scope of a play to
| more and more encompass the scope of reality itself. Likewise,
| some of the points (1, 2, 3, 5...) in the writer of "Why Jira
| Sucks" wants Jira to be bigger, to encompass the variety of ways
| work can flow.
| gregmac wrote:
| > Missing Easy Search Option for Finding Issues in the Project
|
| Really? I think search is one of the most compelling features.
|
| I find most of the time when I can't find something, it's because
| of different terms used, such as searching for "schedule task
| failing" vs the ticket saying "job run error". (Usually once I
| eventually find it I just edit the ticket to have the other
| keywords I tried)
|
| The UI for selecting advanced search is acceptable.. it's not the
| easiest thing - for example searching open vs closed on GitHub is
| an much simpler - but it also exposes a lot more of the fields.
|
| Personally I use the text-based JQL interface most of the time.
| It's very powerful, and as the name implies, anyone that knows
| SQL will find it familiar. A quick example, an easy way to find
| bugs closed in the version you're releasing but that weren't
| correctly tagged: `(type = bug) and (fixversion is null) and
| (status changed to closed after 2020-12-02)`.
|
| And search you do is updated in the url (easy to share with
| others), and even better, if you paste that url into Confluence,
| it turns into an embedded dynamic list. This is great for release
| notes, or making category pages of certain types of tickets (eg:
| all open bugs related to feature x, or all bugs older than 6
| months with more than a few comments, etc). Yeah you can build
| reports with this, but I find these are more accessible and used
| when they're organized within a logical structure in the wiki vs
| buried in a flat list of dozens or hundreds of other reports.
| iainmerrick wrote:
| As others have said here, the main problem is just that it's
| really slow.
|
| Apart from that, I think the only item on this list that really
| puts its finger on a key problem is #1, inability to manage
| dependencies between projects. You try to work around Jira's
| problems by splitting the work into separate projects, but then
| they're almost completely siloed, and Jira doesn't help you
| connect them up.
|
| The other problem I have with it is that it's too fussy about the
| hierarchy of issue types. You have sub-tasks, stories, epics, and
| initiatives. Each one has special semantics and certain supported
| operations. If you started defining some work at the wrong level
| of granularity, too bad, because switching everything to a
| different tier is complicated and massively slow (literally a
| multi-page wizard, a progress bar and a confirmation screen when
| making a "mass edit", i.e. a trivial edit to two or more issues).
|
| Hierarchical issues is a good idea, because that's a very natural
| way to break down and refine work estimates, but it should just
| be an arbitrary tree, not a strict and limited set of tiers.
|
| Too much complexity, not enough generality. (And not enough
| speed.)
| paulryanrogers wrote:
| Looks like the complexity is a consequence of its generality.
| Much like Word it serves so many different cases that many
| people end up using only subsets of features. Yet the code must
| support all possible cases.
|
| Competitors too will likely drift into the same quagmire unless
| they're unashamedly opinionated.
| alexchamberlain wrote:
| I'm no fan of JIRA, but why are we all using it if we hate it so
| much?
| wtf_is_up wrote:
| I really enjoy JIRA.
| meagher wrote:
| As others have mentioned, check out: https://linear.app
|
| https://height.app is also quite good
| dyeje wrote:
| Jira sucks but it's not because of these reasons. In fact if you
| fixed each item here, it would be worse.
|
| Jira sucks because it is unopinionated and infinitely
| customizable. As a result, everybody who believes they've
| discovered the perfect project management setup (spoiler: they
| haven't) is empowered to cook up their vision via an inscrutable
| set of customizations. This leads to a bunch of inconsistencies
| between projects and endless bikeshedding. I imagine all this
| dynamic configuration is also the reason their cloud hosted
| version is so painfully slow.
| elric wrote:
| There is no magical one-size-fits-all project management setup.
| Having a tool that is customizable to match your team's
| workflow is a great win in my book. I've never encountered any
| organizations where there is endless bikeshedding regarding
| Jira. Would you care to give an example?
| alexchamberlain wrote:
| Format of labels; what is an epic, vs a version on an epic;
| what do swim lanes represent; do you tag cross team
| dependencies etc
| DeBraid wrote:
| Sucks indeed. Ended up using the CLI for most JIRA related
| activities in my previous job.
| https://www.npmjs.com/package/jira-cli
|
| Some utils to add to `bashrc`: alias jo="jira
| open" alias js="jira show" jos() {
| ticket="$1" if [ $# -eq 0 ] then
| jira open else jira open
| PROJECT_NAME_HERE-"$ticket" fi }
| jss() { ticket="$1" if [ $# -eq 0 ]
| then jira show else jira
| show PROJECT_NAME_HERE-"$ticket" fi }
| jqlf() { jql="$1" chrome https://__PROJECT_NA
| ME_DOMAIN_HERE__.atlassian.net/issues/?jql="$jql" }
| alias jm="jira mark" alias jcs="jira create
| --project PROJECT_NAME_HERE --type 10001 --priority 3" # create
| story alias jcb="jira create --project PROJECT_NAME_HERE
| --type 10004 --priority 3" # create bug alias jce="jira
| create --project PROJECT_NAME_HERE --type 10000 --priority 3" #
| create epic alias jjq="jira jql" # custom query
| alias jql="jira jql" # custom query # example: #
| jjq 'project = PROJECT_NAME_HERE AND sprint = 158 AND "Epic Link"
| not in (PROJECT_NAME_HERE-4695, PROJECT_NAME_HERE-4373) AND
| status in ("Push to PROD") ORDER BY cf[10008] ASC'
| quattrofan wrote:
| Agreed it is now far too complex and the cloud version
| appallingly slow. I no longer recommend it to anyone.
| pkt1975 wrote:
| What would you recommend now?
| itronitron wrote:
| https://www.redmine.org/
|
| or
|
| https://trac.edgewall.org/
| fnord123 wrote:
| Trac is unusably slow. It's even worse than JIRA.
| real_joschi wrote:
| - GitHub/GitLab/Gitea issues and projects
|
| - YouTrack: https://www.jetbrains.com/youtrack/
| fnord123 wrote:
| What do you recommend?
| wintorez wrote:
| All I want from Jira is to allow me to use Markdown.
| Klaster_1 wrote:
| The new rich text editor still confuses me when it comes to
| newlines and quote blocks, in months since it's been gradually
| rolled out, I still can't remember if it's Shift+Enter or Enter
| to end the quote block and what kind of newlines work with
| quotes, if it's the selected text or a hidden paragraph that
| quotes are applied to and so on. Just let me edit the raw
| markdown as before or expose the underlying markup model when
| editing.
| mulcahey wrote:
| It has a markup language that accomplishes the same thing
| effectively but has a completely different syntax. This is
| super annoying when you are bouncing between pull requests in
| Atlassian Bitbucket and JIRA tickets. I have tried to create a
| heading with # only to end up with an <ol> at least a hundred
| times.
|
| I imagine this is because JIRA (2002) predates Markdown (2004),
| or at least its mainstream popularity when GitHub adopted it.
| denysvitali wrote:
| Is that an excuse? If we have to make a fair comparison, HTML
| 5 is newer than both: is that a reason why one shouldn't not
| update the procuct?
|
| As an additional side note, Jira updates are NOT free. You
| have to pay for a license fee every year to get the updates +
| support, but the product unfortunately remains kind of the
| same: super slow and with missing basic features (e.g:
| Markdown)
| Can_Not wrote:
| It's like the features of markdown without the convenience
| and usefulness of markdown.
| [deleted]
| randallsquared wrote:
| It's definitely not all I want, but that would be huge. Also in
| Confluence, please.
| lbruder wrote:
| I've made the switch back to Redmine for my personal
| projects. By now it has full Markdown support for issues and
| wiki. Faster than Jira, and easier to use.
| franze wrote:
| In my job I use:
|
| * Google Analytics
|
| * Google Search Console
|
| * Jira
|
| So basically I wait and wait and wait to manage projects to make
| websites fast.
| jcahill84 wrote:
| I aspire to build a product that has a website dedicated to how
| much it sucks, in namesake.
| stephen_g wrote:
| What's killing Jira and the other tools in Atlassian's suite for
| us is them killing off the on-premises server products. Some of
| the companies I work with have defense security requirements and
| just can't use it in the cloud (unless they followed a lot of
| stringent requirements that are not on their roadmap, and I
| assume they would charge a lot more for that).
|
| The cloud versions are also _far_ more expensive and while I've
| always liked the software in general (apart from it being dog
| slow), a big draw was how cost effective the server products
| were. So I'm about to start evaluating GitLab, YouTrack, etc. to
| start moving these companies off Jira, Bitbucket and Confluence
| in the next year or so.
| Aeolun wrote:
| Jira datacenter is too expensive too?
| ChrisMarshallNY wrote:
| I was a JIRA admin for a waterfall-based company (Japanese). They
| did process _hard_. Agile was a cussword, and the JIRA workflows
| were standalone engineering efforts; complete with custom JIRA
| plugins, written in Java, because even JIRA couldn 't handle some
| of the process.
|
| I guarantee that it would have had most of the folks here,
| whimpering under their standing desks.
|
| It was the Tenth Circle of Hell.
|
| It gave me a sort of PTSD, so that, now I'm on my own, I try not
| to write anything down, and, if I do, it's usually a small list
| on a whiteboard.
|
| If I never see JIRA again, I will die a happy man.
|
| That said, it is like blaming the asphalt for the eminent domain
| seizures for a road. It's a symptom.
| yakubin wrote:
| I have more specific problems with Jira:
|
| 1. When editing a comment, the textarea is tiny and placed in a
| pop-up, instead of in the page. Can't resize that to see the
| comment better.
|
| 2. After disabling shortcut overrides, the shortcuts are simply
| disabled, along with the default browser behaviour for them.
|
| 3. Refreshing a page resets scroll-status. Seriously, webdevs,
| stop hijacking normal browser scroll behaviour. You always make
| it worse, never better.
|
| 4. If your login session times out when you're writing a comment,
| you can't publish it, but the error message isn't clear about the
| reason why. There was some button in the error message that
| caused you to lose the entire contents of the comment you were
| writing. Happened to me several times after writing comments 8+
| paragraphs long. It's infuriating.
| CraigJPerry wrote:
| Unpopular opinion: it doesn't suck.
|
| Let me walk that back a bit - I have no experience of the cloudy
| version which unanimously seems to be derided as slow. Atlassian
| - you might wanna fix that. Like yesterday.
|
| But server (& datacentre) editions - best in class for my money.
|
| In terms of features, the Rally / Agile Central (did that just
| re-brand again?) rollup roadmap view is the only missing feature
| i crave. Atlassian should just merge the portfolio product into
| jira.
|
| As for everything else - speed is absolutely fine if hosted well.
|
| I tend to council people to try to use less features not more -
| often jira features are used to attempt to work around challenges
| that are best addressed by talking to people instead.
|
| It integrates with everything, no matter what source control,
| build pipeline or IDE tooling is in use, there's integration with
| jira.
|
| The REST API is absolutely usable (mostly for workflow automation
| and analysis purposes).
| stephen_g wrote:
| Server starts heading towards EOL in February 2021
| unfortunately. They've said that they will support it for three
| years after that date but you'll only be able to renew licences
| (not buy new ones), the pricing is going up and you can't
| change tiers.
|
| Datacenter is still supported but I think they're jacking up
| the price of that too.
| smitty1e wrote:
| Indeed. It is a tool. The chief issue I encounter is the staff
| not actually using the tool, whether Jira or otherwise.
|
| If Jira takes a performane hit by lowering the bar for the non-
| techs, fine.
|
| Just use the tool.
| denysvitali wrote:
| > But server (& datacentre) editions - best in class for my
| money.
|
| Well, performance wise they're as bad as the cloud version.
| Even when you give the instance a lot of CPU / Memory. The
| problem is not only the Spring application itself, the DB seems
| to be missing some indexes or the queries are super badly
| optimized. God only knows what's really happening under the
| hood, but my self hosted Jira instance isn't any better (I've
| tried them both, cloud and on-prem).
| dangoor wrote:
| Jira Portfolio is becoming "Jira Advanced Roadmaps" in the
| Cloud version (as part of the Premium subscription). It's
| pretty decent, actually.
| curzondax wrote:
| I just want to quickly see the dashboard of my project and the
| status of my tasks for the daily. Just getting there is a pain
| every day.
| jeffreyrogers wrote:
| I haven't encountered a bug/feature tracker that doesn't suck.
| They're really designed for managers so that they have some
| glimpse into what the people they are managing are working on.
| Something designed solely for engineering teams would be much
| simpler I think.
| AltruisticGapHN wrote:
| As a dev working in a team with "sprints" and creating/ solving
| tickets, I find the interface awful.
|
| I remember 10+ years ago jira had straightforward tables, it was
| much quicker to add, remove, close issues. I'd open a bookmark to
| a page with a simple table listing of all issues assigned to me.
|
| I don't know what the heck is going on, now the ui is this awful
| "modern clean" style with popups everywhere, sidebars, everytime
| i look at an issue it's cramped in a tiny column, or i have to
| open in a new page. The whole ui is so slow and clunky, you have
| to expand/collapse content all 5he time. All in the name of what?
| Is scrolling down a page so difficult for a user? How does Amazon
| make money?
| jimbob45 wrote:
| What would you have us use instead? Trello?
| echelon wrote:
| Github issue tracker is a fantastic alternative if you aren't
| deep down the Jira hole.
| st1x7 wrote:
| Trello is great for small projects and for personal lists and
| boards. I certainly wouldn't want to manage a complex project
| with a large software team from Trello.
| emilsedgh wrote:
| What's your threshold for considering a team as large?
| MatekCopatek wrote:
| My go-to options are the following:
|
| - Whatever GitHub/GitLab provides if I need the most basic
| level of tracking.
|
| - Trello for a more polished experience, a few additional
| ticket/board related features and easier involvement of non-
| developers.
|
| - Linear if there's a bigger team that needs more than a bunch
| of boards (backlogs, roadmaps, projects, teams etc.).
| Can_Not wrote:
| > Trello for a more polished experience
|
| On android, returning from a screen unlock deleted all my
| unsaved text.
| echelon wrote:
| Not sure why you're being downvoted - someone from Atlassian,
| maybe?
|
| I wholeheartedly agree with your suggestions. Trello won't
| scale, but it's good for n < 3 users, especially if working
| with non-engineers / non-PMs.
| pjc50 wrote:
| Am I the only person who liked bugzilla?
| pcora wrote:
| that was fast
| oftenwrong wrote:
| If you have minimal needs, you could use a simple ticket system
| like the Erlang ticket system Joe Armstrong described in 2014:
|
| https://joearms.github.io/published/2014-06-25-minimal-viabl...
|
| In use from 1985 to 2014 and maybe longer.
| cratermoon wrote:
| Every time I upvote a submission by the title without reading it
| I regret it, and this time is no exception. Some of the items
| don't even make sense as written. The fourth item, for example,
| has two huge issues. 1. It's about Confluence, which is a
| _different_ Atlassian product. There 's some Jira/Confluence
| integration, but they are not the same thing. 2. "you have to
| save the other user changes also and while viewing the
| confluence, if you want to edit, the user will be redirected to
| other pages." That sentence is gore.
| Closi wrote:
| Great article. As you are likely not native English, just as a
| tip you can actually simplify a lot of statements by removing the
| word 'the'. As one example:
|
| > When the users need the features from Jira and request them to
| configure the plugins for many application scenarios, which
| contribute to the overall complexity of UIs.
|
| Becomes
|
| > When users need features from Jira they request plugins, which
| contributes to UI complexity.
|
| Not a criticism - just thought this might help!
| mongol wrote:
| Are both equally correct?
| Closi wrote:
| The first has incorrect use of the definite article (the
| users, the features), but to be honest it's less about
| specific grammar syntax/rules and more about making writing
| easier to understand and more concise.
| bambataa wrote:
| Second is preferred.
|
| When you say "need the features", that immediately makes me
| think "which features?" because it reads as if you are
| referring to some previously mentioned features.
| psnatch wrote:
| Yes, but only one is easy to _read_ correctly.
| chrisseaton wrote:
| The 'features' in the sentence are indefinite - they're not
| fully specified - so clearly adding a definite article isn't
| right.
| dkdbejwi383 wrote:
| No offence but I couldn't understand the example without the
| correction.
___________________________________________________________________
(page generated 2020-12-31 23:00 UTC)