What is written here is sometimes wrong, sometimes over-simplifies what is needed to build robust systems. If look at the list: 7/ You absolutely must remove

What is written here is sometimes wrong, sometimes over-simplifies what is needed to build robust systems. If look at the list: 7/ You absolutely must remove people who demonstrate they are not skilled for the role assigned to them in the system. Role / skill match is one of the first thing an assessor will look at. 6/ Documenting best practice is the only way we have to ensure a system will survive the demise of its creators. This is captured in a quality management system and again, will be scrutinized by an assessor. Check EN 50126 in railway (my field) 5/ This is ridiculous. Failure is the greatest teacher. It shows us where we failed and by analyzing failures we progress. Dismissing this is hubris. Many safety techniques have been introduced due to prior incidents (e.g. collision avoidance systems in planes, etc) 4/ Procedures are not meant to make anyone feel clever, but ensure robust / safe operation. While you can wish procedures to be made as smooth as possible by automation, you can’t just ignore them. Some procedures are simple and save lives routinely (e.g. stop at red when driving your car) 3/ Risks must be analyzed, quantified and mitigated. But when a risk can be eliminated entirely at acceptable cost, it should. EN 50126 is again a good read here. 2/ Simplicity is said to be achieved when you cannot remove anything. But it is not necessarily exempt of complexity. Saying something complex is inherently more robust does not make sense. The simpler a system, the better it can be understood by others and thus made more robust by peer review and contributions. 1/ This is not black and white. Sometimes redundancy is needed, sometimes it’s a rotten idea. Reliability (MTBF, MTTR, MTBSF) calculations are needed to determine the right balance.