Defensive programming, YU so popular?

This term can have a lot of meanings. Everyone likes to attribute all the good thing to  a term they like while saying the bad things are misinterpretations or don't belong to that term altogether (Agile, anyone?). Usually when I hear people mentioning defensive coding, this is along the following lines, and this is what I take it for:

Defensive coding is doing everything possible to not make a fool of yourself.

Looks like people believe this is good thing, but to me it looks potentially very devious. This is like curing symptoms, not a problem. Covering your ass may be good for you in the short term, but definitely not for your team.

While defensive coding may contain often useful practices such as validating data coming from the external system, other more questionable practices tend to be associated to it ("check everything for null", "log all random things you can think of" ). To me, these are just Good practices, and Bad practices (in some context ofc.) - and defensive programming seems to contain practices from both of those sets.

Now there is another term, Offensive programming, which basically says, when you fail, scream as loud as you can, so that everyone else knows. This looks much more appealing to me. It looks like programming model Erlang advocates, where if worker fails, it does not attempt any tricks to recover, it just exits. It is responsibility of that worker's supervisor to decide what should be done in face of this failure.

There is but one place where defensive coding makes sense. And that place is most important of all in software. It is Production. Here, crashing the system is the worst thing that could possibly happen. It is often much worse than corrupting data, hiding the fact that something was not accomplished, etc. This is lying to your user. But if you lie rarely enough so that user doesn't notice it, this is better than telling this software is full of bugs by crashing and thus interrupting workflow.

So, defensive coding is bad for you (in the long term). It is bad for your team. It seems to be good for your business. Yet, I feel it is a sorry state of software development, where writing crap, and then defending against the crap you and your colleagues wrote is regarded as proper way of coding. Offensive coding raises the bar higher, and I want to believe it will be a way of doing things sometime in the future.

Sand castle in software

Consider what it means to write software following Open-Closed Principle (OCP).  You never modify existing code. If you need new functionality, you write a new code. Or maybe delete unused software units, to keep things clean.

In traditional statically-typed OO language, you would create class once, and never modify it again. What is the most important thing of that class? A name. You'd have to think really hard how to name this class, or else it will be the source of daily WTFs. I guess, that would be extremely hard.

The obvious benefit is that you never break anything that depends on your code. This enables you to write new code without fear that you may break something - which is very serious problem in software. This is my sand castle, a code that is as flexible as language allows it.

Now look at typical software. Each line of code is modified 10s if not 100s of times. Often changes have cascading effects. Code is full of unexpected behavior where names do not reflect the actual behavior, or even intent.

Why is it so hard to write code following OCP? I think, it is because we do not know what we are doing. Software we are supposed to create is beyond our comprehension. And so, we try creating random things, until something works as we thought it should. We may call this TDD, where we code to examples, and not full specification. On the other hand, there can be no specification other than code itself. The set of what -> how mappings is so big and with so many interesting options, there is no way we can choose The One, The Right option.