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, 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.
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.
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
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.
True all that plays a part.
And the real thing, in our industry, once it is verified and validated and shipped - you don’t touch it unless absolutely necessary.
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.
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.
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