3 ms·

> 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. T

by 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.

bumby 5y ago
Just out of curiosity, what do you think standards are meant to address? In my experience they are meant to mitigate risk. Now maybe that risk is not credible on a particular project which means that standard doesn't apply. But in all other cases, not adhering to standards means you are incurring additional risk, by definition. Now maybe you're just saying, "Yeah, but those are acceptable risks" in which case I don't really think we're saying anything different. My experience working on safety-critical code uses standards that explicitly state what risk is acceptable so there isn't much wiggle room for wishy-washy statements like "good enough". They aren't esoteric, abstract standards of practice (and maybe that's where our personal experience diverges). It becomes relatively clear, with a good testing plan to maps to said standards, whether that risk threshold was met. It's easier to illustrate with hardware, but the same principles apply. Say there's a standard that states each critical component must have a specified reliability level. You could either install a single component that meets that reliability level or design redundancy so the overall reliability meets the standard requirement. What you can't do is install a lower-reliability component and claim it's "good enough" unless you change the definition of critical. And that's what sometimes happens in practice; people get through a design/build and realize they didn't meet the pre-defined/agreed upon standard and so they perform mental gymnastics to convince themselves and others that the component isn't reaaalllllly critical as originally defined. And that discussion shouldn't be based on subjective judgement. As the sign above my old quality manager's office said "In God we trust, but all others must bring data." >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. This might be part of where our opinions diverge. My experience in hearing "good enough" seems different than yours. It sounds like you're using it as "it solves the problem, so it's good enough". My usual experience is more along the lines of "it doesn't meet the standard, but it's good enough." The issue in the latter case is that I think there's some hubris that one fully understands the problem. If you do, then you should have no problem bringing data to support that claim and we'd have no qualms. But if you can't, one thing standards are good at is helping to make you pause to consider all the aspects of the problem you didn't think of. Part of that hubris is the assumption that it's a stable problem. Standards capture the lessons learned when people realized it's not so stable. So clunky code may good enough to solve your conception of the problem, but that still may not be good enough if your conception of the problem diverges from reality (see: 737MAX MCAS, uber, CST-100, etc. as already brought up).

by shkkmo 5y ago

bumby 5y ago

Just out of curiosity, what do you think standards are meant to address? In my experience they are meant to mitigate risk. Now maybe that risk is not credible on a particular project which means that standard doesn't apply. But in all other cases, not adhering to standards means you are incurring additional risk, by definition. Now maybe you're just saying, "Yeah, but those are acceptable risks" in which case I don't really think we're saying anything different. My experience working on safety-critical code uses standards that explicitly state what risk is acceptable so there isn't much wiggle room for wishy-washy statements like "good enough". They aren't esoteric, abstract standards of practice (and maybe that's where our personal experience diverges). It becomes relatively clear, with a good testing plan to maps to said standards, whether that risk threshold was met. It's easier to illustrate with hardware, but the same principles apply. Say there's a standard that states each critical component must have a specified reliability level. You could either install a single component that meets that reliability level or design redundancy so the overall reliability meets the standard requirement. What you can't do is install a lower-reliability component and claim it's "good enough" unless you change the definition of critical. And that's what sometimes happens in practice; people get through a design/build and realize they didn't meet the pre-defined/agreed upon standard and so they perform mental gymnastics to convince themselves and others that the component isn't reaaalllllly critical as originally defined. And that discussion shouldn't be based on subjective judgement. As the sign above my old quality manager's office said "In God we trust, but all others must bring data." >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. This might be part of where our opinions diverge. My experience in hearing "good enough" seems different than yours. It sounds like you're using it as "it solves the problem, so it's good enough". My usual experience is more along the lines of "it doesn't meet the standard, but it's good enough." The issue in the latter case is that I think there's some hubris that one fully understands the problem. If you do, then you should have no problem bringing data to support that claim and we'd have no qualms. But if you can't, one thing standards are good at is helping to make you pause to consider all the aspects of the problem you didn't think of. Part of that hubris is the assumption that it's a stable problem. Standards capture the lessons learned when people realized it's not so stable. So clunky code may good enough to solve your conception of the problem, but that still may not be good enough if your conception of the problem diverges from reality (see: 737MAX MCAS, uber, CST-100, etc. as already brought up).