That's a good argument for science, but a putative engineering discipline must be something that actual, real humans can perform, or we are forced to admit that the standards should be raised and too many people are currently trying to do the engineering.

That's why I point out that it applies to all design philosophies I encounter. I hate to be elitist as a general principle, but I regretfully must come to the conclusion there's a lot of programmers programming who really shouldn't be, based on the evidence.

It may also simply be a communication problem. Here's another example, that I'm more familiar with. In engineering physics textbooks, most treatments of AC circuits are very confusing for the student. At that stage of their careers, we use sin and cos as opposed to a more complex-exponential treatment.

Now, the textbooks all tend to make the same basic treatment. When I was a prof, since I am a "challenged" reader, rather than try to wade through the mess in the book I set apart my own derivation. When I was finished, I naturally had to tie it back into what the textbook was saying so that the students had something to hang onto. But when I went to make the link, what I found actually startled me.

In their derivations, all of the authors made the same phase-shift of the source signals and never mentioned it. I couldn't believe it, and tried to figure out where my mistake was. But I didn't make a mistake.

In a section of the book that didn't really figure in to the future of the students' education--could be easily skipped, in fact, because anybody that needed it would do it over "correctly" anyway-- everybody just sort of did what everybody else did.

Perhaps that's what is going on in OOP. I'm not trained as a programmer--I just pick up what I can. So I'm sure that most of my code is laughable, and I do sometimes paint myself into a corner. But I find that I am sometimes surprised by how easy it is to make big changes if I've encapsulated things. Just my personal experience.