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!

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.

Reply via email to