Professional Licensing Premises

From ProfessionalLicensingOfProgrammers.

Let us discuss/debate here the premises that may support ProfessionalLicensingOfProgrammers. We should state right away that even if the premises are found to be correct that will not necessarily entail that ProfessionalLicensingOfProgrammers is the solution.

There are people who believe the premises are correct but are not ready to buy into ProfessionalLicensingOfProgrammers until we can be reasonably sure that the cure is not worse than the disease -- and under current conditions of the labor market and the organization, composition and political ramblings within established professional bodies related to programming there's a strong likelihood that the cure may very well be worse than the disease. So let's reserve the ThereforeBut part for a page of its own.

I'll enumerate some premises, but contrarians, please jump in.

Premise 0: Programming as a profession (as opposed to hobby, programming as a user, etc) is essentially an engineering discipline. Yes, it also shares something with art, science, even sport, but its essential character makes it an engineering discipline.

The above premise is not a strong argument for professional licensing but if it was not true, professional licensing would make less sense. A lot of engineering disciplines have licensing requirements but arts do not, nor would it make much sense to license an art.

[However, note that many non-engineering disciplines, such as accounting, law, medicine, driving trucks, construction/contracting, etc. have licensing requirements of various types and scope, despite having nothing to do with engineering.]

I doubt you'll get a majority of programmers to agree to this premise. Computer science may be close to an engineering discipline, but modern software development has more to do with language, philosophy, and tactics than it does hard science.

Well, first of all, I do not seek the approval of majority of software engineers. In my estimation based on anecdotal evidence (but there can't be but anecdotal evidence anyway) the majority of software engineers are unqualified to comment on the above premise, so your observation loses any value right there. Second, Computer science, or more precisely computing science is not an engineering, it is as you may guess, science. A formal science at that, a branch of mathematics. SoftwareEngineering and ComputingScience are different things.
If you call "modern" the software development that has anything to do with philosophy, well, allow me to doubt your definition of modernity or your assertion that whatever style of software development that you have in mind is somehow "modern".

Fair enough, but if the people involved aren't qualified to comment, what makes you?

First of all the quality of my arguments, my arguments should be judged on their face value without any prejudice as to the likelihood of their value. I'm no authority in the field if that's what you search for. Then there's the fact that I already contributed some content on programming to wiki that other people found useful, the fact that I earned a pretty good recognition of my skills in the workplace, my successful projects, my increased salary, etc. What else do you need ? If you want references from people with well deserved name recognition, weighing in on the subject I can quote from DavidParnas, EwDijkstra, SteveMcConnell, FredBrooks, etc. You can do some googling or browse your books for yourself.
Do not get it wrong, I have no prejudice (though I have a bias) as to the conclusion of this debate, but I do not think that getting "the majority" into this picture is a valid argument. The history and evolution of ideas is rarely shaped by "the majority" and more often it is shaped by the people who matter. We already have most of the people who matter weighing in on the side that computing science should be treated as a science, distinct from software engineering which should be treated as an engineering discipline.

Indeed. I've seen many of your posts here, but I can claim the same authority as you. I am also a veteran programmer - check my personal page and evaluate for yourself. Still, I don't understand your dismissal of the opinions of other programmers - Every programmer thinks they are better than anyone they never met, and it's hubris to think it is as simple as "we know better than them". There are valid reasons for the varied approaches and philosophies programmers have. I prefer to see programming in terms of language and symbolic systems, you may prefer to see it in terms of engineering - but neither is implicitly more valid. They are simply different flavors. I would argue that DesignPatterns are tactics, formulating a good SystemMetaphor is philosophy, and that designing good interfaces to manipulate the whole thing is language. Of course using "the majority" is a FallaciousArgument, just as ArgumentFromAuthority (especially when the two are combined to form a "most of the people who matter" argument) is. However if you expect people to sign onto a licensing setup, you'll need to at least hear opposing viewpoints. There isn't much debate about the nature of computer science - it is a science. There is still tremendous debate about the nature of software development (construction? engineering? craft?), I'm just trying to say that the premise need some work - perhaps drop the word engineering and state the properties of programming that you believe are similar. -- LayneThomas

Look ArgumentFromAuthority is not exactly a fallacy. It is not a decisive argument but it is a damn good heuristic. We have nothing but heuristics on the subject. SoftwareEngineering is the widely recognized word that denotes our profession.
I certainly hear opposing views. Programming or more generally software development does have artistic elements. So do many other engineering discipline. Creativity is not a core engineering practice, but the fact that some activity requires intellectual creativity, does not disqualify activities from being usefully called "engineering disciplines". I choose to disagree with your characterization of SystemMetaphor as a philosophical element, but I do not think it matters. Even if it was, one would have to prove that all these influential elements from other areas of knowledge significantly alter the content of our profession to the point where it can no longer be usefully classified as an engineering activity. --CostinCozianu

Objection to Premise 0

I do not find the assertion that programming is an engineering discipline either supports or contradicts the idea of professional licensing. Many, if not the majority, of licensed professionals are in non-engineering tasks, for example doctors, lawyers, and accountants. Licensing does not imply Engineering. This would only leave the argument programmers are engineers and engineers should be licensed, ergo programmers should be licensed. The difficulty lies in the term "engineer." The term is too poorly defined, too broadly used, and applied to too many non-licensed workers to imply any relationship between "engineer" and "licensing." Given the lack of correlation, continued discussion of whether programmers are engineers is pointless.

Other premises:

Software engineering market is a market with low visibility and asymmetric information. As the situation stands as of 2004 (and the many years before) it is hard to tell for the consumer of engineering expertise who has the minimal competency for software engineering and who has not.
Following from the above, there is the premise that there are significant problems for both consumers and suppliers that need to be addressed somehow. Or if we decide that the cure is worse than the disease they don't need to be addressed, but if there was no problem, the solution would be discarded automatically.
Premise: Professional Licenses indicate future proficiency. I believe this is the underlying desire, "Can we predict who will be successful in known and unknown future tasks?" Prediction is always tricking, but the best we can do is hope that past performance will reflect future performance. The question now becomes what items of past performance best predict future performance and how well does a License represent those items?

In other disciplines, licensing is typically required for practitioners who:

1) Wish to sell their services to the public, or 2) Are working on MissionCritical stuff in a leadership role.

Junior chemical engineers and junior civil engineers are not licensed--indeed, they cannot be as significant industry experience is a prerequisite for licensing. However, unlicensed civil/chemical engineers cannot accept certain types of work.