Re^2: Programming is combat

[DBAugie]

in reply to Re: Programming is combat
in thread Programming is combat

With respect to Train as you fight. That's another way of saying "practice makes perfect".

With respect, the complete maxim was taught to me as "Train as you fight, fight as you train." If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear. If your training prescribes that you must use a checklist to launch the alert fighter, then you must use the checklist when the klaxon goes off.

Relate this to programming:

• Your program, application, or system must pass security certification and accreditation. So don't build your work with hard-coded, plain-text passwords.
• Your work is going to have to meet the standards of Sarbanes-Oxley, plan for it and program accordingly.
• QA testers are going to evaluate your work against requirements, write code that satisfies requirements.

For those of you old enough to remember Sgt Rock and his Howlin' Commandos, "Nuff said"

[BrowserUk]

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.

Security.

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?)

Sarbanes-Oxley

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.

Requirements

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."