But when you have discovered that your code is logically or mathematically inconsistent, you really need a better justification for leaving it than, "Well, it's worked so far." That's exactly the kind of thinking that resulted in both shuttle disasters, and that's exactly the kind of thing my friend faced from management.

Now hardware: The NASA hardware guys who showed up to the Houston hackerspace always really impressed me. (But what do I know? I'm a software guy.)

Sure; I suppose it comes down to your definition of "broken". I would consider inconsistent results broken and, as you say, a thorough analysis should be performed to assess the impact.

I was thinking more along the lines of "I don't like this code, let's refactor". That can be dangerous.

I think management was traumatized by some of the hubristic "let's refactor" crowd, and overcompensated. My friend was a physics major, not CS, and his programming style was cautious, conservative, and workman-like. His physics and math was top notch, and that's where his objections to the NASA code came from.