Secure Coding mailing list archives
Re: Interesting article ZDNet re informal software development quality
From: "Carl G. Alphonce" <alphonce () cse Buffalo EDU>
Date: Thu, 08 Jan 2004 16:03:31 +0000
on Wednesday January 7, 2004, Crispin Cowan wrote:
Alun Jones wrote:I hate to say it, but maybe it's time for developers to become accredited professionals, and for employers to insist on getting qualified developers, rather than picking anyone who's read a book on C.What would they be accredited of? Professional civil engineers are accredited of knowing ... None of this can work for "professional" software "engineers". There is no cookbook for reliable software. A programmer can follow all of the best practices, and still produce software that crashes & burns. Worse, there is controversy over what the "best" practices are, so you can't even hold a programmer accountable to a single procedure.
This gets back to the question I asked several weeks ago (to which I received many useful and interesting replies - thanks to all) asking what students should be taught in the first year and beyond to help them write more secure code. I think there are issues which software developers must be aware of and techniques they must be proficient with in order to develop secure software. Whether a "stamp of approval" should come from a certification course or successful completion of an accredited degree program is a good question. Members of some professions ("self-regulating professions" I think they're called) must be members of colleges in order to practice. These colleges have the authority to take action against members who do not practice in accordance with accepted procedures, of who have had complaints lodged against them. Members must typically also stay current by completing some number of continuing education hours every year. Members who do not follow accepted procedures (e.g. have not tested their code, have not done code reviews) can have their licenses suspended or revoked. Clearly there is no magic one-size fits all solution, but having the ability to weed out consistently incompetent people may be one of many mechanisms that could be used to improve the quality of software. Of course, there is also the risk that something along these lines becomes a costly and toothless bureaucracy. Perhaps it is better suited to a subset of developers, such as those working on safety-critical systems (are there any requirements for developers working on such systems now?) -- Carl Alphonce email: [EMAIL PROTECTED] Dept of Computer Science and Engineering phone: (716) 645-3180 x115 University at Buffalo fax: (716) 645-3464 Buffalo, NY 14260-2000 http://www.cse.buffalo.edu/~alphonce
Current thread:
- RE: Interesting article ZDNet re informal software development quality, (continued)
- RE: Interesting article ZDNet re informal software development quality Alun Jones (Jan 07)
- Re: Interesting article ZDNet re informal software development quality Crispin Cowan (Jan 08)
- Re: Interesting article ZDNet re informal software development quality George Capehart (Jan 08)
- RE: Interesting article ZDNet re informal software development quality Alun Jones (Jan 08)
- Re: Interesting article ZDNet re informal software development quality George Capehart (Jan 08)
- Re: Interesting article ZDNet re informal software development quality Bruce Ediger (Jan 09)
- Re: Interesting article ZDNet re informal software development quality Brian Utterback (Jan 09)
- Re: Interesting article ZDNet re informal software development quality George Capehart (Jan 10)
- Re: Interesting article ZDNet re informal software development quality Brian Hetrick (Jan 07)
- RE: Interesting article ZDNet re informal software development quality David Crocker (Jan 06)
- Re: Interesting article ZDNet re informal software development quality Crispin Cowan (Jan 09)