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 ... 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.