5 ms·

I can't tell what you are arguing about? We are laying out an approach to software development, refactoring, and a model for how to view old code that you some

• bumby 5y ago
  My point in a nutshell: Good enough is usually an excuse for vague and ill-defined practice. If you don't have a well-defined "good enough" you probably don't have a mature process. If you don't have a mature process, you probably shouldn't be writing critical code. Hence my original comment that it's not a good mindset for high-risk applications. Well defined "good enough" often looks like a standard. Those standards should be risk based so that one person's biases don't result in a different level of risk mitigation than another person's. That risk is what contextualizes what is "good enough". I'm sure if you asked the Boeing managers, they felt their CST-100 software was "good enough", but the relevant safety standards say it wasn't "good enough". Since both sides can use the term, it makes the term somewhat useless. Like you say, there is no singular "good enough" so the question becomes: Good enough...for what? Good enough to meet schedule, or good enough to not risk crashing into the ISS? My main issue is that "good enough" often means "undefined". When people say "good enough", I've found it often means "we don't know what we need, but I'm sure we'll know it when we get there." I think that can be a bad approach to software development when the risks are high because it opens one up to cognitive biases that lead to subjective and poor decision making. If you're saying "good enough" is precisely defined and based on risk, then I agree. But that is not how I've ever seen the term used in practice. It's almost always a nebulous term which means you've only vaguely defined the risk. Poorly defined, subjective judgement belongs more to art than engineering, especially not safety-critical engineering. "clunky, cobbled together, expermental or just plain stupid" as the OP said, just doesn't cut it on critical applications, even if the developer claims it's "good enough" and doesn't strike me as a professional mindset.
  • shkkmo 5y ago
    You have a highly specific definition of good enough that doesn't match my experience with it's usage. Every time I have discussed whether something is "good enough", the discussion centers on what the relevant risks, needs and priorities are. Indeed, adherence to relevant standards should be part of the "is it good enough" discussion, but following standards alone doesn't absolve you as a devolper from assessing the current contextual needs and risks. Indeed, blind adherence to standards is bad as standards are not perfect and are designed to fit a general use case. You need your developers/engineers to think about the full context and asses whether their design will hold up under real life conditions and not just those that were prevalent when the standards were created.
    • bumby 5y ago
      I think you might be subjectively reading too much into it to make a point that doesn't need to be made. Look at the actual wording of the post I originally responded to: >"But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand." Can you imagine a discussion about relevant risks and priorities that uses that definition of "good enough"? I can't, especially with safety-critical code. I'll give another example: The NTSB report of the uber autonomous driving accident gives a good breakdown of events. Through that report you can see the developers programmed a delay (they call it an "action suppression") due to nuisance braking etc. It's hard for me to imagine a code engineer programming a delay on a static delay time-sensitive safety critical system if they understood the risks (even if the mitigation was the human driver, they didn't seem to have a good understanding of human factors engineering). Yet someone along the way thought the software was "good enough" for production. It's speculation on my part, but I doubt you'd find a good FMEA or hazard analysis on that system. This is my big worry as SV mindsets get into safety critical systems: the general "move fast and break things - because it's 'good enough'" doesn't translate well to systems where lives are at stake. That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough"
      • shkkmo 5y ago