I guess you could talk in abstract terms about overbuilding a program by including a large amount of self-checking and possibly even error correction, but that's a bit of a stretch.

There is the whole "Don't Repeat Yourself" mantra.

I guess you could talk in abstract terms about overbuilding a program by including a large amount of self-checking and possibly even error correction, but that's a bit of a stretch.

That's a "bit of a stretch!?" That's how you should build anything that needs to be fault tolerant and robust. Maybe not a "large" amount, but enough, such that one error doesn't strand the user in a highly inconvenient situation. A key example: text messages that can crash Messages and leave the iPhone in a state where the user has to reboot. This has happened several times over the years! Apple programmers here on HN will shrug their shoulders and tell you that you have to let the process crash to ensure memory isn't corrupted. So why not have one process which can crash, working off a file acting as a queue, with another process monitoring attempts to process each element, and limiting the number of tries for each item on the queue? Apparently, that's too much trouble, and it's easier to just pooh-pooh people on social media.

Is it "redundant" to overbuild that part of the system? Yes. It's also much better for the user and for the company long term.

A good watchdog can be more valuable than bug free software.

Too much to ask of this generation of young programmers for something like messages on the iPhone. That's not a central feature of a smartphone anyways, right? Just let the user reboot.

There really isn't a concept of a bridge "failing gracefully". Any failure is a disaster. You can talk about a bridge being functional even after it becomes weakened by the elements or overloading or poor maintenance or some other condition, but that is another case of overbuilding.

I guess what I'm saying is that software and bridges are not very similar.