4 ms·
>A design may include other certified hardware or software designs as components or layers, but liability for failures in a design remains fully with that desig
by Arainach 4y ago
>A design may include other certified hardware or software designs as components or layers, but liability for failures in a design remains fully with that design’s engineer of record; it cannot legally be passed through to its components’ engineer of record.
How can this ever make sense? So if a bridge fails because the supplier of rebar messed up the heat treatment, the bridge designer is liable? What this means in practice is no systems larger than those that can be practically understood by a single person - possibly from atoms and first principles - and no systems that can't be audited by one person in time shorter than the project would become irrelevant.
- EvanAnderson 4y agoManufacturers independently test raw materials coming from suppliers, sub-assemblies from contract manufacturers, etc. If we're going to consider software a "supply chain" it seems like a good idea to subject it to the same rigor. Speaking about real world manufacturing: I'm ignorant of the details but I would assume there's some construct in law or regulation for liability to be assigned back "up the chain" if due diligence in statistically sound testing "down the chain" is demonstrated.
- velcrovan 4y agoEarlier on it says “If a system deviates from its design, the contractor becomes liable for any such failure, whether related to the specific deviation or not.” And yes, you’re probably right that systems would have to be much more legible. I’m interested in imagining what that tech landscape would look like.
- abeppu 4y ago> liability for failures in a design remains fully with that design’s engineer of record > So if a bridge fails because the supplier of rebar messed up the heat treatment Is a failure of a bridge necessarily a failure in a design? Or do we distinguish between a physical project which uses a design from the design itself? If the materials were bad, whether or not the construction team had some responsibility to re-test those materials prior to using them (is this common?), it doesn't seem like evidence that the _design_ failed.
- AdamH12113 4y agoMessing up the heat treatment isn't a design failure, it's a construction failure. The design specifies acceptable parameters for the rebar. If the rebar is within those parameters but the bridge fails because the parameters were wrong, the designer is responsible. If the rebar was out of the specified parameters, the contractor is responsible. If I'm reading the article right, "design" would encompass interaction boundaries as well as things like CPU/memory requirements, information storage, and security.
- linkdink 4y agoThat's already how the world works. The bridge design company takes out insurance reflecting their liability. If something happens, they pay. If their supplier messed up a component, they can turn around and sue the supplier. Licensed professional engineers are already personally responsible for their projects to some extent, which can be very big and complicated. They're covered by professional liability insurance. All of this has been around for a long time.
- atoav 4y agoI mean if something I design as an electrical engineer kills people because it was faulty, it doesn't matter if the components sucked, because it is my responsibility to choose components that do not suck and to test them as well. As someone who also does web development I know that this degree of liability is completely foreign to a big part of the software world, and IMO this is an part of the reason software still sucks big time in terms of efficiency, reliabilty, safety and security. Because if you have to think about liability suddenly the simple rugged system starts to look lot more attractive.
- pdimitar 4y agoYou should keep in mind that a good chunk of programmers absolutely want to invest further into safety but are never ever allowed to do so by management. At one point you learn to shrug it off and make notes to maybe revisit the code one day and fix the dangling bits. Alas, that time almost never comes because people get demotivated and leave the companies. Which is very normal.