> Making software secure should be a requirement of the development > process. I've had the priviledge to have worked on some very good > projects where the managers emphasised security in the beginning of > the projects life cycle since it was a requirement of the client.
Making software secure absolutely should be part of the development lifecycle, and as early as possible, too. My overall point was that if you talk to the people who really care about usability (as distinguished from just "features") you will hear very similar frustrations about their ability to get what they consider true usability requirements into the end product. So in terms of learning from other communities I think as opposed to beating our heads against the same wall it can be helpful to learn from another *-ility community to see what ways they have tried successfully/unsuccessfully to increase the quality in software from their viewpoint. My suggestion is that the problem is not just software security but run a little deeper to the main problem of software quality of which security is one of the factors (albeit an important one). So what are the common threads amongst usability and security? For examples it is interesting to note that both communities seem to value early involvement in the development lifecycle and striving for simplicity in design. Software security does not need more barriers, but to the extent that we can find allies with similar goals and issues from other communities (could be *-ilitity, business, compliance, legal btw) and collaborate with them to communicate the value of quality, then our chances for shipping better software are increased. -gp "Societies have invested more than a trillion dollars in software and have grotesquely enriched minimally competent software producers whose marketing skills far exceed their programming skills. Despite this enormous long-run investment in software, economists were unable to detect overall gains in economic productivity from information technology until perhaps the mid-1990s or later; the economist Robert Solow once remarked that computers showed up everywhere except in productivity statistics. Quality may sometimes be the happy by-product of competition. The lack of competition for the PC operating system and key applications has reduced the quality and the possibilities for the user interface. There is no need on our interface for a visible OS, visible applications, or for turning the OS and browsers and e-mail programs into marketing experiences. None of this stuff appeared on the original graphical user interface designed by Xerox PARC. That interface consisted almost entirely of documents--which are, after all, what users care about. Vigorous competition might well have led to distinctly better PC interfaces--without computer administrative debris, without operating system imperialism, without unwanted marketing experiences--compared to what we have now on Windows and Mac. Today nearly all PC software "competition" is merely between the old release and the new release of the same damn product. It is hard to imagine a more perversely sluggish incentive system for quality. Indeed, under such a system, the optimal economic strategy for market leaders may well be the production and distribution of buggy software, for the real money is in the updates and later releases. One of Philip Greenspun's points in his introductory programming course at MIT is that the one-semester course can enable students to create the programming equivalent of the amazon, eBay, or photo.net websites. So why it is so hard to get it right the first time? Or at least by the Release 8.06th time? See Software Engineering for Internet Applications (MIT 6.171) at http://philip.greenspun.com/teaching/one-term-web -- Edward Tufte, June 28, 2002 " http://www.edwardtufte.com/bboard/q-and-a-fetch-msg? msg_id=0000D8&topic_id=1&topic=Ask%20E%2eT%2e