Could you give example of component that is 100% correct? I feel that even components can be 100% correct only within context, e.g. within ideal automaton under expected limitations and we don't have that.
While idea to construct everything from components overall seem to work better than to build monoliths quite often (Space X vs NASA, Linux vs many other OSes) but not always (e.g. SQLite).
> Could you give example of component that is 100% correct? I feel that even components can be 100% correct only within context, e.g. within ideal automaton under expected limitations and we don't have that.
Verified* instances in safe Idris. Of course GIGO is still valid and failures in lower-level components (such as a processor just not behaving as specified) can cause failures in higher-level components, but it's simply impossible for there to be a failure in that component itself - any observed failure will necessarily be the result of a lower-level failure.
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.
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.
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.
> 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".
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.
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.
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?
> 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.
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.
> 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.
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.
Well, your argument would only apply to software which operating contexts are not known to the developers ahead of its release. Is it the case for every piece of software? I’d argue not. Most of the times, you know what to expect . And you can always put up some guards to ensure it fails gracefully.
So expected limitations in your cases is "known to the developers ahead of its release", but what happens with the software after release, e.g. after 10 iterations or 2 years or 10 years? What happens if your product from 10s of users grows to 1000s of users, millions of users? What happens when new functionality must be added and it collides with the existing one in multiple points?
You can and you must do your best, but you can't do everything - you must choose what is your sacrifice.
While idea to construct everything from components overall seem to work better than to build monoliths quite often (Space X vs NASA, Linux vs many other OSes) but not always (e.g. SQLite).