Re: Interesting article ZDNet re informal software development quality

["Carl G. Alphonce" <alphonce () cse Buffalo EDU>]

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