Home → Magazine Archive → July 2014 (Vol. 57, No. 7) → Licensing Professional Software Engineers: Seize the... → Full Text

Licensing Professional Software Engineers: Seize the Opportunity

By Phillip A. Laplante

Communications of the ACM, Vol. 57 No. 7, Pages 38-40
10.1145/2618111

[article image]

Save PDF

In his July 2013 Communications column, ACM President Vint Cerf revisited the controversy of licensing professional software engineers in the U.S. This issue has been one that divides the profession since reasonable cases can be made both pro and con. Officially, ACM has opposed and IEEE has supported such licensure. Even within both organizations, though, there is substantial support and opposition.1,2,3,5 I think President Cerf was right in suggesting that, because of the dramatic growth in interacting software in both devices and in applications that significantly impact peoples' lives, and more importantly, because licensing is happening, we have reached a tipping point.

I am a longtime (more than 25 years) member of both the ACM and IEEE and I chair the committee that developed and maintains the licensing exam for use by the states. I have also been involved in helping states' licensing boards deal with the issues of operationalizing the licensing process. Even so, I have been no longtime supporter of licensing software engineersI wrote against it as recently as 2005, noting the many challenges.5 But two things changed my mind. The first was a book about the tumultuous history of implementing medical licensing in the U.S.8a history that in many ways parallels that for licensing software engineers. The second involved deep conversations with Dennis Frailey and Don Bagert, who have written in support of licensing certain software engineers for many years. I became convinced it was necessary to move forward with the licensing process and to be involved in helping address these challenges from within the community of licensed professional engineers.

I will not revisit the pros and cons of licensureas noted, there is ample literature on thatand whatever your feelings, licensing of certain software engineers is now mandatory in 40 states in the U.S. and other states will likely follow. Instead, I would like to briefly recap the current situation, describe some of the implementation challenges, and then suggest ACM and its members should be more involved.

The opinions expressed here are my own and represent no other entity with which I am affiliated.

Back to Top

Current Situation

States license engineers who work on systems in which failure could adversely affect the health, safety, and welfare of the public and who offer their services directly to the public.

Generally, the requirements for licensure as a professional software engineer are:

  • Holding a bachelor's degree in software engineering from an ABET-accredited program.
  • Passing the Fundamentals of Engineering (FE) exam.
  • Having applicable work experience (typically, at least four years) under the supervision of a licensed professional engineer (PE).
  • Passing the Principles and Practices of Software Engineering (P&P) exam.

In addition, evidence of good moral character is needed and most states require continuing education to retain licensure. These requirements vary between statesusually pertaining to years of education, the nature of work experience, industrial exemption rules, and alternative paths to licensure.

My volunteer committee developed the P&P exam. The development effort was supported by a consortium of non-profit entities including The National Society of Professional Engineers, The Texas Board of Professional Engineers, and IEEE (through its U.S. Board and Computer Society). The National Council of Examiners of Engineers and Surveyors (NCEES) is the non-profit organization that oversees all exam development and administration for the state boards. Several exam development committee members are ACM members, though they were acting privately. A discussion of the exam development process can be found in Laplante.6

In April 2013, the first Principals and Practices exam was offered. Twelve individuals took that exam and six passed the exam. It is likely the low number of examinees was because the FE exam must be passed before the P&P exam can be taken.


Licensing of certain software engineers is now mandatory in 40 states in the U.S. and other states will likely follow.


The FE exam comprises 180 multiple-choice questions and it is this exam that seems to cause the most resistance and fear when I discuss licensing. The morning session is the same for all engineering disciplines120 questions in mathematics, probability and statistics, chemistry, computers, ethics, business practice, economics, mechanics, strength of materials, material properties, fluid mechanics, electricity and magnetism, and thermodynamics. Software engineers take the same afternoon exam as electrical and computer engineers. This exam comprises 60 questions covering circuits, power, electromagnetics, control systems, communications, signal processing, electronics, digital systems, and computer systems.

Most of the afternoon topics would be learned by a student in an ABET-accredited software engineering program (there are 21 in the U.S.) or computer science program. Some of the morning session topics, however, would not normally be seen by such students. Still, one can think of circumstances where the concepts of material properties, fluid mechanics, and thermodynamics would be relevant to a software engineer working on water treatment, power generation and distribution, or road and railway systems. Besides, these areas represent a small fraction of the test and can be studied independently through review courses. The FE exam was recently revised by NCEES and will continue to evolve to more accurately reflect the widening differences in the ABET engineering programs. Here is an opportunity for software professionals and faculty to seek licensure and work to reform the FE exam and the ABET software engineering degree.

Back to Top

Alternate Paths and Industrial Exemption

Some state boards will waive certain requirements, such as those related to education and experience, or provide for alternative satisfaction. For example, many board policies allow for trading education for experience and vice versa, say, holding a relevant master's degree could count for one year of experience; a Ph.D. could count for two years of experience. Additional years of experience could mitigate holding a non-ABET accredited degree in software engineering or a related degree (such as computer science), an unrelated degree, an associate's degree, or no degree at all. In certain cases "recognized standing" can be used to petition boards for licensure or exemption from certain criteria. An opportunity exists for ACM to lobby state boards to accept a broad set of degrees (for example, computer science, mathematics, information systems) as relevant, award credit for certain professional certifications, and to introduce or expand grandfathering criteria.


Ironically, I have discovered that some people who object to licensing probably do not need to be licensed.


Many states have "industrial exemptions" that allow the practice of engineering without licensure in such areas as electrical or telecommunications utilities, and businesses that manufacture a product. Recently, NCEES convened a group to study how states deal with these exemptions. The group found that "few states actually exempt many categories of engineers from licensure. For example, engineering faculty are specifically exempt in just a handful of jurisdictions. State and local government agencies are exempt from engineering licensure in only one jurisdiction. Public utilities are specified in only 11 jurisdictions."7 The group further recommended that state boards be encouraged to reduce the number of exemptions. The NCEES recommendation presents a threatnarrowing the list of exemptions will increase the number of professionals who need to be licensed. But this is also an opportunity for the ACM and its members to be involved in the discussion to encourage state boards to intelligently expand the exemptions.

Back to Top

Implementation Issues

Complex implementation issues still need to be resolved. One important issue is in defining the "penumbra," that is, to which systems should licensure statutes apply? Other questions include: how do we treat the chain of interactions, custody and responsibility for interacting systems; what roles can licensed professional engineers play; what artifacts should be sealed by the PE; and what roles can non-PE software professionals play? These questions must be answered in a comprehensive and consistent way across states. These issues existed in other licensed engineering disciplines and the answers have emerged with time and experience.

Another unresolved issue, which is common to licensing of all engineering disciplines, is international recognition. There are some agreements in place that can act as building blocks, but there is no uniformity in how state boards treat licensed professionals from other countries and how other countries recognize U.S. licensed engineers.4 ACM and its members can help in addressing these challenges.

Back to Top

Going Forward

Wherever there are challenges there are opportunities. Several companies are seeking licensure of their software engineers as a competitive advantage; individuals can do the same. Given the way licensing statutes are currently interpreted, I believe a very small percentage of software professionals will have to be licensed. Most electrical and mechanical engineers are not licensed, nor need to be, yet the path to licensure exists for them.

For those who are working on systems that will be within the penumbra, licensing will be mandatory. In these cases, whatever their career starting point, I can suggest a path to licensure. It might mean taking a review course or two, or it might mean completing a degree. In some cases it might mean petitioning a board for an exemption. Ironically, I have discovered that some people who object to licensing software engineers probably do not need to be licensed, or would be able to be licensed if only they would take the tests or petition their state board for an accommodation.

State professional engineer licensing boards, which are generally populated by civil engineers, need help understanding software implementation, understanding the penumbra, developing alternative paths to licensure, creating grandfathering criteria, and refining the set of industrial exemptions. It is the difficulties in addressing these issues that are the usual basis of the case against licensing. But licensing is a reality and professional organizations such as ACM, ASQ, and IEEE, should take the lead in helping state boards answer these questions. Otherwise lawyers, lobbyists, and engineers of other disciplines will influence the rulemaking.

Back to Top

References

1. Bagert, D.J. Taking the lead in licensing software engineers. Commun. ACM 42, 4 (Apr. 1999), 2729.

2. Frailey, D.J. Licensing software engineers. Commun. ACM 42, 12 (Dec. 1999), 2930.

3. Knight, J.C. and Leveson, N.G. Should software engineers be licensed? Commun. ACM 45, 11 (Nov. 2002), 8790.

4. Laplante, P.A. An international perspective on U.S. licensure of software engineers. Technology and Society 32, 1 (Jan. 2013), 28, 30.

5. Laplante, P.A. Professional licensing and the social transformation of software engineers. Technology and Society 24, 2 (Feb. 2005), 40, 45.

6. Laplante, P.A., Kalinowski, B., and Thornton, M. A principles and practices exam specification to support software engineering licensure in the United States of America. Software Quality Professional 15, 1 (Jan. 2013), 415.

7. Launey, A.J.P. NCEES task force studies licensure exemptions. Today's Engineer (July 2013); http://www.todaysengineer.org/2013/Jul/licensure-July.

8. Starr, P. The Social Transformation of American Medicine. Basic, New York, 1982.

Back to Top

Author

Phillip A. Laplante ([email protected]) is a professor of software engineering at Penn State University.


Copyright held by author.

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