• not_woody_shaw@lemmy.worldEnglish
    76·
    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.

    • PlexSheep@infosec.pub
      49·
      5 months ago

      It’s so sad what happened with KSP2, we were all so excited at the start. I’m glad I didn’t buy it though

    • zurohki@aussie.zoneEnglish
      28·
      5 months ago

      They also wouldn’t allow the new devs to talk to the old devs, so they had to figure out the old codebase for themselves.

  • rtxn@lemmy.worldEnglish
    50·
    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 cumulative downtime caused by software issues was not enough to justify the downtime caused by the update (obviously this was determined by a Middle Manager (derogatory)).

    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.

    • CosmicTurtle0@lemmy.dbzer0.comEnglish
      36·
      5 months ago

      I absolutely cannot stand this kind of logic.

      “We make a shit ton of money on this very critical piece of software!”

      “Then let me fix it!”

      “NO! It’s making us money NOW! It only stops making us money when it’s broken. At which point then we fix it.”

      “But that might be hours. We can minimize downtime if we plan properly.”

      "But it’s making us money NOW!1!1!”

      I shit you not I have had various versions of this conversation throughout my career, across industries, across disciplines.

      • rtxn@lemmy.worldEnglish
        20·
        5 months ago

        True zen is achieved when you realize it’s not your problem. Even better when the thing eventually breaks and you can be smug about it.

        • skulblaka@sh.itjust.works
          13·
          5 months ago

          I’m not in the industry anymore, but every time I raised an issue to the boss that got ignored, I used to like to keep a little folder where I’d print the emails or just take notes about the issue, the proposed fix, and when and why it got rejected.

          Then, 8 months later when everything is on fire, I could point at the date February 12, where at 3:40 PM I raised this specific issue that got ignored.

          It never benefitted me, not once, in fact I sincerely think my boss at the time thought I was a smug little prick. Which was fair, I was one. But credit where it’s due, every time I brought the folder back out, he’d get a look like he just swallowed a mug full of cold piss and tell me I was right. That’s all I really wanted out of that folder anyway.

        • CosmicTurtle0@lemmy.dbzer0.comEnglish
          12·
          5 months ago

          It’s your problem when they can’t make payroll because of it. And it’s your problem when they ultimately blame you for not having the solution ready to implement.

          The first has happened to me once.

          The second more times than I can count.

          • Victor@lemmy.world
            7·
            5 months ago
            1. Make PR ready to merge.
            2. Mark as Draft and write in the description that management says this should not be merged until the site breaks.
            3. Site breaks.
            4. They blame you for not having a solution ready.
            5. 😎 👈 You.
            • skulblaka@sh.itjust.works
              7·
              5 months ago

              And while you’re busy making this PR to fix a problem that you haven’t been authorized on, you’re falling behind on current tickets.

              The only way to realistically make this happen at most companies is if you’re doing work for your company on off time, and, generally speaking, never ever do that for any reason unless you’re being paid for on-call.

              • Victor@lemmy.world
                2·
                5 months ago

                Yeah my joke was kind of partly inspired by the drawthefuckingowl meme. Step 1 would be the owl lol.

        • bleistift2@sopuli.xyzEnglish
          7·
          5 months ago

          Even better when the thing eventually breaks

          You mean when it finally does become your problem?

          • rtxn@lemmy.worldEnglish
            6·
            5 months ago

            If it’s going to be your problem no matter what, start making offline backups of your email account, and print out the email conversation where the bossmang rejected the fix. Make sure your HR rep is present on every meeting, even especially if it makes the people uncomfortable.

            (this assumes that you live in a place where employee protection laws exist, i.e. it might not work in America)

    • SigmarStern@discuss.tchncs.de
      30·
      5 months ago

      Oh yeah, I remember the good ol’ “Our whole business Logic is within this 30 tables spread sheet, that only one person can read, and don’t you dare restarting that computer” times.

      One person. Sitting in front of three monitors. In front of a spreadsheet that maxed out every resource of that computer. It was glorious.

      • rtxn@lemmy.worldEnglish
        21·
        5 months ago

        don’t you dare restarting that computer

        We had two desktop PCs on the factory floor doing server stuff for a lot of assembly machines. We couldn’t move them to proper hardware or virtualize them because the GUI and the server were built as one monolithic application (I still don’t trust any Japanese company’s developers as a result), so one computer was made the primary server for one half of the factory and the fallback for the other half, and vice versa, to solve the reliability issues stemming from the software’s dogshit design.

        What it couldn’t solve was Windows’ dogshit design. One early Monday morning, when we switched on the factory, Windows decided to force-update itself, then failed and bricked both computers. We spent half the shift with our thumbs up our asses periodically checking if tech support bothered to show up yet.

        • IrateAnteater@sh.itjust.works
          20·
          5 months ago

          I have a lot of questions for whoever set that up in the first place, first and foremost of which is: why in the everlasting fuck was that computer ever attached to the internet? At most it should be allowed internal network access only.

          • rtxn@lemmy.worldEnglish
            12·
            5 months ago

            Some required network services were located off-site. It could’ve been done in a secure way, but don’t expect such considerations from the company described above. It’s still better than the many XP and Win2000 production machines with the same internet access.

            I can’t say a lot because of confidentiality, but if you had seen the factory around the time I quit, having a Win10 computer with internet access would’ve been the least of your concerns. If we had OSHA here, that building would’ve kept them busy for a week.

  • Funwayguy@lemmy.world
    16·
    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.

    • rcbrk@lemmy.mlEnglish
      3·
      5 months ago

      ffs, every time someone from a community group asks me “Can you have a quick look at our basic website, we just need to change <reallySimpleThing>”, and I’m like “sure, i used to do web development, let’s have a look […] FFFFFFUUUUUC…”

  • BaumGeist@lemmy.ml
    9·
    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

  • Artyom@lemm.ee
    7·
    5 months ago

    I have a coworker who thinks I’m this guy cuz it’s apparently absurd for us to add the 5 most popular dependencies on the planet to our environment and I’m sentencing us to the doom of dependency hell.

  • NocturnalMorning@lemmy.world
    4·
    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.

      • CrypticCoffee@lemmy.ml
        7·
        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.

      • NocturnalMorning@lemmy.world
        2·
        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
            2·
            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
              4·
              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

            • luciferofastora@lemmy.zip
              2·
              4 months ago

              How solid is the unit test coverage? What about regression tests? If you get new bugs creeping in all the time, your bug-catchers aren’t doing their job