4 ms·

Oh my God, this comment shows up on a lot of these threads about software correctness and I can't disagree more. * Today, modern software is failing left and r

Oh my God, this comment shows up on a lot of these threads about software correctness and I can't disagree more. * Today, modern software is failing left and right. It's a serious problem and it's extremely frustrating. In part, this is because software industry has abysmal correctness practices. In part, this is because when software engineers write code correctness is an afterthought. * Software correctness, is not easily measurable, and therefore cannot be approached as a metric, instead should be approached as a mindset. Software correctness is about designing systems such that bad things cannot happen by definition. When approached this way, seeing instances of unsafe ideas is sufficient red flags and should be removed. This is because the fact that unsafe constructions exist is sufficient evidence that unsafe behavior exists. * When unsafe code is written, it can be shown that it "works", but this takes effort and engineering time. When things are designed such that they cannot fail, it doesn't take effort and engineering time to make sure they "work". This is why designing from the beginning with correctness in mind is superior than writing crap code and then debugging later. * You say working with good code is a luxury, but it's actually the opposite sometimes. Sometimes you can write code that works 99.9% of the time and call it a day. This is a luxury. Some of us can't. Sometimes it really is the case that if software fails 0.01% of the time someone will be physically harmed. In cases like this some software engineers scratch their heads because they know how to fix bugs, but they don't know how not to never add bugs in the first place. Why did I write this comment? In case you wonder: * You say some people have code purity complex, which you use pejoratively. But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. It occurred to me your comment lacks self-awareness in this regard. * You say "developers will be sitting home fuming", as if this out of some abstract religious principle, when there are concrete, sometimes mathematical reasons why certain code purity concepts exist. * You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost.

tomlockwood 4y ago
> But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. You better believe that I complain loud and hard about crap code. I complain about how crap other people's code is, and I have the self-awareness to complain about my code that is crap. What I have a problem with is the attitude some people have that developers "suck" because they write crap code. For example, some people write method names that aren't descriptive. It happens. I personally don't think they should be forced to write "I suck" 30 times on their school blackboard because of this. What would that actually achieve? > You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost. No, actually, I do realize this. But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost. From the VB6 example I used before - the runtime will actually be out of all versions of Windows from 2024. But that's a problem for Another Project. You may think that writing "incorrect" code is a self-limiting decision but I can assure you that I am doing fine and my clients/managers/colleagues have generally enjoyed working with me.
- gnulinux 4y ago
  Amen to this comment, I apologize if my previous comment went too far, it seems like we're overall on the same page, at least on some issues. > For example, some people write method names that aren't descriptive. It happens. I agree, and I would actually argue names don't matter. Well, they do, we should still pick good enough names, and never pick adversarially confusing names. But ultimately, code should be clear regardless of the name. Take a look at this Haskell talk for better arguments than I can write here: [1] Part of the reason why designing software that by definition cannot include bad behavior is such a powerful concept is because even when we inevitably name things terribly, the harm is contained. [1] https://www.youtube.com/watch?v=ZSNg6KNzydQ https://www.youtube.com/watch?v=ZSNg6KNzydQ > But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost Sure, but this part of the problem. As engineers, it's also our duty to explain to business people the implications of these. If ultimately the business decision is that "this thing won't matter in X years" then there is nothing we can do, but the limitations must be known and clearly communicated. Which, I don't think you disagree, but I didn't think this came out in your original post.
marginalia_nu 4y ago
If we accept this as true and grant that there was a method that produced code that in many ways was superior. It would take time to write and require less effort to maintain and on top of that it would have less bugs and be more reliable, wouldn't that give whatever shops adopted these practices have just an insane competitive advantage? This seems extremely paradoxical, especially given, in your own words "[t]oday, modern software is failing left and right." Why isn't cheaper, faster-to-develop software that requires less maintenance and isn't failing left and right able to completely take over?
- xmcqdpt2 4y ago
  The parent specifically states that correct unsafe code is more expensive to produce though? I agree with the parent anyway. Most programming is relatively low stakes (at worst the user restarts the app or make a new shopping cart or sends the message again etc.) which then means that most programmers are trained to write low-stakes code. IMO this is why "turning it off then on again" and "delete the configuration files" are such common advice.
  - marginalia_nu 4y ago
    Seems to contradict this statement: > When unsafe code is written, it can be shown that it "works", but this takes effort and engineering time. When things are designed such that they cannot fail, it doesn't take effort and engineering time to make sure they "work". This is why designing from the beginning with correctness in mind is superior than writing crap code and then debugging later.

tomlockwood 4y ago

> But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. You better believe that I complain loud and hard about crap code. I complain about how crap other people's code is, and I have the self-awareness to complain about my code that is crap. What I have a problem with is the attitude some people have that developers "suck" because they write crap code. For example, some people write method names that aren't descriptive. It happens. I personally don't think they should be forced to write "I suck" 30 times on their school blackboard because of this. What would that actually achieve? > You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost. No, actually, I do realize this. But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost. From the VB6 example I used before - the runtime will actually be out of all versions of Windows from 2024. But that's a problem for Another Project. You may think that writing "incorrect" code is a self-limiting decision but I can assure you that I am doing fine and my clients/managers/colleagues have generally enjoyed working with me.

gnulinux 4y ago
Amen to this comment, I apologize if my previous comment went too far, it seems like we're overall on the same page, at least on some issues. > For example, some people write method names that aren't descriptive. It happens. I agree, and I would actually argue names don't matter. Well, they do, we should still pick good enough names, and never pick adversarially confusing names. But ultimately, code should be clear regardless of the name. Take a look at this Haskell talk for better arguments than I can write here: [1] Part of the reason why designing software that by definition cannot include bad behavior is such a powerful concept is because even when we inevitably name things terribly, the harm is contained. [1] https://www.youtube.com/watch?v=ZSNg6KNzydQ https://www.youtube.com/watch?v=ZSNg6KNzydQ > But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost Sure, but this part of the problem. As engineers, it's also our duty to explain to business people the implications of these. If ultimately the business decision is that "this thing won't matter in X years" then there is nothing we can do, but the limitations must be known and clearly communicated. Which, I don't think you disagree, but I didn't think this came out in your original post.

marginalia_nu 4y ago

If we accept this as true and grant that there was a method that produced code that in many ways was superior. It would take time to write and require less effort to maintain and on top of that it would have less bugs and be more reliable, wouldn't that give whatever shops adopted these practices have just an insane competitive advantage? This seems extremely paradoxical, especially given, in your own words "[t]oday, modern software is failing left and right." Why isn't cheaper, faster-to-develop software that requires less maintenance and isn't failing left and right able to completely take over?

xmcqdpt2 4y ago
The parent specifically states that correct unsafe code is more expensive to produce though? I agree with the parent anyway. Most programming is relatively low stakes (at worst the user restarts the app or make a new shopping cart or sends the message again etc.) which then means that most programmers are trained to write low-stakes code. IMO this is why "turning it off then on again" and "delete the configuration files" are such common advice.
- marginalia_nu 4y ago
  Seems to contradict this statement: > When unsafe code is written, it can be shown that it "works", but this takes effort and engineering time. When things are designed such that they cannot fail, it doesn't take effort and engineering time to make sure they "work". This is why designing from the beginning with correctness in mind is superior than writing crap code and then debugging later.