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.
An organization called The Pledge
of the Computing Professional (http://
Deep Accountability, Beyond even Liability
DOI: 10.1145/2507771.2507774