On licensing software engineers

In this post I will attempt to argue that, if one believes that there should be a licensing process for professional software engineers (and there are good arguments that there shouldn't be), that the licensing process for professional actuaries would serve as an excellent model to copy, and is superior to modeling a software engineering licensing process off of the so-called "Professional Engineer" (PE) license available to, e.g., civil, chemical, mechanical and electrical engineers.

Every once in a while, particularly after a catastrophic software-induced failure (for instance, after the allegations of unintended acceleration on the part of the Toyota acceleration control module), I hear renewed calls for software engineers to be professionally licensed, to ensure that only competent and trustworthy people can practice in the field (or can practice particular roles in the field).

What I hear people propose the most often is to add a "Software Engineer" exam to the set of exams one can take to become a licensed "Professional Engineer".

This is a problematic idea for several reasons.

First off, the standard PE track requires taking a "Fundamentals of Engineering" exam prior to taking the PE subject-matter exam. The FE exam is all good stuff to know, but it seems to cover the overlap between traditional fields of physical engineering. A computer science student or software engineer might know this material by coincidence, but current programs aren't necessarily designed to impart this knowledge.

Second off, the standard PE certification strongly assumes that one has an engineering degree from an ABET-accredited engineering program, likely in the engineering school of a major university. Without even getting to the many software engineers who don't even major in CS, the ABET requirement, as it stands, would make it impossible for people who majored in CS at Carnegie Mellon or at, I believe, CalTech, to attain a PE license. Discussion of PE certification for Software Engineers have talked about backdoors and grandfather clauses for institutions like these -- but when the top programs in a discipline require a grandfather clause for the certification you're proposing, perhaps something is wrong with the certification.

Third off, many of the best practical software engineers I know don't have degrees in computer science or computer engineering. Many have degrees in other STEM fields, and some have no degree at all, yet are far more practically competent than large numbers of people who hold CS degrees.

Luckily there are professional domains other than engineering that have long-established professional licensing systems. I propose that a better one to copy would be the system used to license "actuaries".

Actuaries work in industries like finance, insurance, etc. Their role involves measuring and managing risk and uncertainty. To an outsider like myself their field looks like a highly specialized subfield of applied statistics.

And they have a licensing system.

Best of all, they have a licensing system that, in the US, does not require that your degree be in any particular field (source : https://www.howtobecome.com/how-to-become-an-actuary ). Yet, at the same time, their licensing system is rigorous enough that those actuaries who did not major in "actuarial science" often have undergraduate degrees in mathematics.

And, like computing, their discipline is considered to be a quantitative field, which, arguably, is a better analogy for how to treat professional software development than "engineering"

Their certification process proceeds in steps and involves a mixture of exams and apprenticeship. Exams include topics like markov chains, survival models, generalized linear models, etc. Apprenticeship, I presume, entails working (for pay?) under a certified actuary.

Of course, I, personally, prefer the current system of "no certification process whatsoever". But, if you're going to make a certification process for software developers, I think the actuarial model is a better model for most day-to-day software engineering than the PE model.

I *could*, however, imagine a PE license for something like "controls" or "cyber-physical systems", and a world in which someone in charge of the Toyota acceleration control module would have to be dual-certified in that and in a non-PE software development certification modeled after actuarial certification. In such a world the person who is in charge of writing your banking software might have to hold some currently non-existent software development certification, but would not need a PE certification to perform what is, acknowledgedly, a critical function, but not which is also not a task that requires training in physical engineering.