• MangoCats@feddit.it
      link
      fedilink
      English
      arrow-up
      0
      ·
      13 hours ago

      Every time I look back at old stuff, I have to remind myself of the relative importance of getting it done, vs getting it perfect, at the time.

      Inevitably, there were no clear requirements at the outset, or if there were they were vastly outnumbered by additional requirements that scope-crept their way into the project. The project was “due” before I was asked to help / landed with the whole thing to do myself. The project was under-estimated and is now “on the critical path” for a larger initiative. Other interested parties are too busy to meet during definition time, but all too willing to point out missing scope after a “finished solution” is presented.

      Yeah, me from the past… not a fair reflection.

        • MangoCats@feddit.it
          link
          fedilink
          English
          arrow-up
          0
          ·
          11 hours ago

          And the real thing, in our industry, once it is verified and validated and shipped - you don’t touch it unless absolutely necessary.

          • vrek@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 hours ago

            Yeah, I used to be in the medical device industry. Once shipped, an update typically meant a patient needed additional surgery because of your mistake. That really emphasized the “unless absolutely necessary” part of your statement.

            • MangoCats@feddit.it
              link
              fedilink
              English
              arrow-up
              0
              ·
              11 hours ago

              Not just in implantables, though implantables have that whole additional surgical risk aspect, but all medical devices have painful piles of paperwork required for each revision. They’re trying to lighten the load for “security patches” but so far it’s still a major pain. I suspect it’s the much the same in avionics and any other industry that requires documented validation against traceable requirements and all that jazz.

              • vrek@programming.dev
                link
                fedilink
                English
                arrow-up
                0
                ·
                11 hours ago

                Oh yeah… I once had a project to change a 0 to a 1 in a file on a machine used to manufacture devices. Basically operator had to align crosshairs over a certain point before starting. At 4 of the systems the operator could just touch the screen at the point and go. At one they had to push x+ or x- or y+ or y- repeatedly to line it up because the configuration had a 0 in the option “Click To Align”… It took 8 months to validate changing that to be 1

                • MangoCats@feddit.it
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  9 hours ago

                  Do you know the cost to change the color on a box? Just the color, not the text, not the information, just the color?

                  Estimate:

                  $470,000

                  No scrap cost, old color boxes used until stock depleted.

                  Vendor didn’t charge us anything to change the color on the next and subsequent lots.

                  All that was engineering hours for the document revisions, meetings to support document changes, training, recording of documents, first article inspections, etc.

    • idriss@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      1 day ago

      Progressing is cool, but having 10 yoe and still outputing spaghetti is bad. I am just saying if you care enough about what you are doing you are top 10% already

      • eldavi@lemmy.ml
        link
        fedilink
        English
        arrow-up
        0
        ·
        16 hours ago

        the quality of the code is dependent on the quality of the pay. lol

        • Cityshrimp@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          13 hours ago

          And as others have noted, how much time you are actually given. PMs and managers don’t know or care about code quality, they just want something to work NOW

          • Kjell@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            13 hours ago

            And there is never time to maintain the code, because each project only want to add more feature/s which makes the spaghetti code even worse.

            In my group we had a golden opportunity to fix all old mistakes but no, we (decided by PO and group manager) needed to spend all time on proof of concepts that will go to production at earliest in 5 years. Now that opportunity is gone and we are crunching in order to meet the deadlines instead. Still with bad code quality of course.