4 ms·

I think you are ignoring both failures to correctly specify what was intended (the design was right conceptually, but you specified it incorrectly when formalis

I think you are ignoring both failures to correctly specify what was intended (the design was right conceptually, but you specified it incorrectly when formalising it so now you have a perfectly verified incorrect implementation), and failures in the design (the thing works as you designed it, but it turns out your design isn't perfect). More likely, you're not unaware of these possibilities, you're just using a meaning of "failure" that excludes them. But regardless of whether you call these failures or call them something else, they prevent you from guaranteeing perfection.

lmm 6y ago
On the contrary, there is guaranteed perfection: I can guarantee that they perfectly implement the given formal specification. I think we're in agreement that one can't produce a guaranteed-perfect system (since the system will always have a part that must interact with humans), but I don't think that actually supports the approach of treating every component as fallible.
- marcus_holmes 6y ago
  And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly?
  - lmm 6y ago
    > And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. Not my experience; the system may need new components or need to rearrange the existing ones, but the components themselves don't become imperfect. Consider something like a prime factorization algorithm; maybe your system will change to the point where you don't need it, or need to extend it, but it continues to be perfect. > And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly? Tech companies go bankrupt all the time, so I think it's a stretch to say that commercial coding is working perfectly. Automating a sloppy human process in an equally sloppy way can certainly make you money, and maybe there's more money in doing that than in making perfect things, but we should at least acknowledge that there's an unexplored alternative here.
    - marcus_holmes 6y ago
      Your example of a component is kinda trivial: this sort of component is usually handled by a standard library and not developed in-house anyway. The stuff that's developed in-house is to service a customer need, and customer needs definitely change over time. > Tech companies go bankrupt all the time generally speaking they don't go bankrupt because of bad tech, though. It's usually imperfectly understood customer needs. No amount of perfect tech is going to stop that.
      - lmm 6y ago
        > this sort of component is usually handled by a standard library and not developed in-house anyway Currently yes; that's what I'm arguing could change. Every library has to be written somewhere, and at a lot of jobs I've found myself rewriting the same should-be-standard pieces again and again. > The stuff that's developed in-house is to service a customer need, and customer needs definitely change over time. Yes and no. There are definitely parts of the system that change over time, but a lot of what gets written in-house ends up being surprisingly basic/generic things like database mapping, job scheduling etc.. You'd be surprised how often there just isn't a publicly available implementation of the thing you need even when it really "should" be part of the standard library. > generally speaking they don't go bankrupt because of bad tech, though. It's usually imperfectly understood customer needs. No amount of perfect tech is going to stop that. I'm not convinced. The way bad tech generally manifests itself is that the company is slow to react to changing customer needs, because it takes too long to make changes to their systems. Having been on the inside, I've definitely seen things that you would think from the outside are business failures but had poor technical choices at the root of why they happened.
        marcus_holmes 6y ago
        I agree with everything you said :) Except I've seen (way, way) more failures from bad business choices than bad technical choices. I'm not saying it doesn't happen. But there's always the example of Twitter and the Fail Whale. That was almost-complete technical failure, and yet the business didn't fail because of it.
- krageon 6y ago
  If the formal specification is wrong, the component is still broken in practice. Your distinction is convenient as a vehicle for feeling better about your code (and I would argue you should feel good about writing such code), but it doesn't really have any bearing on the problem given the way you present it here.
  - lmm 6y ago
    > If the formal specification is wrong, the component is still broken in practice. What does it even mean for an internal specification to be "wrong"? The specification for the system can be wrong, and maybe the component wouldn't be useful in a correctly-specified system, but even then I think it's misleading to say the component is "broken".
- Talanes 6y ago
  >since the system will always have a part that must interact with humans Yes, such as the part that judges whether something is fallible or not.
- Joeri 6y ago
  All software runs on hardware and all hardware is fallible, ergo all software is fallible, even provably correct software. If you take a networked components view, then the assumption of failure must be baked into every network connection. That covers the vast majority of real world systems.
  - lmm 6y ago
    Not all hardware fails undetectably though, and certainly it's possible to separate failure of a component from failure of the network connection to that component. There are definitely parts of a system that need to handle failure, but I think that's different from saying that every component needs to be treated as fallible.

lmm 6y ago

On the contrary, there is guaranteed perfection: I can guarantee that they perfectly implement the given formal specification. I think we're in agreement that one can't produce a guaranteed-perfect system (since the system will always have a part that must interact with humans), but I don't think that actually supports the approach of treating every component as fallible.

marcus_holmes 6y ago
And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly?
- lmm 6y ago
  > And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. Not my experience; the system may need new components or need to rearrange the existing ones, but the components themselves don't become imperfect. Consider something like a prime factorization algorithm; maybe your system will change to the point where you don't need it, or need to extend it, but it continues to be perfect. > And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly? Tech companies go bankrupt all the time, so I think it's a stretch to say that commercial coding is working perfectly. Automating a sloppy human process in an equally sloppy way can certainly make you money, and maybe there's more money in doing that than in making perfect things, but we should at least acknowledge that there's an unexplored alternative here.
  - marcus_holmes 6y ago
    Your example of a component is kinda trivial: this sort of component is usually handled by a standard library and not developed in-house anyway. The stuff that's developed in-house is to service a customer need, and customer needs definitely change over time. > Tech companies go bankrupt all the time generally speaking they don't go bankrupt because of bad tech, though. It's usually imperfectly understood customer needs. No amount of perfect tech is going to stop that.
    - lmm 6y ago
      > this sort of component is usually handled by a standard library and not developed in-house anyway Currently yes; that's what I'm arguing could change. Every library has to be written somewhere, and at a lot of jobs I've found myself rewriting the same should-be-standard pieces again and again. > The stuff that's developed in-house is to service a customer need, and customer needs definitely change over time. Yes and no. There are definitely parts of the system that change over time, but a lot of what gets written in-house ends up being surprisingly basic/generic things like database mapping, job scheduling etc.. You'd be surprised how often there just isn't a publicly available implementation of the thing you need even when it really "should" be part of the standard library. > generally speaking they don't go bankrupt because of bad tech, though. It's usually imperfectly understood customer needs. No amount of perfect tech is going to stop that. I'm not convinced. The way bad tech generally manifests itself is that the company is slow to react to changing customer needs, because it takes too long to make changes to their systems. Having been on the inside, I've definitely seen things that you would think from the outside are business failures but had poor technical choices at the root of why they happened.
      - marcus_holmes 6y ago
        I agree with everything you said :) Except I've seen (way, way) more failures from bad business choices than bad technical choices. I'm not saying it doesn't happen. But there's always the example of Twitter and the Fail Whale. That was almost-complete technical failure, and yet the business didn't fail because of it.
krageon 6y ago
If the formal specification is wrong, the component is still broken in practice. Your distinction is convenient as a vehicle for feeling better about your code (and I would argue you should feel good about writing such code), but it doesn't really have any bearing on the problem given the way you present it here.
- lmm 6y ago
  > If the formal specification is wrong, the component is still broken in practice. What does it even mean for an internal specification to be "wrong"? The specification for the system can be wrong, and maybe the component wouldn't be useful in a correctly-specified system, but even then I think it's misleading to say the component is "broken".
Talanes 6y ago
>since the system will always have a part that must interact with humans Yes, such as the part that judges whether something is fallible or not.
Joeri 6y ago
All software runs on hardware and all hardware is fallible, ergo all software is fallible, even provably correct software. If you take a networked components view, then the assumption of failure must be baked into every network connection. That covers the vast majority of real world systems.
- lmm 6y ago
  Not all hardware fails undetectably though, and certainly it's possible to separate failure of a component from failure of the network connection to that component. There are definitely parts of a system that need to handle failure, but I think that's different from saying that every component needs to be treated as fallible.