Hacker News Reader

Comment by Arainach | Hacker News Reader

>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.

View on HN

That'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.

Manufacturers 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.

I 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.

You 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.

Messing 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.

> 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.

Earlier 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.

Reply on news.ycombinator.com