In other engineering disciplines, engineers are often required to undergo a licensing process. This gives a sense of security to the public - for example, confidence that our bridges are built with the necessary materials and structure to support the necessary load. This causes many things to function differently in those engineering fields - often more rigorous planning or accounting is applied, and engineers are sometimes liable for their work. On the other hand, engineers are somewhat more empowered to conduct their craft in accordance with best practices and not budget - protecting the best interests of the customers they serve.
From a business perspective this would be one more way to evaluate people (be it right or wrong, it would be used this way) however my question lies in the attempt to "standardize" - i.e. to have a test that evaluates skills there has to be an agreed upon "best practice" -- who determines said best practices, and is there consensus on said practices? Most things that are licensed have a near unanimous agreement to the things being licensed, i.e. "if its a rear wheel or all wheel drive car, turn into the skid". This is known and agreed upon by everyone from teachers to race car drivers. It's empiric, it can be proven definitively - opinion doesn't come into play until you get into the minutiae of the empiric fact or add in variables - to some degree the "how". Engineering has some concrete "facts" that are non disputed based on everything that is known at current, those facts don't change very often, i.e. the melting point to reduce structural integrity of a beam made of "x" really isn't going to rapidly change provided all the variables are known - it's a solid enough fact that there can be a licensing around knowing such things. The concrete quality of this knowledge / skillset allows licensing to work, driving for example doesn't radically change in it's core skillset, even when new technology comes about, and when new technique or technology comes about it's a "small" change - not large enough to have to "re-license" everyone.
Software is constantly changing, and has a creative "opinion" component, so the question then i would ask is this: Using this "license" as a buyer of a resource am I getting a developer that is highly capable AND current, or am I getting a developer that checked the right boxes and adheres to a now possibly outdated set of rules/methodologies?
The other element is that any time there is the ability to certify or offer any kind of credentialed system, there is an area to make money -- monetizing certifications and licenses can create corruption in that space or create scenarios that are beneficial to the licensing organization but not the industry as a whole. Licensing becomes a cash cow when the criteria to be licensed are highly malleable and change rapidly over time, which is often the case in software. This means that the licensing would have to be at such a "fundamentals" level that it might not matter to most (think perhaps of the UL accreditation on household appliances), OR is changing so fast that it loses its meaning with any slightly informed employer.
It could, in a silicon-valley type world even be a DETRIMENT to someone to have said licensing as it could a false flag of capabilities/lack thereof - i.e. ability to change and adapt. An example of this: the Project Management Professional or "PMP" certification during the agile renaissance became a detriment as often more cutting edge employers saw it as "the old way" - I know many people that took it off their resumes for this exact reason and the Project Management Institute is now offering a "Agile" certification vs. simply rolling agile information into the new version of the PMP. they're doing this for 2 reasons - A) the industry is seeing the PMP as outdated and is actually not a signal of value based on current needs, in fact it's seen as a red flag, a potential detractor B) they can make more money by offering a whole new certification.
I see the concept of software licensing interesting, but I question it's real world accuracy and usefulness. To me, personally - someone that thought of a "software licensed profession" (not an accreditation/certification) is out of touch with the current time and is in denial regarding the rapidness of change in the technology sector.
If the software development field moved toward an accredited profession it would be the sign that it is maturing. In its relatively young life software development has fast grown to become pivotal in the advancement of humanity and its well-being. Along with this breakneck expansion has come justifiable distrust of software developers from the rest of the business world, only starting to improve within the last decade.
Why the distrust? Because out of nowhere a new industry full of young professionals appeared, offering promises of solving the world's problems using technology many still consider black magic. When business leaders buy into these promises, some are met by great success, many are met with drawn out project schedules and inflating costs. Software development as a profession still has little consistency in the quality of the product it can provide and in how much time it can provide it. These issues are precisely why so many other mature professions are licensed or accredited.
Accreditation can signify a variety of things depending on the profession but it often guarantees a level of professional expertise of the accredited individual. Like many other technical professions, the depth of knowledge necessary to stay competitive in the software development field is such that proving it would not be well suited to a slowly evolving accreditation process. The evaluation of current technical aptitude should be left to the many certifications offered (and constantly updated) within the industry. Instead, a software development accredited professional should prove their knowledge and use of best practices that help ensure a product can be produced with quality and in a determined amount of time. Examples of this would be ensuring that the software professional is well versed in common design patterns, automated testing, and continuous delivery to name only a few.
Accreditation can also ensure a degree of responsibility for the work performed. This can reflect both ethical and legal responsibility. Do we as software developers feel an ethical responsibility to meet the needs of our business and our end users and make their lives better? Do we have a legal burden to uphold these ethics in every project we are a part of? Would these concerns cause us to give more thought to the work we do and how?
Finally, who would perform the accreditation of software development professionals? In other fields this often falls on state governments to legislate and uphold. In this case, it may be better to call on ACM and IEEE, the two professional associations of the industry. These organizations are both very well respected and are worth joining if you have not already.
This is an interesting question, and invoked an immediate negative emotional response from me, which perhaps helps to answer the question. We recently had the debate internally as to whether to list our open positions as "Software Developers" or "Software Engineers," and I'm firmly in the park of the "Developer" tag. I struggled to put into words a response to this beyond the emotional "I don't want to," but a couple of things come to mind. For me personally, software is not a rigorous field (see rigor: thorough, exhaustive, or accurate) -- we rarely get to write "provably correct" code. And I don't mean provable as in unit and integration tests, but rather true proofs. There are so many system conditions we don't account for because "it'll never happen." When it inevitably does happen... we fix it and redeploy it. Other engineering fields don't have that sort of freedom. If you put something out wrong the first time, the project may well fail.