Sign In

Communications of the ACM

From the president

'But Officer, I Was Only Programming at 100 Lines Per Hour!'

Vinton G. Cerf

ACM Past President and Google Inc. Vice President and Chief Internet Evangelist Vinton G. Cerf

It's summer and I thought it might be worth stirring up some thunder and lightning with another controversial topic. As many readers know, there is a category of engineer that is sometimes called "Registered" or "Professional." This is not to say that most engineers, registered or not, are not professionals, but it turns out the terms are specifically and legally meaningful. While the procedures and practices vary from state to state in the U.S. (and elsewhere), there is often an exam to pass or at least a questionnaire to fill out and a registration step of some kind that authorizes the engineer to label herself or himself as "Professional."

Among the privileges granted to professional engineers is the right to undertake certain kinds of projects, to certify designs, to oversee design and implementation, and so on. These projects are often large and potentially involved in what could be life-threatening conditions of use. Examples include designs for bridges, buildings, aircraft, roads, railways, levees, dams, and hydroelectric- and nuclear power-generation systems. Indeed, some medical devices may require some oversight and certification for use. The reason for this attention to qualification and certification is obvious: public safety is involved one way or another.

I am sure some of you will have figured out where I am going with this. I think we would all agree that software (and its underlying hardware) is increasingly a part of our daily lives in large and small measure. The programs that control the car engine, the controllers for appliances (like water heaters, heating and cooling systems, washers and dryers, ovens, and other fairly large-scale and power-consuming devices), and financial management and trading systems are potentially hazardous if they have errors that lead to excessive load, mechanical malfunction, unexpected behaviors, and so on.

One wonders whether legislative bodies and perhaps insurance companies will reach conclusions that suggest software designers and implementers should have imposed upon themselves similar regulatory requirements, authorizations, and certifications. I once made a living writing or designing software for IBM, MCI, and the USG, among others. Some of that software or at least its design was pretty widely used (for example, MCI Mail, the Internet, time-sharing services, among others). With the increasing incidence of hacking, denial-of-service attacks, penetration, malware infection, and botnet creation, one might be tempted to argue that software developers should bear more responsibility for the behavior of their software.

I think many of you would agree that a test or questionnaire is not likely to provide assurance that a "certified professional" programmer's work is free of flaws. I am not even sure what sort of test could be proposed that would provide such assurance. But it is very tempting to imagine a balance between certification and liability is worth some consideration. How can we provide motivation to a well-intended programmer to reduce the risk to users of his or her software? What incentives would companies that create software or market it have to reduce liability by appointing a "certified software engineer" to take responsibility for the safety and reliability of the software?

Plainly one would expect that any kind of licensing would have to produce some kind of safe harbor for both the employer and the employee. Perhaps reduction of insurance premiums?

In the past, I have had no problem convincing myself that the idea of professional licensing along these lines is a dumb idea. But we do have certification for users or maintainers of certain kinds of software or equipment (for example, for Microsoft software, Cisco equipment). 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 also believe that no one really knows how to write absolutely bug-free code, especially if the input and operating state space is innumerably large. So accepting liability that the code won't break or be broken is a pretty scary thought.

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. We many avoid this in the near term, but I am not so sure in the long term.

OK, I have my cast-iron three-piece suit in place...What do you think?


©2013 ACM  0001-0782/13/07

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2013 ACM, Inc.



It's economically inviable. It may have been possible when software was less pervasive and less complex, but today the cost of even the smallest project would skyrocket. Just imagine not being able to use the tools and libraries made by unlicensed third parties.

Robert Abbott

I have been developing computer software and engineering large computer systems for over 25 years, including the critical types of systems mentioned in this article. During my career, I have continued my education and have also picked up many vendor certifications to support my practice. Many people that I work with, however, do not have any formal education in the field. Some are exceptional programmers with a good grasp of the programming methodology. Some even practice portions of the software engineering discipline. Many, though, possess only marginal "coding" skills. With the proper oversight and sufficient specifications, these teams can deliver excellent products. If I were to require key positions to not only hold computer science degrees but also professional certifications, I would never be able to assemble teams large enough to deliver the kinds of systems that my group builds. For someone already working in the field to go back and complete a Bachelor's- or Master's- level degree in software engineering, followed by a comprehensive exam much like the ones taken for the professional engineer designation after several years of professional experience seems onerous and expensive. I fear that introducing this kind of requirement could cause our profession to lose a significant number of qualified practitioners. Until we are able to increase the number of graduates of software engineering, computer science, and other technology programs I believe it will be infeasible to implement such a required designation for our profession.


I think that the issue is not so much certification as licensing by an appropriate body, usually self-governing but established by law.

Why are "professional engineers" licensed at all? Licences give the public a sense of comfort not just by ensuring a minimal standard (as set by the governing body) but also by yoking the licensee to liability for failure to deliver to those standards. However, it also limits the liability of the licensee, who can then argue in court that the allegedly faulty services were rendered according to appropriate standards (and this goes a long way to reducing damages). All licensed engineers carry liability insurance, by the way.

A question is whether a licensed practioner would always be required. Clearly not -- just as licensed engineers are not always needed for certain projects. I think that some sort of licensing is coming because of the liability issue alone.

The above is not a value judgement on practitioners or engineers.

CACM Administrator

The following letter was published in the Letters to the Editor in the November 2013 CACM (
--CACM Administrator

In response to Vinton G. Cerf's editorial "But Officer, I Was Only Programming at 100 Lines Per Hour!" (July 2013), I would like to add that as long as physical damage is caused by machines, vehicles, and medical devices, their manufacturers can be held liable, whether or not a software problem is the root cause. If damage is due to addon software (such as an app running down the batteries of a navigation device or an app crashing a car by interfering with car-to-car communication), the software manufacturer could be liable. When liability insurance premiums can be lowered by demonstrating professional qualifications, the option of acquiring personal or staff certification will be embraced by software development professionals, though, perhaps, not enthusiastically.

Ulf Kurella
Regensburg, Germany

The following letter was published in the Letters to the Editor in the November 2013 CACM (
--CACM Administrator

I view myself as a "formal methodist" in the professional world of software engineering, though reality is less grand. I "manage" the application of formal methods and also (try to) sell the formal-methods concept to upper management in my organization, in part by quoting Vinton G. Cerf's fellow Turing-Award laureates E.W. Dijkstra and C.A.R. Hoare, in addition to A.M. Turing himself. (It is, of course, no reflection on these immortals that the success of my pitch is modest at best.) I also quote Cerf, context-free (July 2013): "[N]o one really knows how to write absolutely bug-free code..." and repeat the same disclaimer regarding my own (lack of) impact.

Rumor has it IEEE will soon adopt a professional-engineerlicenseinsoftware engineering. I hold its purported precursor, the IEEE Certified Software Development Professional (, but do not recall whether I answered the single formal-methods question, out of 180 questions, correctly in 2009 when I took and apparently passed the test.

The back-and-forth between ACM and IEEE regarding licensure and certification is interesting and probably necessary. I thank Cerf for eschewing any shrillness while providing much-appreciated humor.

George Hacken
Wayne, NJ

CACM Administrator

The following letter was published in the Letters to the Editor (pp. 8-9) in the October 2013 CACM (
--CACM Administrator

I am a Colorado licensed professional engineer whose area of practice is software and who found no cause for disagreement with the first half of 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 professional' programmer's work is free of flaws..." to the delight of my liability insurance provider, who repeatedly admonishes me to avoid giving guarantees or warranties against errors in my work. But "free of flaws" is an unrealistic expectation for any human being, even a licensed professional software 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 overflows, opportunities for SQL injection, memory leaks, and race conditions that infest the products of the more junior software developers I often must clean up after. Yes, I still make mistakes, but I make them more rarely and at a much higher level than the typical "code monkey."

Cerf also said " is very tempting to imagine a balance between certification and liability is worth some consideration." But if he were a patient on a treatment table under the aimpoint of a Therac-25 [radiation therapy machine], where would he prefer that balance 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? Professional bridge designers somehow manage to perform their work competently, accepting possible liability without living their lives in constant fright. They do so by virtue of careful design through proven principles, incorporating lots of margin into their construction, and performing rigorous testing. So it can and should be with professional 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

CACM Administrator

The following letter was published in the Letters to the Editor (pp. 8-9) in the October 2013 CACM (
--CACM Administrator

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 ( 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 ( 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 impossible 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 degrees), 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 education and experience criteria for a "responsible 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 recommended guidelines.

Stephen Garriga
Blairsville, GA

CACM Administrator

The following letter was published in the Letters to the Editor (pp. 8-9) in the October 2013 CACM (
--CACM Administrator

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 ( 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 ( founded in 2010 at Ohio Northern University and the University of South Florida aims to recognize graduates of computing programs as professionals in service to society, as the Order of the Engineer does with graduates of U.S. engineering programs. Today, 26 U.S.-based institutions conduct The Pledge rite-of-passage ceremony as part of their graduation activities. Graduates taking The Pledge sign a certificate both publicly and in the presence of their peers and are then presented a pin ( that serves as an additional reminder of their commitment to self-accountability through ethical and moral behavior within the profession.

The Pledge has been endorsed by the Order of the Engineer, the ACM Special Interest Group on Computers and Society (, and the ACM Committee on Professional Ethics. For more, please see or contact any of us directly.

Ken Christensen
Tampa, FL
John K. Estell
Ada, OH
Ben Kuperman
Oberlin, OH



I appreciate very much these readers' thoughtful comments and the points they make. Some of the best programmers I have known have lacked formal training, having come by their expertise through field experience. However, those points persuade me an effort might be made to say something about minimum curriculum and performance, if not an actual examination like the bar exam for lawyers or board certification for medical professionals. Evidence of continued education might also give credibility to the credentials of a professional software engineer. While it may not be inevitable, it seems sufficiently plausible that some kind of licensing will be proposed, in which case ACM might contribute positively to the development of credible course content and perhaps also testing standards for professional software engineers.

Vinton G. Cerf
ACM President

CACM Administrator

The following letter was published in the Letters to the Editor (pp. 8-9) in the September 2013 CACM (
--CACM Administrator

Vinton G. Cerf's "From the President" editorial "'But Officer, I was Only Programming at 100 Lines Per Hour!'" (July 2013) raised the issue of how to license "software designers and implementers." The state of Texas first licensed software engineers in 1998. ACM pulled out of the Texas software engineering licensing effort in 1999, while the IEEE continued on by itself. Texas and many other states now offer licensing through the "Principles and Practices Exam of Software Engineering" exam ( Cerf implied licensing consists solely of an exam. However, typical state licensing requirements include a degree from an accredited program, the fundamentals of engineering exam, four years of documented engineering practice, the professional engineer exam in the area of practice, and three letters of recommendation from licensed professional engineers familiar with the candidate's engineering practice. If such credentials are not sufficient to formally determine competency, what is?

Duncan M. (Hank) Walker
College Station, TX



I did not intend to imply that licensing consisted solely of an exam but rather assumed it would likely be in addition to any other evidence of training and competence. It would be of interest to know what has been the outcome of the Texas licensing program. In particular, under what circumstances might work opportunities be restricted to persons holding such a license. Can Walker cite other states with similar programs? Are there conditions under which the license is a "must have" as opposed to a "nice to have" insignia in the state of Texas?

Vinton G. Cerf
ACM President

Displaying all 8 comments