Karen,
Ah, once again I expressed myself poorly. Apologies to all; it was too
early in the morning to write (I'm on Pacific time).
As far as I'm concerned, being able to understand English is crucial
to meaningful interpretation of literature written in that language,
and being able to write and speak English with mastery is crucial to
effective self-expression as a critic. So English mastery is not
just "incidental and important", it is absolutely vital to the
success of the English major who aspires to more than mediocrity.
I did not mean that it was unimportant; indeed, I very strongly agree
with you. I mean that learning to express oneself is part of the focus
of a good English curriculum, but not the only one. You begin with
basic instruction in that (English/Rhetoric/Comp Lit 1A-1B-1C), and
then take an advanced course or two on that topic, and then continue
to hone your skills on courses like Shakespeare, Orwell, Milton,
Steinbeck, etc. But in those later courses the primary goal is not to
teach you clarity of expression; you are assumed to know how to
express yourself, and your skills improve as a result of constructive
criticism on what you write. And without the ability to express
yourself clearly, you can't discuss themes, characterizations, and
other aspects of English.
I think "secure" programming should be taught similarly. The primary
goal of learning to program is not to write "secure" programs. it is
to learn to write good programs, designed with the appropriate amount
of thought for the requirements and use. Someone specializing in
analysis of algorithms will probably not delve as deeply into software
engineering as someone specializing in that area, and I think that
requiring the algorithmist (is there such a word?) to know software
engineering at that level is inappropriate. *But* the algorithmist
should know how to write good code, and that's basically what we are
talking about.
I hope this clarifies what I meant. Learning to write good code is
incidental to one's studies in the sense that it is not the end goal,
but it is a necessary skill, and an important one, for all who program.
I feel the same way about software development. Writing software
sloppily results in software the functional objectives of which can
be subverted, either accidentally or intentionally. Such software
cannot be said to satisfy those objectives, and thus it must be seen
as failing, at least partially. It's only because we have accepted
such partial failure for as long as there has been software that our
standards for what we consider "goodness" for software are so poor.
Yep; if your requirements are poorly thought out, your software may
satisfy them, but it (almost certainly) won't do what it should. An
observation: it's not just in software that we accept partial
failures. Think of the last time you called a large company about a
problem :-).
Thanks, Karen!
Matt
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
