[jwatte]

"Defensive Programming is a well-regarded technique in software engineering."

No.

No, it's not.

Fail early, fail fast, crash loudly, and then react. That, plus deep validation testing, is how you build robust systems. Trying to soldier on when things are wrong just propagates bad data and bad behaviour into a larger surface area that needs cleanup.

Assert everything, even in production. Capture all failures and action each one (turn a 500 crash into a validation failure 400, etc)

Monitor all logs for unexpected/new anomalies.

Be vigilant around testing. Failure cases are part of the spec, too!

That's how robust systems are really built!

[dsp1234]

In the section that you mention, the author of the article is comparing techniques for dealing with local function calls vs microservices over the network, specifically in regards to the fallacy that the network is reliable.

With respect to local functions, I think most developers would agree that defensive programming is well-regarded (otherwise this browser would crash on half the web pages I visit).

With respect to distributed system, basically the rest of that section agrees with you, concluding with:

"In fact, using a middleware or services layer that forces engineers to think about their resilience strategies in the face of network failures is quite valuable. After all, the engineers are the best people to decide how a system should behave when things go wrong."

So you basically just re-iterated what the author wrote.

[HillRat]

Also, isn't Hystrix a good example of defensive programming in a services environment? Seems to work well for Netflix.

[robotresearcher]

Asserting everything is defensive programming. You don't have to survive errors to be defensive. The defence comes from noticing them.