Communications of the ACM
Communications of the ACM
Licensing Software Engineers
Déj`a vu. As I read the many comments on software engineering licensing I'm reminded of the debate on the merits of the "go to" statement that raged in this publication three decades ago. I recall in particular the famous computer scientists of the 1960s arguing in favor of the "go to" without really understanding Edsger Dijkstra's point when he first proposed that it was harmful. This taught me an important lesson: serious issues demand serious investigation; immediate responses can be very wrong.
Unfortunately, licensing is a political issue and not a technical one, so finding an answer is difficult, and it will never be possible to prove any course of action is the right one. The debate on licensing of software engineers has been a personal journey for me. I continue to struggle with the pros and cons, concluding that great good and great harm can result no matter which way this issue is settled. It all hinges on people, their personal integrity, and how they handle their responsibilities.
What bothers me most is the shallowness of much of the debate. Do the writers really know how licensing works? (For example, licensing only applies to a small number of individuals.) Have they considered the political and societal issues as well as the technical issues? As I listen to my fellow computer professionals, I'm proud to observe that our motives are generally altruistic: we seek order, logic, certainty, and perfection, although we live in a world driven by opportunism, probabilities, politics, and pragmatism.
This debate is noble, but we must not let the issue of licensing cloud our judgment. A case in point is that many arguments against software engineering licensing boil down to "there's no guarantee it will solve anything." This is undeniable, of course, but is it relevant to the issue? We do not live in a world of certainties or absolute solutions. A college degree, a course in Java, use of semaphores, a proof of correctness or years of programming experience do not guarantee anything. But we acknowledge that these things have value and we strive to use them properly.
One undeniable fact is that we do not control licensing. It is a political mechanism that can be used by forces with motives far different from our own. However, we can influence licensing, and we must influence it for good. Two potentially good results from licensing of software engineers: (1) because licensing forces us to define, codify, and organize our field and has the potential to improve the overall quality of the software engineering discipline; and (2) because licensing may be legally required for certain purposes (very limited, I suspect), it has the potential to reduce the chances that unqualified, incompetent practitioners will build inappropriate software in systems that affect the public's health and safety.
Licensing is not necessarily the best solutionmaybe we can guide society to a better one. But humans have a pretty strong track record of regulating and licensing things that could hurt people. If the skills associated with a powerful new technology cannot reasonably be evaluated or understood by the layman, regulation is one of society's less intrusive ways of keeping things under control. Societies all over the world license and certify those whose practices affect public health and safety such as nurses, stockbrokers, lawyers, engineers, and even cosmetologists. Medical licensing does not prevent unethical or incompetent medical practices, but it certainly improves the odds. (I am acutely aware of this when I'm about to undergo surgery.) And because licensing rests on accepted standards of competence and practice, it provides the legal basis by which customers can seek redress, and the same legal basis by which practitioners can defend themselves. One way or another, society will define these things. Who is more qualified than the computing community to help society accomplish this?
Our primary responsibility as computing professionals is to give this matter serious attention. We ought to read opinions on all sides, learn the facts about the subject, and participate in defining reasonable regulation mechanisms. We ought to let our leaders (professional and political) know what we think about these matters. (You might be surprised at what some of these leaders think you believe.) We should help our professional societies define and codify software engineering. If we work together we can have a major influence.
Some licensing authorities have already asked us to work with them. If we reject these overtures, split into factions or fail to act at all, we may find ourselves at the mercy of laws defined to protect special interest groups or to increase the reach of professional organizations that do not represent our community. This has already happened in some countries, where professional societies unrelated to software control the legal definition of software engineering. In one U.S. state, the senate recently passed legislation allowing trade schools to award engineering degrees (including software engineering.) Fortunately, the bill died in the house. The main spokesperson the legislators heard was a lobbyist for a trade school program. This is a very real political issue.
Every field needs to mature, and licensing has a good track record of helping disciplines do so. Some argue that society should leave software engineers alone. But we are not leaving society alone and the response is the same as it's always been. Licensing and regulation are too important to leave to others.
©1999 ACM 0002-0782/99/1200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.
No entries found