• not_woody_shaw@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    5 months ago

    Reminds me of the KSP2 fiasco. Management insisting on reusing the engine from the old game, and firing all the senior devs who could have told them there was no possibility of getting the features they’d announced to work without rewriting the engine from scratch.

  • NocturnalMorning@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    5 months ago

    Sure, but refactoring things constantly leads to bugs too. Once it works you should stop rewriting code. The SW team at my job didn’t get the memo.

      • NocturnalMorning@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        5 months ago

        Sure, refactoring is sometimes necessary. But refactoring also introduces new bugs often. Our code base is constantly being refactoring, and it’s not more reliable, stuff is constantly breaking.

          • NocturnalMorning@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            5 months ago

            Why are programmers so arrogant? They do have unit tests, and a dedicated test team. Refactoring can and does introduce bugs. It’s a fact.

            • MyNameIsRichard@lemmy.ml
              link
              fedilink
              arrow-up
              0
              ·
              5 months ago

              Frankly, if your test suite isn’t catching 95% or more of the bugs, there’s a problem with the test suite and if uat aren’t catching 95% or more of the remainder, there’s a problem with uat

      • CrypticCoffee@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        5 months ago

        Yes, and you do it at the point you need to work on that feature. The business pay for it when they want the change.

        You do not pay for the refactor with your time, if the company won’t pay to fix their code. Just make it clear the risks and how bad it could be if you carry on with duct tape fixes.

        You have to be strong and firm and not agree to hacks. You need to work with your team to ensure you’re on the same page rather than getting undermined by cowboy dev claiming he can do the feature in 2 days when it needs 2 weeks to do the necessary work.

  • rtxn@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    5 months ago

    My previous work used two mission-critical software for continuous operation.

    One was some guy’s university project written in Object Pascal and PHP and largely untouched since 2006. I tried offering fixes (I also knew Pascal), but I was rejected every time because the downtime caused by software issues was not bad enough to risk the downtime caused by the update.

    The other was (I shit you not) an Excel spreadsheet with 15000 lines and 500 columns. I tried making a copy and cleaning it up, but Excel couldn’t handle the amount of data and ran out of memory.

  • Funwayguy@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    5 months ago

    Sums up every Node project I’ve had the displeasure of looking at. The lock file being the only thing holding the twisted web of versions keeping that franken-app running between a minefield of incompatibilities and buggy hacks.

  • Presi300@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    5 months ago

    Well of course I know him, he is me… I haven’t found a job yet but this post pretty much sums a lot my personal projects.

    • Entropywins@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      5 months ago

      Personal projects = it’ll work until it doesn’t

      Professional projects = I’m hiding in the MDF hoping no one finds me

  • BaumGeist@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    5 months ago

    Take the passive-aggressive nerd approach:

    1. Start a niche online movement that only cares about one aspect of computing and convinces people all their problems are caused by your pet peeve

    2. let the company dig its grave

    3. create a FOSS alternative

    4. sell a premium version for businesses (it includes phone support and management-friendly marketing matetials)

    5. congrats, you are now the de facto standard software in your field