5 ms·

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 en

by 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
  > 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. That's not a definition, but a description. It was pretty clearly not an description of "safety-critical code". You've inserted a context of safety-critical vehicle control systems into a comment responding to an anecdote about writing PHP4. You say things like: > Poorly defined, subjective judgement belongs more to art than engineering That only seems true if you are extremely lucky and/or early in your career. It is extremely common for software engineers to face poorly defined, nebulous problems that you simply don't have the information to solve in an objective manner. The frequency with which this happens is why the approach described by the top comment is so effective. It is a process of continual improvememnt where you try to avoid making unnecessary decisions until you have better information to make them with. What changes with safety critical code is how you gather that information (and what other processes to build to supplement developer judgment). You try to gather that information with as little risk as possible. Experimental clunky and cobbled together code has a place in this process, but not as a part of live, uncontrolled testing. You run it against models as you prototype solutions and then you refactor or rewrite that code to be good enough to test in riskier situations. The quality of the assessment matters, but there is really no problem with people making an assessment of whether the code was "good enough" for it's context. In fact, I would refuse to work with a developer who refused to make such assessments. Standards and outside analysis are important, even in non-safety critical systems, but they ate no substitute for a developer making careful assements of if code is good enough. This is part of the point the article and top comment are making. You can assume that the person who "wrote this shit" is an idiot and mock them, but you will learn more instead if you try to understand the context that drove that person to make the decision, how well that decision worked out, what it cost them and what it gained them. This is how you avoid cognitive biases, not by refusing to accept code that is truely "good enough" in some quixotic pursuit of impossible to achieve perfection. > That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough" I think you are tilting at windmills here. There is no such broad generalization. Clunkly code is often not good enough, which is why it needs to be refactored, "the moment that it starts becoming messy" (which is, I'm sorry to tell you, a context dependent subjective judement call.) But clunky code can be fine or even great. I'll take a defect free clunky code base that solves a stable problem over an elegant rewrite that adheres to the latest coding standards any day.

by shkkmo 5y ago

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
> 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. That's not a definition, but a description. It was pretty clearly not an description of "safety-critical code". You've inserted a context of safety-critical vehicle control systems into a comment responding to an anecdote about writing PHP4. You say things like: > Poorly defined, subjective judgement belongs more to art than engineering That only seems true if you are extremely lucky and/or early in your career. It is extremely common for software engineers to face poorly defined, nebulous problems that you simply don't have the information to solve in an objective manner. The frequency with which this happens is why the approach described by the top comment is so effective. It is a process of continual improvememnt where you try to avoid making unnecessary decisions until you have better information to make them with. What changes with safety critical code is how you gather that information (and what other processes to build to supplement developer judgment). You try to gather that information with as little risk as possible. Experimental clunky and cobbled together code has a place in this process, but not as a part of live, uncontrolled testing. You run it against models as you prototype solutions and then you refactor or rewrite that code to be good enough to test in riskier situations. The quality of the assessment matters, but there is really no problem with people making an assessment of whether the code was "good enough" for it's context. In fact, I would refuse to work with a developer who refused to make such assessments. Standards and outside analysis are important, even in non-safety critical systems, but they ate no substitute for a developer making careful assements of if code is good enough. This is part of the point the article and top comment are making. You can assume that the person who "wrote this shit" is an idiot and mock them, but you will learn more instead if you try to understand the context that drove that person to make the decision, how well that decision worked out, what it cost them and what it gained them. This is how you avoid cognitive biases, not by refusing to accept code that is truely "good enough" in some quixotic pursuit of impossible to achieve perfection. > That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough" I think you are tilting at windmills here. There is no such broad generalization. Clunkly code is often not good enough, which is why it needs to be refactored, "the moment that it starts becoming messy" (which is, I'm sorry to tell you, a context dependent subjective judement call.) But clunky code can be fine or even great. I'll take a defect free clunky code base that solves a stable problem over an elegant rewrite that adheres to the latest coding standards any day.