FailQuicklyAndObviously

Don't design things which cover up failure, design for failure to be obvious (and catastrophic). That way it reveals itself earlier and can be fixed faster.

Examples :

• materials which show wear on your house. When it looks worn, it is change it. Contrasted with materials which appear new even when underneath they're rotting away.

• bad use of exceptions in programming can often hide failure. Equally, functions get passed two args a and b and divide one by the other. If b is 0, this fails. There's often a temptation to trap this, to prevent failure. But inside the function, you don't know the context the function was called in, or what to do. You could raise an exception to be caught elsewhere. But in fact, this simply opens the possibility of another part of the program prematurely catching the error and hiding it. Better to leave the program to crash. That way when it happens, you can debug the context and find why it's getting this bad arg.

You might find Crash Only Software an interesting perspective on this sort of design – AdrianHoward

Basically like ErlangErrorHandling

See also :

• BeauSage

• OnLaziness

• SoftwareLessonsFromHowBuildingsLearn