|P is for Practical|
Hm. I don't think the analogy holds very well.
If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear.
Not all fighting is done wearing NBC suits, and as sure as hell, not all training is. Sure, they train under those conditions so as to have experienced them, but I doubt it makes up more than 2 or 3% of their total.
The app I wrote to index the ingredients in my sisters recipes has hard coded credentials. If hackers crack it, I hope they enjoy her profiterole recipe as much as I do.
Choosing what to not to expend effort securing is as important as securing those things need it.
I'd be interested to hear your solution to the problem of supplying credentials to your DB apps? (Assuming that they can't be entered manually every time. Eg. Web apps?)
Doesn't affect me (note my handle). But from what I scanned on wikipedia, it probably rarely affects programmers in general, being aimed at corporate/legal processes rather than programming in general. I can see how for example it might be desirable to have an MIS suite provide hooks for auditing, but a good auditor would probably ignore that on the basis that they can be as bogus as the glossy company brochure.
Can't argue directly against what you say, but I see little correspondance between that and military practices and doctrines.
Then again, maybe I can argue against it. Requirements (and plans) are a fine starting point, but in all but the most repetitious of projects, they change. In common parlance, "the best laid plans of mice and men", or as the military would have it. "No plan survives the first encounter with the enemy."
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.