Communications of the ACM

Iam a Colorado licensed profes- sional engineer whose area of practice is software and who found no cause for disagree- mentwiththefirsthalfof Vinton G. Cerf’s “From the President” editorial “But Officer, I Was Only Programming at 100 Lines Per Hour!” (July 2013). The second half was another matter.

I concur with Cerf’s statement: “I
think many of you would agree that a
test or questionnaire is not likely to
provide assurance that a ‘certified pro-
fessional’ programmer’s work is free
of flaws...” to the delight of my liabil-
ity insurance provider, who repeatedly
admonishes me to avoid giving guar-
antees or warranties against errors in
my work. But “free of flaws” is an unre-
alistic expectation for any human be-
ing, even a licensed professional soft-
ware engineer. What my professional
license (together with the PE exam
and years of education and decades of
professional practice behind it) does
provide the public is assurance that my
work is relatively free of sophomoric
programming errors like buffer over-
flows, opportunities for SQL injection,
memory leaks, and race conditions
that infest the products of the more ju-
nior software developers I often must
clean up after. Yes, I still make mis-
takes, but I make them more rarely and
at a much higher level than the typical
“code monkey.”
Cerf also said “...it is very tempting
to imagine a balance between certifica-
tion and liability is worth some consid-
eration.” But if he were a patient on a
treatment table under the aimpoint
of a Therac- 25 [radiation therapy ma-
chine], where would he prefer that bal-
ance to be placed?

And “I take pride in believing that I, and many colleagues, see themselves as professional in spirit if not in name, and that we strive to deliver reliable code.” I take the same pride, but I must also contend with the “It ran okay once, so ship it!” mentality of the typical “Let the free market decide”-oriented manager.

Moreover, “So accepting liability
that the code won’t break or be broken
is a pretty scary thought.” Okay, what
if this entire discussion were about
bridges and structural engineers, not
code and software engineers? Pro-
fessional bridge designers somehow
manage to perform their work compe-
tently, accepting possible liability with-
out living their lives in constant fright.
They do so by virtue of careful design
through proven principles, incorporat-
ing lots of margin into their construc-
tion, and performing rigorous testing.
So it can and should be with profes-
sional software engineers.

And finally “We are so dependent on an increasing number of programs, large and small, it is difficult to believe the software profession will escape some kind of deep accountability in the future.” This is one of the best endorsements for software engineering licensure I have ever seen.

Lawrence stalla, Colorado Springs, CO

Vinton G. Cerf’s view (July 2013) of “registered” and “professional” designations (and lack of standardization) among U.S. software engineers made me wonder if a model could not be borrowed from an overseas friend, the British Computer Society (http:// www.bcs.org/). In the U.K., industry can often ignore BCS qualifications, but where safety concerns require a “responsible engineer,” suitably qualified, it is the BCS that sets the bar. The U.K. government has delegated issuing registered- and professional-type designations to bodies like BCS that belong to the U.K.’s Engineering Council ( http://www.engc.org.uk/). Though this practice may represent a vestige of a medieval guild system, “professionalism” in these terms would be judged instead by a jury of one’s peers. Yes, there is indeed the possibility of elitism (setting the bar high to exclude newcomers), but, at least where safety is concerned, better too high than too low.

Without knowing the details of
each U.S. state’s program, it is im-
possible to assess the complexity of
establishing a single standard, but
in the 1990s accreditation by the BCS
required a minimum level of work
experience, passing a written exam
(or exemption for certain college de-
grees), providing documentation to
demonstrate experience and career
progression beyond “entry level,” and
submitting to a panel interview.
It does not seem unrealistic for
ACM to help define minimum educa-
tion and experience criteria for a “re-
sponsible engineer” accreditation in
IT; ACM is after all an organization
of IT experts and practitioners, many
of whom (I would hope) to whom it
would apply. ACM could administer
the process itself, with lobbying to
have each state recognize it (perhaps
eventually a de facto national, or even
global, standard); alternatively, it
could be provided more simply as rec-
ommended guidelines.
stephen Garriga, blairsville, GA

Vinton G. Cerf (July 2013) discussed professional licensure, a controversial topic in the computing community. While our aim here is not to explore the larger question of licensure, we would like to suggest the community would benefit from practices that promote professional awareness and self-accountability, the way the Hippocratic Oath promotes self-accountability among medical doctors beginning their careers in service to society. Engineers in the U.S. have long used an obligation ceremony sponsored by the Order of the Engineer (http://www. order-of-the-engineer.org/) in which graduating seniors pledge to uphold the standards and dignity of the profession through an oath including parts of the Canon of Ethics of major international engineering societies. The oath and the ceremony are not tied to the licensure of engineers in any way but are meant to inspire young professionals toward a consciousness of the profession and remind older professionals of their responsibility receiving, welcoming, and supporting them.