The Expense Of Defense
The following “borrowed” snippet from a recent Steve Vinoski QCon talk describes the well worn technique of defensive programming:
Steve is right, no? He goes on to deftly point out the expenses of defensive programming:
Steve is right on the money again, no?
Erlang and the (utterly misnamed) Open Telecom Platform (OTP) were designed to obviate the need for the defensive programming “idiom” style of error detection and handling. The following Erlang/OTP features force programmers to address the unglamorous error detection/handling aspect of a design up front, instead of at the tail end of the project where it’s often considered a nuisance and a second class citizen:
Even in applications where error detection and handling is taken seriously upfront (safety-critical and high availability apps), the time to architect, design, code, and test the equivalent “homegrown” capabilities can equal or exceed the time to develop the app’s “fun” functionality. That is, unless you use Erlang.




Not that I’m going to argue against your premise (that the last 4 four Erlang/OTP features force programmers to deal with failure up front, and ergo obviate the need for “defensive programming”.) But you need to explain why, at least in some cursory form. Otherwise, it simply ends up with a flair of marketing-speak to it.
Point taken. All I can say is watch Steve’s talk. This post is just a capsulized summary of it.
Check this out for more information on quality practices (especially for agile methodologies) https://advancesereadings.blogspot.com/2018/10/quality-practices-in-agile-approaches.html