[thesalsabear]

While this is a question of what the court should presume, should we ask what does a software developer presume or doesn’t:

A software developer would presume proper working of software if it is being used widely. I would presume JavaSDK or pandas library to be working properly, inspite of the fact that pandas that 3.5K bugs file on GitHub issues. But if I am thinking about integration a less known library or using a less known software I am less confident about its working.

[nine_k]

Given enough eyeballs, all bugs are shallow. As such, they are complained about by thousands of people, for years.

Less ironically, one can expect widely used features of widely used software to have been tested in realistic conditions so whatever bugs there might be are at least known. But it takes an insane amount of testing to cover the phase space even of a moderately complex piece of software: look how large is the test suite of SQLite.

Apparently the only working approach to less buggy software is to compose software from small, self-contained,isolated, well-understood parts, so that you can reason about the whole more easily. This is the philosophy behind the original Unix. This is the philosophy behind functional programming. This is partly the philosophy behind actor systems (even though reasoning about async interactions is harder). I expect to see more and more of these in practice.

[makeitdouble]

Yes. Bugs are there, but either they're shallow, well known and worked around, or have low impact for the majority of people using them.

The epitome of that was utf-8 support for a long time: there were a huge number of bugs, but alaphabet based languages would be mostly ok, and most devs would know it was a mess and work around that as much as they can.

To me one should expect any software to be broken in numerous ways, and take the time to check what happens around the area that are critical to them.

> compose software from small, self-contained,isolated, well-understood parts, so that you can reason about the whole more easily.

That looks awfully close to the micro-service approach as well. The approach can be good, but it still gives me pause.