Misconceptions About Licensing Software Engineers

Your concerns and comments addressed

25 November 2013

Photo: iStockphoto


Two articles featured in The Institute on the licensing of professional software engineers in the United States—Licensing Software Engineers Is in the Works and Answers to FAQs about Software Licensing—attracted a large number of comments with many opposing licensing, some in support or neutral, and several emotionally charged. While a dialogue about issues such as the merits of licensing and its requirements are all healthy, many of the comments reflect persistent misconceptions.

I have spent a great deal of time speaking at conferences and with various organizations and universities about licensing of software engineers, and I have seen these same misconceptions expressed repeatedly. Here, I will address some of them.

Thirty states currently require licensure for software engineers working on systems that affect the health, safety, and welfare of the public as well as those offering their services directly to the public. I expect the remaining states will eventually follow suit. An ongoing misconception is that passing a test to get a license is the only requirement but many readers commented that passing such a test does not guarantee that the candidate will build safe software.

I agree with the conclusion, but not the premise. States license many other types of professions—including accountants, doctors, lawyers, and nurses as well as tradespeople such as beauticians, electricians, and plumbers—through a combination of requisite education, experience, and the passing of one or more competency exams. The same is true for all professional engineers, and the details of these requirements are noted in the aforementioned articles.

Some objected to the requirement of having to pass the Fundamentals of Engineering Exam (FE), a test of basic concepts that include business, chemistry, computer programming, ethics, economics, mathematics, mechanics, and probability and statistics. Opponents say that most software engineers will never use much of this knowledge. 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. In any case, these subjects are traditional ones studied by engineers. To question the relevancy of these concepts to the profession of engineering or software engineering is the purview of professional organizations, such as IEEE, universities, industry councils, and government entities.

Others complained about the unfairness, irrelevancy, or difficulty of also having to pass the Principles and Practices of Software Engineering exam, which is the subject matter exam taken after passing the FE to demonstrate requisite education and experience. The test was developed using the same rigorous process that is used for subject matter exams in other professions such as accounting, nursing, and medicine. It was designed to be passed with a high rate of reliability by those who have the relevant skills and knowledge. The methodology used in developing the exam was published in the report  “A Principles and Practices Exam Specification to Support Software Engineering Licensure in the USA” by a top software practitioner journal, Software Quality Professional. I also encourage people to take a look at the review book for the exam, which was published by IEEE.

Some opined that few actual cases of software failure causing humans harm exist. I would amend this statement to say: “have been reported.” The community acknowledged high-profile failures such as Therac-25, a radiation therapy machine that had given massive overdoses of radiation to cancer patients, but they contend that there hasn’t been a problem with dangerous software failures.

We are only beginning to understand the complex interactions of software systems and the ubiquity of embedded software in consumer products, public infrastructure, transportation systems, and other areas with great potential for harm to the public due to software failure in those systems that are not rigorously engineered.

Some respondents fear that licensing will drive software jobs overseas or that the use of software from outside the penumbra of licensure will endanger the public. On the contrary: requiring stricter control of the production of critical systems software requires that greater attention be paid to those who produce software, the sources of third-party software components, and their quality.

Some blog comments read: “I have a Ph.D. in X with more than Y years of experience building significant embedded software for important mission critical applications. It is ridiculous and insulting that I should have to take some test for a job that I have done for many years.” If you want to become a licensed software engineer but not take the test, you may be able to take advantage of alternative paths to licensure, such as qualifying for what is called “grandfathering,” which is available in some states. But you will need to prove your claims of expertise to the state board of professional licensure, and it will decide whether you are exempt from having to follow the standard path to licensure.

Other forms of objection hinge on opposition to government regulation or licensure of professionals in general. Opponents say, “Why should the government set the parameters for who can be a software engineer?” I think these objections have theoretical merit, but then you must apply these arguments equally across all professions and trades, not just engineers. But before you go down that road, consider the consequences of not requiring licenses for doctors, lawyers, and nurses.

Finally some comments were personal attacks that questioned the motivations or intelligence of those working on the licensing effort. While I will not dignify those posts with a response, I want to note that those who worked on this project are world-class software practitioners with substantial experience who have built—and are building—software for avionics systems, medical devices, missile defense systems, nuclear power plants, transportation infrastructure systems, water and wastewater handling systems, and more. These volunteers are working on this project because they care about the health, safety, and welfare of the public and the profession of software engineering.

phil Photo: Christopher Laplante

IEEE Fellow Phillip Laplante is chair of the Software Engineering Licensure Examination Development Committee. A professional engineer, he also is a professor of software engineering at Pennsylvania State University, in Malvern.

IEEE membership offers a wide range of benefits and opportunities for those who share a common interest in technology. If you are not already a member, consider joining IEEE and becoming part of a worldwide network of more than 400,000 students and professionals.

Learn More