• eselover@lemmy.today
    link
    fedilink
    arrow-up
    57
    ·
    1 year ago

    Ah yes the forgotten land of uncompleted tasks. Slated to be a hotfix when it becomes a problem.

  • XYZinferno@lemmy.world
    link
    fedilink
    arrow-up
    40
    ·
    1 year ago

    I don’t know when this meme was originally made, but my boss unironically has this taped to his office door, and it’s glorious

  • Arghblarg@lemmy.ca
    link
    fedilink
    arrow-up
    26
    ·
    1 year ago

    Everywhere I’ve ever been,

    If it’s lower than “High” or “2”, it’s as good as “backlog” :)

    (There can never be a priority “1” and seldom “Highest”, never “Blocker”, otherwise the CEO gets a text or something.)

  • lukas@lemmy.haigner.me
    link
    fedilink
    English
    arrow-up
    23
    ·
    edit-2
    1 year ago

    Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home. Oh, unless you want them to spend overtime on a production problem whose root cause a scrum master added to the backlog 5 years prior to the incident, of course. Oh, unless you want them to give you one year estimates for changes as simple as translation changes 'cause the architecture is so ass-backwards and never improved upon that everything depends on everything and everything breaks with one simple change. And who needs tests, right? Waste of time and money! Just live in fear that one change can break the entire software, like a real man.

    • Prox@lemmy.world
      link
      fedilink
      arrow-up
      11
      ·
      1 year ago

      Backlog isn’t sexy. Management wants sexy. Nobody’s boss wants to hear about how the DB schema was improved - they want to see some new, flashy widget.

      And the whole product line suffers because of it.

    • Piers@beehaw.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home.

      But why do that when instead you can just pretend those issues don’t exist (or simply fail to understand them) and secure a bonus/promotion/personal favour by cutting “unnessecary” labour costs then celebrate by burbling on about how capitalism “maximises efficiency”.

  • CarrotIsland@beehaw.org
    link
    fedilink
    arrow-up
    21
    ·
    edit-2
    1 year ago

    Backlogs are great. Sometimes while working on prioritized tasks the depriorized backlog tasks are made irrelevant and thus you never have to do them and you don’t waste effort. Call it strategic deprioritization or perhaps even tactical laziness.

  • MasterBlaster@lemmy.world
    link
    fedilink
    arrow-up
    21
    ·
    1 year ago

    I’m a Senior developer, and I’m still playing the part of the Junior in this meme.

    I hate it when people insist on leaving their trash lying around where I work.

  • gargantuanprism@lemmygrad.ml
    link
    fedilink
    arrow-up
    16
    arrow-down
    1
    ·
    1 year ago

    Honestly why do jr devs want to do work so bad, I’m literally just like “yo chill” and they keep pestering me for work

  • stilgar [he/him]
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    IMO it’s good to have a “shadow backlog” for stuff like this. Keep the actual backlog for prioritised product work, “ideas” and tech debt can be kept in GitHub Issues or even just a wiki page somewhere.

    • CoderKat@lemm.ee
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      1 year ago

      I have two levels of backlog. The first level is my curated list of tickets that are highly worth doing in the near future and is limited in size. It’s currently larger than I’d like at 30-something (for a team of a little under 10), but I’m trying to get the team to focus on it more after historically neglecting it.

      The second level is literally just everything else. Hundreds upon hundreds of tickets, ranging from restructuring unit tests (which will frankly never happen unless the structure of the tests somehow became a major barrier) to cool features that just aren’t important enough yet (or would take too long). Plus all the super low risk bugs, often in edge cases that nobody really cares about yet or aren’t worth the time to fix yet. And then there’s all the automation style tickets about improving the handling of something (commonly edge cases of things already automated for the happy path), but often that something just isn’t common enough to be worth it.

      Tickets in the second level sometimes do get done. Usually because some issue becomes more common, enough people ask for it, or we simply finally have time for a new feature (can only do so many of those at a time). A common theme I have is I’ll encounter a problem, file a ticket, then eventually encounter the problem enough times that I go, “fuck it, I’ll do it myself”.

    • lukas@lemmy.haigner.me
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Meh, I prefer to call it trash. What’s the point of a backlog nobody works on, and so hopelessly irrelevant that the issues themselves may no longer exist or are otherwise outdated?

      • stilgar [he/him]
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Because then when someone else suggests the same thing you can say that its in the backlog 😉

  • 21racecar12@lemmy.world
    link
    fedilink
    arrow-up
    13
    ·
    edit-2
    1 year ago

    Our solutions architect is like this. Not because we’re working on anything important at the moment, but because we keep pushing back important upgrades further and further, making each day a more challenging operation to keep our rickety-ass distributed monolith alive.

    We were supposed to upgrade from Java 8 on Springboot 2.1 to 17 on Springboot 3. That got wiped off the table because the bosses think shoving our inefficient solution into a cloud product is what will attract customers.

    • lukas@lemmy.haigner.me
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      I’m not too familiar with Spring, so excuse my ignorance, but could you sell Spring Cloud ✨ to management? If I understood the docs correctly, Spring Cloud requires Springboot 3, so you can migrate to Springboot 3 while management can claim that your monolith is very cloud. Or is this a “dump it in ec2 and claim it’s cloud” situation?

      • 21racecar12@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Dump it into ec2-type lol. It’s not a product that can or should be cloud native without becoming a security nest of hornets for customer cybersecurity departments.

  • Gnubyte@lemdit.com
    link
    fedilink
    English
    arrow-up
    12
    ·
    1 year ago

    “I archived them all Padme. They’re gone…every single one of them. And not just the minor tickets.”

  • Rev@ihax0r.com
    link
    fedilink
    arrow-up
    12
    ·
    1 year ago

    ugh Jira. At my first job in 2006 I was the Jira administrator. Every project wanted their own custom fields. We had a Jira project for “infra” problems it had 3 fields yall Title/Description/priority and it worked so well. Moved to a company with a simple ticket system with not much more but the concept of “tags” it was heavily

  • jj4211@lemmy.world
    link
    fedilink
    arrow-up
    10
    ·
    1 year ago

    In our case, tossing stuff in the backlog to never get done is just part of trying to get through life.

    We have an… eccentric colleague who demands the craziest stuff that no one else wants. Now in a sane world, we explain that his requests are either extremely costly for a minor thing no one cares about, or, like 90% of his requests, run explicitly counter to what our customers want even if we could trivially do it. He is not a customer nor is he in contact with customers or marketing or sales, he’s in a different technical team but has an “armchair enthusiast” interest in my teams product.

    We used to try to have that discussion to reject items to make it clear they will never ever get worked on. However whenever we did that he would demand hour after hour after hour of meeting to discuss each request that we want to reject and convince us why his requirement is the most awesome thing in the planet, and with enough meetings maybe we’d stop being so clueless and come around to recognize the brilliance.

    So now we toss it in the backlog, and there’s always a point of comparison like “Customer giving us $40M asks for feature X”, and he has to rationally accept why X jumps ahead of his backlog items, even if he is displeased. One new project manager made the mistake of trying to close out the backlog items and the meeting invites flew about us daring to ignore his awesome requests.

    So we have a chunk of backlog that every one knows will never happen, and in fact if our backlog ever dried up, then we’d have a big problem because then we’d actually have to have that tough conversation about why his ideas are bad. At this point some of his wacky stories have been on the backlog for over five years.

    • Windex007@lemmy.world
      link
      fedilink
      arrow-up
      22
      ·
      edit-2
      1 year ago

      I’m the Sr. Dev in this meme.

      I usually just do this when a jr has fallen in love with a piece of work and wants to keep polishing it. They start to confuse “I could do X” with “I should do X”… And confuse “less than perfect but still acceptable” with “bug”.

      I tell them to slap it on the backlog and to move on.

      We have backlog grooming meetings every few weeks. If they still actually want to do it, we can talk, but like 19 times out of 20 they’ve found a new shiny rock by then anyways, and we’re now in a position where we can both agree it isn’t a good use of our time, and close it out as a “will not do”.

      You don’t need aggressive POs or scrum masters to operate as a pragmatic team. I far prefer having a lean overhead. When there are more people shouting directions than people actually coding you’ve got too many cooks.

      • MasterBlaster@lemmy.world
        link
        fedilink
        arrow-up
        11
        ·
        1 year ago

        It’s interesting how people have different interpretations of mwmes. You took it as a reflection of a perfectly normal good thing, while I took it as a perfectly normal bad thing.

        Iny experience, “put it on the backlog (and never look at it again)” is the response to someone raising a serious architectural problem.

        • Windex007@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          Yeah exactly. I think you hit the nail on the head with the “(and never look at it again)”.

          It’s not explicit in the meme. “Not doing it” and “never look at it” are totally different things… But I think you’ll fill it in based on your personal experience.

          I’m sorry your backlog doesn’t get regularly revisited.

          If I were you, I’d push for setting aside time to get it under control.

          If your backlog is gigantic, I expect there will be pushback just because once the problem gets sufficiently large nobody is brave enough to broach it.

          But, you can apply story slicing skills to these kinds of problems too. Break it down into smaller bits with clear and realistic objectives. Setting aside 30 minutes with the goal of, say, picking 5 items on your backlog that you know you won’t ever do because they’re super low value? Pick 5 items and close them off as won’t do. Baby steps.

          • MasterBlaster@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Currently, I am not living this hell. But I gotta tell you, you are supporting a pipe dream.

            Literally, if I cannot describe a direct benefit to the so-called end user it won’t even be looked at. The development and engineering team are unimportant. The first part I was told directly, the second part was implicit.

            Most corporate environments use scrum or agile as ceremony - decorations to make everybody think they’re doing something better than what they’re really doing. Then when it fails, they can go back to what they were really doing and claim agile was just a fad.

        • Windex007@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          Sometimes. Sometimes it’s just “I can refactor this to use X pattern”. Or “I COULD push X logic to some other layer”

      • ChickenLadyLovesLife@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        When there are more people shouting directions than people actually coding you’ve got too many cooks.

        Ha ha what about when the shouters:coders ratio hits 10:1?

    • Dave@lemmy.nz
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Yep. Gotta clean out that backlog by deleting the stuff that will never get done.