The Case for Professional Licensure in the Software Profession
 

I recently wrote a blog with the above title <<withdrawn>>.

In the spirit of debate (only), I'd like to know what any of you think of it ... either here or as a (note: moderated) response there.

Please, though ... no flames. (That would be what private messages are for.)

This discussion can begin when, and not before, you're ready to propose a licensing system that you think will work.

No-one, in the history of the planet, has ever done so.

That's easy enough: follow the licensure and standards-setting systems that are already in use within other professions. For instance, auditing or accounting. Start with the known (supposed) security of the data itself. For example, let's consider medical or medical-claims data. Supposedly this data is highly confidential. Uh uh. You need someone to work on the system, so you put out a few competitive bids and six weeks later you've got people from eight time-zones away working on the project who say they know SQL ("what is an outer join?") and jQuery. Okay, but that's not the problem: the problem is, they know =everything= about you. They've got a git-repository with a complete copy of, say, your claims system. Or maybe they're locals ... and you ask, "What does HIPAA stand for and what are its implications to our business?" Blank. Stare. Is that important? It should be. Because they're the ones writing the queries that drive your systems and the associated reports – which they also write, and which you utterly rely on.

Computer software doesn't exist, or work, in a vacuum. It often handles the most sensitive data that there is outside of the military. Should it be something that can just be made by ... anyone, anywhere? Should the qualifications of those people simply be self-reported and that's good 'enuf?

If we impose a legal requirement that this answer is "no," the industry will find a way to comply with it. Hence, my suggestion that the industry should be the one to start defining those requirements first.

Well, if you're hiring for a project where the programmers need to know HIPAA (and there are projects where they do), you'd ask that in the job interview and you might have that exact same exchange. And then you wouldn't hire the guy. What's the problem here? HIPAA "familiarity" is obviously not something you'd want all programmers to have to pay out of their own pocket to write an exam on, so that's a hugely bad example. And I mean a hugely bad example.

The PCI standard would have been a better example, because it's more common to write ecommerce applications, but many programmers never need to touch those either. In those cases, all an exam for PCI familiarity would do is waste the new programmer's time and money. Furthermore, what matters is not that A) the programmers have written exams on the standard, but that B) the software is compliant with the standard. A does not imply B, and the way to verify B, in the case of PCI compliance, is to pay for the software to be audited. Do not attempt to shift the financial burden here.

As a programmer yourself, you should know that this usually actually means "I don't understand the problem." ;)

We can't truly have "audited" systems if we exert no control over who has a programmer's access to them, and/or who has the ability to query the data and to produce the reports upon which business (and regulation) currently depends. We can't have "confidential" data if the data-processing that this data is subjected to isn't as closely guarded as the data is, and this concern isn't limited to the military. We use computers everywhere today for every purpose. It isn't enough to trust the self-reported attributions of anyone who walks up to you and insists that he knows JavaScript and that he can do the job cheaper than the next guy who makes the same claim. Although we don't know the extent to which this too-free access might be used by an industrial spy or a saboteur, we probably wouldn't have the means to know that, either. Since I spend a lot of time thinking about the inherent risks in this "new economy" of ubiquitous data and computers that we've recently constructed, I think about such angles a lot.

And, yes, there is also the problem that in many areas we have no standards: the right way to put two software widgets together is "any way that seems to fit." Very-serious issues arise ("Bobby Tables," anyone?) and each of them is a surprise.

Dude, some companies failing at HR does not imply that licensure (which no-one has ever proposed a working plan for) is the answer. I'm using "implies", here, as it's used in logic.

Also, let me remind you that it was the military and the NSA that had the two most publicized done-by-insider security breaches of the last few years.

This is factually wrong for two reasons. First, the most fundamental concept in security is to choose algorithms that won't expose the data even if the algorithms are known. Second, the correctness of those both algorithms and their implementations absolutely can be audited to the extent that anything can. If you want to move the goalpost for being "truly" audited to the point where it's impossible, then you go ahead and do so, because you'd be invalidating your own position.

So tell me, sundialsvcs, how does your company determine who to hire or subcontract to?

Is this how you hire? And if it is, whose fault is that? Do you think that protecting you from yourself would be worth the cost of subjecting everyone else to a new and expensive bureaucracy? A bureaucracy which has absolutely no possibility of working anyway?

Oh let me guess: yes and yes? You've failed the audit. I hope your prospective clients find this when they do web searches to check you you out.

(Honestly, sundialsvcs, that blog entry was drivel. Just like many of your other rants in General).

Well, dugan, it's most-unkind of you to call it "drivel!" I would never say the same of you.

By data-processing in the above quote, I am specifically referring ... not to the algorithms ... but to the personnel and to the personnel practices. Let me cite for example this page: http://www.infosecurity-magazine.com...-an-inside-job, which in turn cited http://blogs.gartner.com/avivah-lita...target-breach/:
The article specifically refers to procedural controls, of course, "securing insider access." But I aver that an organized formal system for validating the experience and the credentials of a person who works in and with those controls (and many environments which do not have formal control systems although they should), should be included as a fundamental part of those systems, without which we can't really say at all that those systems are "secure" at all.

It is very difficult to hire or to contract in the data processing business – I am very acutely aware of that, and for that reason I never employ contractors to have direct client contact but hold them at arm's length from the project. (Sundial is not a "job shop.") We also routinely do criminal background checks and ... :eek: he looked like such a nice guy and he knew ActionScript extremely well. This has happened more than once. One's ability to actually verify prior employment history is difficult; getting any sort of qualitative opinion from anyone (outside of casual conversation at a bar) is essentially impossible under employment and liability laws. A "license number" would fix that. When I consider engaging a contractor to work on my property, I see "License #XXXX" in all of the advertisements, and I can go on-line and check that claim (as well as see any disputses that have occurred).

And, having said that, it is also significant to note that, under the construction laws, not every employee of the contractor has to himself have a contracting license; but the contractor himself does, and he is legally responsible for their work and for making certain inquiries and assurances concerning them ... all to protect the consumer. I don't think that it's inappropriate – let alone "drivel" – to float the notion that perhaps there is a security-exposure in our industry which does not have an algorithmic solution. And to very seriously suggest that a formal system of professional licensure might be an appropriate move in this (not yet a ...) profession as it has been in other ones.

The true purpose of licensing in other professions is to reduce competition and secondarily to protect the mediocre from both the better and worse ends of the range.

The pretend purpose of licensing is to protect the customer from the bottom end of the range of professionals. But actual licensing systems do a very poor job at that. There is little correlation between those excluded and those who are (or would be) the worst practitioners.

The measurement of skill/knowledge to weed out the worst potential practitioners is far less practical in software engineering than in other professions. So one can predict with great certainty that the accuracy of the selection would be even worse.

The impact of allowing bad practitioners to practice is far less in software engineering than in typical licensed professions. That fact derives from the nature of the typical projects and the nature of the typical relationship between the customer (more likely employer) and practitioner. It is much more practical to use QA procedures to catch software engineering blunders before they do real harm than is true in most other forms of engineering (even more so compared to medical practice etc.).

Good software engineering is still more art than science and more intelligence than knowledge and experience. Thought experiment: If you could look through 10,000 students from high school computer programming classes and find the best one, then look through the software engineers in a moderate size project and find the median one, I am quite certain that best high school programmer is already a far better software engineer than that median professional. Try that with medical: take the best of 10,000 students taking high school biology and compare to the worst (not even median) doctor in a typical hospital. The student simply does not have the knowledge and experience to surpass even a terrible doctor.

You also need to be concerned with the effective suppression of the high end inherent in every standardization or certification process. If you lose some of the incentive/ability to distinguish the best from the ordinary competent accountants in gaining the supposed ability to distinguish competent from incompetent, that may still be a net win. If you burden the best software engineers with side effects of your lame attempt to distinguish competent from incompetent, you have a big loss. A small part of what the best software engineer does on a typical big project is worth more than all the benefit or harm of the worst few engineers.

I skimmed through that and naturally jumped to the point that I think best illustrates why you are wrong:

During the winter break in my second year as an undergraduate, I got a consulting contract to diagnose and correct major performance and accuracy problems in software written by someone who had two PHDs and years of software engineering experience. He was still on the team and had failed in a long effort to diagnose his own work. The best and most experienced (but lacking credentials) member of the team had also tried and failed. I solved that problem quickly and spent most of that winter break making other performance enhancements to their software. Sometimes knowledge and experience just don't cut it, when intelligence is required.

That was a LONG time ago, and software engineering has gotten a lot more specialized and knowledge based. But a few years ago, I brought in a brilliant undergraduate for a summer internship where I work, to attempt a correction to an overly complicated mess left by an "expert" (who had been fired years earlier) that seemed to depend on specialized knowledge no one on staff possessed and it was a topic the intern had never even known existed, much less knew any details. A few days of google searches and a lot of intelligence solved the problem quickly, so we gave that intern several other tasks. At that time we had a PHD in a specialized field (within software engineering) in our team who had been hired with the plan he would start with a few projects that seemed to need that expertise. One of those he kept making excuses to put off and work on other things instead, until the lack of that work was causing serious consequences. I think the "expert" simply could not figure out how to do that work. We had the intern look at it. He asked the expert a few questions about what needed to be done, and despite it being in another topic he had never heard of, he finished the job quickly.

These are some of the most extreme anecdotes I have from years of working in the field. But I'm sure these experiences are not unique. The case I'm making is that intelligence matters a lot more than experience. If you try to regiment a progression, such as you described, you will lose important contributions from the best engineers. You may discourage them permanently. Being brilliant with the hard stuff does not necessarily make you better at the routine stuff, so the best engineers would not even be expected to progress quickly through the levels.

Well, there's a fundamental problem with your latest argument. A licensing system would do nothing to to address the problem of "securing insider access." No background checking or licensing system will tell you who isn't dangerous.

Do you think that any licensing bureaucracy could possibly have done a better background check on Edward Snowden than the NSA did themselves? And I'm sure that Edward Snowden would have been deterred by the thought of losing his license to practice software development.

The other most fundamental concept in data security is to design your systems and processes with the assumption that everyone is an attacker, with the level of paranoia determined by the sensitivity of the data, and with access to the most sensitive data limited to people who would be held personally responsible for any leaks. Do you give people more trust just because they're "licensed"? No. A licensing system would only give you a false sense of security. (Snowden and Manning were indeed held responsible for leaks; one's in exile and one's in prison. That should be enough to deter most people).

In the case of the person who was then known as Bradley Manning, the system was not set up like this. That person was given access to a huge number of files that that person did not directly need to do the job at hand. That was the flaw in the system that made the leaks possible; it wasn't because Manning wasn't "properly" vetted.

As to your point about consumer protection, it's a solved problem. Sundial, as a company, is responsible for any leaks committed by its employees or subcontractors. If they happen, the client sues Sundial to recover the cost of any damage caused by the leaks. I assume you also have a BBB number, which potential clients can look up, and see a record of disputes. So for consumer protection, a licensing system (which, again, you have not proposed a working plan for) would be completely redundant. I think, again, that your real purpose for calling for a licensing system is to make your own HR process easier, and to that, again, I say that a new, huge bureaucracy (which, again, has zero chance of working effectively) isn't an acceptable price to pay for that benefit... to you.

From the second link:

Well, as it turned out, the author of this article was indeed very surprised. I suggest using more up-to-date information sources. (EDIT: especially when you're talking about security!)

And, again, what do you propose that the requirements for getting licensed should be, anyway? That was the first thing I asked, you, you said "that's easy" and proposed something that clearly wouldn't work. Since then, you've swerved straight from talking about incompetence (HIPAA for specific projects, SQL injection) to talking about malice; which of the two should the licensing system be addressing? And how?

People would just get their code off the streets.

From what sundialsvcs has described of his HR challenges, it sounds like he actually does. He also seems to think that everyone does.

Also, do people hired for JavaScript/ActionScript jobs typically need access to sensitive data? Of course not, but those are what he's brought up as "security challenges". His arguments make no sense.

Dugan, one of the principles of debate is to try to keep personalities out of it. There are thousands of companies in this business with several million employees. A debate about the problems that might be addressed by my premise and/or the problems with that premise, is welcome ... but not jabs at the person who brought up a point or a counter-point. This should be off-limits in debate. Please let it be so.

There are two reasons, I think, why licensure is adopted in professions from civil engineering to barbering:

1. You're obliged to make a public record of your training and credentials; and ...
2. There is something that you can't afford to lose, that can be suspended or taken away from you.

Even if licensure is or isn't the solution, the problems are still definitely there – such as the PhD who was said to be unable to solve the problem versus an intern who merely "Googled it." If you look at such stories (and they are quite legion ...), there are many problematic issues to it when viewed from any angle.

(JohnsFine, these are very interesting ideas and yes, I think every "old hand" shares them, although I respectfully do not quite agree with some of your conclusions. Maybe I'm a little more optimistic; or, pessimistic; I don't know.) :)

These rather closely match the history and evolution of many other professions at the nascent points when the need for licensure and standardization was becoming apparent-enough to prompt something to actually be done about it. We've moved rather quickly from the point where computers were isolated machines in special rooms to the point where computers, and software, are ubiquitous ... as is software's impact on every facet of virtually every person's lives. So far, we've been able to focus attention on the technology and the software as though people, practitioners and practices had nothing significant to do with it. We've also been able to contain the damage or at least to conceal it ... but, as computing equipment continues to expand dramatically in its pervasiveness, our profession(!) does, too.

Hence my closing statement that we need to be the ones to first recognize this evolution of our industry (matching that of so many others), and to, as they did, take the lead in shaping its direction and future course.

I don't have any ideas about this, but I have a question: In an environment where such a licensure is mandatory, how would open source software be handled, where it is almost impossible (especially with larger projects, like the Linux kernel, office suites, desktop environments, ...) to get information about such a licensure for every contributor?
Wouldn't this automatically close such environments for open source software?

First, I find the above to be dishonest.

Pointing out that your proposals appear to be attempts to solve problems caused by non-standard (and my impression is, substandard) HR practices is not a "jab". It is a pertinent observation, and trying to redefine it as "off limits" is not going to help you ignore it. Why? Because I'm addressing the very important question of: "what is your proposal really trying to solve?"

Speaking of "personalities" being off limits: If one person is repeatedly evading requests for clarification (which you are), then pointing that out (which I will do now) is obviously fair. Now, for at least the third time, what do you think a person should need to do in order to get licensed?

If you simply ignore this fundamental question and restate your very vague points again (which you've done previously), or attempt to change the subject again (which you've done previously), then you don't get to complain when "personalities" get called into question.

That is both useless and redundant. Most developers are hired for skills that aren't taught in schools (you yourself mentioned ActionScript). Furthermore, records of past employment, training, education and "credentials" (you know, resumes) absolutely can be verified, and most employers do verify them as part of the HR process. You can't verify something on a resume? Don't hire the guy. (Or fire him, if you hired him while the verification is still in progress).

Now, let me return to one of your earliest points:

See how I've already addressed it? ;) Unless you yourself are doing something stupid (and I'm sorry, I can't think of a more "diplomatic" word right now), like storing the actual claims data in the repository, there simply isn't a problem. Are you, or are you not doing that? Your answer is directly relevant to the validity of your entire proposal.

No amount of vetting will stop an insider from doing what insiders do. Bradley Manning was on a mission and had an inattentive supervisor privates just don't need to be exposed to what he was exposed to no matter his clearance. Snowden had a TS/SCI if you've ever been subjected to a clearance investigation you would understand how absolutely complete it is but it stall cannot predict future behavior. The military is currently trying to come up with a way to revamp it procedures to help predict insider threats to the point that there is an idea being floated to scan the online activities of all personnel who have a clearance. I don't know if that can actually be done since there is a push to have everyone have at least a Secret clearance and NDA, secondly I'm not sure it would make through the various unions. I agree that something should be done but I'm also not sure I'm willing to give my last wisp of privacy for it.

for the most part licensing systems are in fact nothing but a form of tax
plumbers it's a tax all work requiring a licensed plumber is inspected any way
same for all building trades all work is inspected
and the license holder never has to even show up on the job
(or ever have lifted a tool for that trade to get the license just pass a paper test and pay a fee )
just pay the permit fees and the tax on his license


the programmers are not the ones who need to be regulated
it's the companies they work for that need to be regulated like M$

sure dose smell like a way to shut down open source software

That is completely true. A lot of licensing systems (including municipal business licensing systems) are instituted solely to generate revenue.

Decades ago in a millenium long past, the Aus Computer Society tried to convince everybody that we were more analogous to a guild of yore, and needed to be certified.
By them ...
For a fee ...

Seems they are (also) still pushing the same barrow - see here.

I suspect that in the next few years we will find that professional licensure is coming, such that it cannot be avoided at least among project managers and team leads, and that this concept has nothing to do with "the craft guilds of yore." (Incidentally, the business of privately-developed for-profit "certifications" is obviously alive-and-well, as we see every day in the Certifications sub-thread.) Ours will not be the one engineering discipline in the history of the world that finds itself exempt from it.

WikiPedia: Regulation and Licensure in Engineering

AAES: Protecting the Public ... (PDF)

ISPE: History of Engineering Licensure

In the "heady, early days" of computer programming, sure, we all had it good ... working in the raised-floor machine rooms with generally isolated computers that were connected to terminals used by employees within our companies. The first inter-company networks (for what was then called "EDI" -- invoicing and such) were likewise extremely controlled. But today, computers are in everyone's pockets, cars, everywhere. And they are not only being programmed, but the programs are being designed and validated, by people whose only credentials are they say they can do it ... according to practices that are only just-now being codified in an ad hoc manner by military contracting and by various exceptionally-vulnerable industries (e.g. PCI); otherwise, that are not formalized at all. As the public becomes more aware of the amount and breadth of information that is being gathered about them, and about the actual practices that are used to prepare software, they will turn to the same advocate they always use to protect their interests: government. It is coming.

Okay, sundialsvcs. You've simply ignored every discussion point, and your latest is an "but I'm still right" assertion. So: whatever you say. ;)

This fantasy of yours been debunked extensively. Sundial may be an outlier that it's actually true for, but you've refused to verify even that (when asked). You're not debating in good faith, SundialSVCS.

Clue, sundialsvcs. Your refusal to adopt industry standard best practices such as code reviews is one factor making in more difficult for you to verify your candidates' skills. The difficulty you're having in verifying your candidates' skills is the only reason you've cited to justify proposing this bureaucracy. Therefore, your solution is improve your own operations, not to call for a new bureaucracy.

Do not try to dishonestly spin this as a personal attack again.

I think sundialsvcs' point in that thread is pretty interesting in contrast with a trade that doesn't require any license but is in no way trivial: welding.

Now, it's true that welders can be certified, but that's not really the end of the process. You don't hire somebody with a certificate and some experience, no matter how much, and let them go build you anything of any safety consequence (skyscrapers, boats, cars, etc). Nobody does that. Not a chance. And despite that, the certification is still valuable while being completely voluntary.

The certification gives the employer a rather generic guarantee that at some point you were good enough to complete a task given some process. A license or cert can't do anymore than this. It's incredibly limited.

And that's why despite being valuable, it's not the end. If you're welding on some guy's submarine, he's going to watch you like a hawk, with a combination of sophisticated analysis tools and other employees who review your work. It's not cheap, it's a continual process, and it's not free of any bureaucracy because it's too expensive for the submarine to sink because you wanted to just weld non-stop until you thought you were done.

Despite a hand-wave to the contrary, nobody is going to let you leave a crap weld on a submarine. The "it's built, it's too late" thing is BS. If you dared to put a leaky boat into the water because you were too lazy to fix it or review any work, you're going to sink your project. Nobody would allow you to leave a botched weld holding up a skyscraper: you or another employee are going to cut it out and fix your mistake. There were definite plans for building either of those things, but you're going to need something stronger and more comprehensive than plans to insure the correctness of the project: review and analysis.

The idea that you can slap a license on something and push the problem off into some corner and think that it's going to accomplish anything seems pretty preposterous.

It seems odd to me that the original blog (which seems to have been pulled) was about how we need licenses to magically fix things while the newest blog entry seems to have found a little more sanity is describing the construction of software as a process.

I generally agree and wish I could weld, machine, or program at that level of skill. When I retire I'll work on all three art forms.

Several of my friends are welders ... in steam plants. It's awesome what they can do.

Incidentally, yes, I have withdrawn the original post for revision, although there are other posts on the more general topic of software quality and quality-process at http://www.sundialservices.com/blog.html, including the most-recent one in which I did shamelessly copy the notion of welding in a submarine. The licensure post will surely reappear at a later date in a revised form.

The points raised in this thread have been very thought-provoking to me, and very helpful. This thing that we are talking about is "ferociously complex," as well as profoundly important, and as we strive to express and to perfect 'methodologies' for dealing with these things it's always with the sincerest (and, survival-oriented ...) intentions. Failures in the process come from the reality that the process is so damned difficult. The bottom line (I think ...) is that we are in "a profession," and that it has become the profession which today touches more people's lives more directly than any other profession has, or ever could. Furthermore, it's a profession that is constantly evolving, "right underneath our feet" and "on the open waters, miles from land."

I do believe that licensure and other forms of regulated business-practice will come, and are already coming in the form of (somewhat ad hoc, at this point) chapters within pivotal legislation such as (in the USA) HIPAA and Sar-Ox. They're also coming from initiatives such as PCI. But they're now being given much more force by what happened to the US NSA and separately to Target. We can't avoid – and shouldn't try to avoid – the oncoming, I think "inevitable," presence of mandatory regulation in our still-baby industry. We should try to shape that legislation as it comes, recognizing also that it is an international concern and not just finance, privacy, or defense-related.

Thank you all, again, for your interesting comments in this thread. I wished to be provocative, of course, but not a provocateur.

Not a problem at all. You're doing what you should be doing, which is revising your position based on feedback.

(Say! I've been quoted!) :)

Ahh, yes, "the Google Interviews" story. Perversely, one of the reasons why some shops use such interviews is to reinforce the notions of the candidate that he (it's always "he") is the smartest kid in school. The harder the interview is, the more he wants the job, and the more :eek: he'll put up with while on the job. He will so badly "want to be 'in' the club," he'll do anything once he gets there.

Silicon Valley "plexes" – GooglePlex, One Infinite Loop, Facebook-land, and so on – are 21st Century manifestations of a very old Victorian-era idea: the "Company Town." You work there, you eat there, you sleep there, you play there, you live there. The company's lawyers will help you get your divorce so you can just keep working. And in this way you're probably good to around age 32 to 35. At which point they simply fire you. ("Old Age and Treachery will outdistance Youth and Vigor, every time.")

http://www.businessinsider.com/micro...ll-book-2012-5
... and so on. (Honestly, if you study industrial history as much as I love to, there is nothing New in this world...)

However, all of this is irrelevant to my main point! :eek:

These kinds of rites-of-passage ordeals ostensibly test whether you have absorbed so-much content out of a language reference guide that you can quote obscure portions from it verbatim from memory during an interview. (But mostly, they are rite-of-passage ordeals.) These are tests of the skills of the über technical specialist. They are tests in a silo, to find out just how deeply in that one silo you can go. In any case, they are the skills of a steamfitter, not the skills of a mechanical engineer. An engineer certainly will specify that the welds in the steam plant that he is designing must conform to such-and-such ASME specifications, and the steamfitters (highly seasoned technical professionals that they are!) will faithfully do that for miles upon miles of welds. Engineering requires you to deeply understand the forces to which the completed system will be subjected and the standards which it must conform to, as well as the processes that must be followed to ensure that the completed system will never fail. It is not the same as being able to pick up a torch and make that weld. (Although this is a highly prized ... and also licensed ... skill that can take decades to learn.)

Ironically, software systems are much more mission-critical even than those steam plants, because ... software is everywhere. There are millions of instances of it, sitting at the very heart of businesses of every description. And yet, a lot of it is being constructed by rank amateurs whose only qualification is that they put in the lowest bid. Some of the things that I have seen in 22+ years of dealing with failed production(!) systems would strain your sense of belief to the point that you'd probably call me a liar ... and I'd sorely wish that I was. As computer software becomes more and more pervasive, awareness of the risks of failure are also becoming pervasive. With it will come the recognition that software programming is a profession, and with that recognition will come licensure and legally-enforced business practices – not just in "the military," but everywhere.

Well, if the following (taken as a whole) isn't equivalent to "the skills of a mechanical engineer", then what, in your opinion, would be?

Also, stop moving the goalposts. The point was to disprove your premise that "people are being hired to write software when their only qualification is that they say they can do it." Which I did.

The "logic" that you're displaying hurts my brain.

Again, come up with how you want licensure to work (I've already asked some pretty specific questions that you've ignored), and you can begin making your point.

Your argument so far has been: Software projects are failing because they are being worked on by people who aren't qualified to work on them, licensure will decrease the failure rate by increasing the quality of the workforce, therefore licensure is either desirable or inevitable (you vacillate between the two). You have resisted every attempt to examine your argument (I've asked many specific questions that you judiciously ignored), and simply chosen to keep restating it.

We shall see, if and when others besides yourself chime in.

I believe that this is code for "This discussion is over." ;)

No, it is code for "a discussion has not yet occurred here." You've made your points, even re-sparking this thread when it had gone silent. Your points and mine have been heard well enough, but few others'. If there is no further interest in the topic on this forum, such that a real debate-dynamic of multiple truly engaged points of view could occur, let it die.

I tried to bring up some relevant points, but I think you took a (maybe intentionally) distorted message from what I said.

My main point is that (in software engineering) intelligence tends to be more important than knowledge. At its theoretical best, a licensing system would qualify based on knowledge, not intelligence. More likely, it would be a set of artificial hurdles that slow down the best engineers almost as much as is slows down mediocre engineers.

Looking at Dugan's interpretation of your argument:

"Software projects are failing because they are being worked on by people who aren't qualified to work on them". That agrees with all of my experience in the field (though I think a larger fraction of failures originate higher up in management).

"licensure will decrease the failure rate by increasing the quality of the workforce". That idea is so implausible, it is hard to imagine how anyone familiar with software engineering could believe that.

Your behavior has consistently indicated that this is not the case.