The first time I heard of what I now call the No Paranoia Rule was in the following comment by Luke Gorrie on LtU:
"Oh my, what if Luke installed an exception handler that ROT13 encoded every string on the heap, then how would Jane debug her programs?"I hear that early on, people opposed subroutines for similar reasons. And of course, macros are frequently criticised for their potential of wreaking havoc.
But that's where the No Paranoia Rule comes into play. Stop being paranoid, and don't discount language features for their potentially devastating effect.
As Luke further states,
This [being paranoid] is not the way to illumination.(Clemens A. Szyperski coined the term No Paranoia Rule.)
1 comment:
It seems to be a sub-part of the more general, fundamental, rule of any engineering design: you can only design for what you *know*.
You cannot design for what you don't know -- it is not design, it is not rational, or informed, it is just guessing, or random gambling. Engineering design is essentially about leveraging some model or rational structure to step forward with some sureness.
You can still design for what you can reasonably expect: indeed, that is really just a vaguer area of the known. But anything suggested by paranoia is obviously not reasonable.
(. . . now, you can *evolve* with guessing or random gambling, but that is a another, if adjacent, subject . . .)
Post a Comment