Well Designed Failure

So last night, while I was out for a social gathering and my partner was out of town, someone appears to have tried to break into our house. They did a moderately good job of disassembling the door handle on our front door, but didn't get any further than that, thanks to the deadbolt lock on the door and the two loud dogs in their beds next to the door. Last night I was pretty upset about it, and I was also being critical of the door handle, but the more I think about it the more I think I'm wrong. I am beginning to think that the door handle itself was really quite brilliantly designed -- it was designed not just to work, but to fail gracefully.

When I got home I found the front door handle had been jimmied somehow, and was loose in the door itself; in addition, the interior handle part had come completely off the door. So I was mildly upset about this, thinking that first, someone had tried to break into my house, and second, that I would have to replace the door handle (at 9PM on a Saturday, which did not sound like the best time to go shopping for door hardware). But actually the door handle did its job brilliantly, and here's why I think that:

1. Most importantly, the alleged intruders were unable to get into the house. So when the integrity of the handle failed, it still managed (with backup from the deadbolt and the dogs) to accomplish one of its two main design goals: keeping the door shut (the other we'll get to in a subsequent point).
2. After the alleged intruders departed, when I arrived home I was still able to gain entrance to the house via the front door. This, by the bye, is the other main design goal of the handle: allowing the door to be opened. 
3. This allowed the handle to accomplish another design goal, which is often ignored: it failed securely, and kept functioning even in failure mode. This was accomplished by various parts all acting in concert even in failure mode (including the length of the haft of the knob, the length and placement of the screws, and the design of the latch mechanism itself). 
4. In addition, after the failure mode, it was relatively easy to return the handle to full working order -- the recovery process was relatively simple and not time-consuming.
5. It did all this without any damage to the door itself, the deadbolt, or even the handle and knob mechanisms, meaning it was designed for robustness in its application.

So here we have a really, really good example of designers not just designing for the stated goals, but also taking into account failure and recovery modes. This is also an example of how even old, complicated tech (and a modern lock/latch is pretty complicated) can be designed to fail gracefully and with minimal agita to the user. From an Operational perspective, this handle may be a nearly-perfect design: secure, robust, graceful in failure, silent in normal operating modes, and easy to recover. It is a benefit of having had door knobs and locking latches for a couple of hundred years, including the last 50 or so when CAD methods have allowed for much finer tolerances and more rapid iteration of incremental improvements.

To sum this all up: if you, as a software designer, think not just about the stated goals but about how the tool you're building will be used (and broken by users), you'll have not just a better starting point, but also a better idea of what you'll need to iterate towards for improvement.