Here, I argue strongly against licensing for software engineers. I will not be talking in purely philosophical terms. Instead, I will draw concrete lessons from the Canadian experience, where there is a fierce battle under way over the issue of licensing software engineers as professional engineers. This battle has revealed much about licensing and its implications.
First, let me set the Canadian context. Engineering in Canada has for years been a self-governing profession, given exclusive right to practice engineering under provincial and territorial Engineering Acts. Software engineering in Canada (as everywhere in the world) has for years been a central area of computer science. It has not been a professional engineering discipline. Most people calling themselves software engineers are not licensed professional engineers.
What is happening in Canada reveals much about licensing. Indeed, the most important revelation is that licensing is not the central issue, rather it’s whether software engineering should be an institutionalized profession.
Recently, the Canadian Council of Professional Engineers (CCPE), the national umbrella organization encompassing the provincial and territorial engineering associations, has declared software engineering to be an area of professional engineering, just like civil, mechanical, electrical, chemical, or any other engineering specialization. CCPE spells out their position in detail: Software engineers should be trained in software engineering programs housed in engineering faculties and governed by standard engineering accreditation procedures. Graduates of such programs should be able to receive professional engineering license (the P.Eng.) after an appropriate period of practice. And only P.Eng. holders should have the legal right to practice software engineering.
To try to consolidate their claim to software engineering, CCPE embarked upon an aggressive campaign that included:
- Legal action against Memorial University of Newfoundland (MUN) for offering a software engineering program in computer science rather than in MUN’s engineering faculty;
- Trademarks filed on the words "engineering" and "engineer," used to buttress CCPE claims to software engineering (including in the MUN lawsuit);
- Recent amendments to many provincial/territorial Engineering Acts that make it easier to include the design of software under the scope of engineering practice (which has not included software heretofore);
- Accreditation of software engineering programs in the engineering faculties of three Canadian universities (with at least 10 more to come). These programs are variations on standard engineering programs, notwithstanding the considerable differences between software and the physical artifacts of traditional engineering. The bulk of the software expertise in these programs is, in general, provided by computer scientists due to the relative paucity of comprehensive software expertise within most engineering faculties across the country;
- Many media releases, advertisements, and position statements reinforcing "ownership" of software engineering by professional engineering, reiterating that holders of the P.Eng. license have exclusive right to practice software engineering, and claiming that anybody else would not only contravene provincial/territorial law, but also endanger "the public safety."
CCPE’s position on software engineering has not gone unchallenged. Opposing CCPE on various of their claims are a number of interested groups, including the Canadian Information Processing Society (CIPS), Canada’s main organization of software professionals; the Canadian Association of Computer Science (CACS), the national organization of university computer science departments; the Information Technology Association of Canada (ITAC) representing Canadian information technology companies; and the Association of Universities and Colleges of Canada (AUCC), the national organization of universities. These groups have engaged CCPE on many fronts, including producing a variety of letters and position papers that directly contradict many CCPE positions, contesting CCPE in the MUN lawsuit, and serving (with CCPE appointees) on committees set up in the wake of the lawsuit to investigate whether common educational programs can be established for software engineering that are acceptable to all parties. Attempts at compromise have failed to date, and the current situation is antagonistic. CCPE continues to pursue its agenda, the various interested groups continue to oppose CCPE, and the threat now looms of possible legal action by provincial or territorial engineering associations against software engineers practicing without a P.Eng. license.
What is happening in Canada reveals much about the licensing issue. Indeed, the most important revelation is that licensing, per se, is not the central issue. The central issue is in fact whether software engineering should be an institutionalized profession. The license is merely a manifestation of such institutionalization, essentially a device used by an institutionalized profession to distinguish insiders from outsiders.
The Canadian situation provides specific object lessons about the potential drawbacks of institutionalizing a profession of software engineering:
Self-interest. By definition, an institutionalized profession is an entity in and of itself, with its own self-interest. Sometimes the profession’s self-interest can conflict with the public interest.
Reduced interdisciplinarity. An institutionalized profession tends to become encapsulated. It emphasizes its own processes and credentials. It excludes other practitioners. Needed interdisciplinary interactions can be difficult to achieve, both during the education of professionals and later during practice. Such encapsulation is incompatible with the needs of an interdisciplinary area like software engineering.
Conservatism. As with most big institutions, institutionalized professions tend to be conservative. Change happens slowly, innovation may be treated with suspicion, the power of the past can impede future progress. Institutional conservatism ill suits a discipline as innovative and rapidly changing as software engineering.
Reduced academic freedom. Institutionalized professions exercise a high degree of influence on the programs that educate professionals. Unfortunately, the demands of professional accreditation can compromise needed academic freedom and flexibility. Thus, a requirement for professional certification of professors can negatively impact the ability to hire professors with needed subject expertise. Curricula can become overloaded in trying to meet both academic needs and professional demands.
Single professional model. An institutionalized profession tends to promote a single professional model. It is difficult to conceive of one professional model being applied to software engineering. There are many application domains for software, each with its own special characteristics. There are many types of people who create and maintain software, including Web site designers, sophisticated users of spreadsheets, old-school programmers who gained their expertise through experience, engineers building an embedded control system, accountants tuning an accounting package, trained professionals developing a new information system, programmers updating legacy software, and so on.
Dated expertise. A clear problem with the institutionalized profession model is that licensing is done once and is good for life (as long as the registration fees continue to be paid!) Of course, professionals are always supposed to monitor their own knowledge and to update it if necessary, but how easy is this in the software field with its incredible speed of change? Imagine a license issued to a software developer in 1962: Would this still be any indication of professional competence in 2003 in a field changed as dramatically as software has over the past 40 years? Will the speed of change over the next 40 years be any less dramatic?
Before considering an alternative to the institutionalized profession model, I would first like to look at the characteristics a software engineer should ideally have to help guarantee the public safety.
Educational depth and breadth. A software engineer in whom the public could have confidence should have a state-of-the-art education, focused not only on the computer science subdisciplines but also with an ample number of supporting subjects like mathematics, statistics, logic, economics, business, and the behavioral sciences, and with flexibility to include other disciplines in which software could be applied (including, of course, traditional engineering disciplines if he or she were learning how to build systems embedded in standard engineering artifacts). The software engineer should continuously upgrade this knowledge throughout his or her professional career.
Knowledge of context of use. A good software engineer should have sensitivity to the context of use of the software being built and either deep knowledge of the application domain and/or the ability to interact deeply with experts in the application domain.
People skills. A good software engineer needs to have solid people skills, in order to be able to work with others on project teams, as well as to understand the human social environment in which much software is embedded.
Appropriate personal attributes. A capable software professional needs to have or to develop personal attributes such as humility (in the face of our incomplete knowledge of software and software processes and with regard to the complexity of any application domain), self-knowledge (to know what he or she knows and, as importantly, doesn’t know), flexibility (to change with the discipline and to react to situations as they unfold), and confidence in his or her professional abilities (but not so much as to be blinkered to his or her own limitations).
Commitment to process. A good software engineer should also be able to suppress his or her individuality, when necessary, to the importance of following a process that helps to build better, more cost-effective, and ultimately, more reliable software.
Only, possibly, in the last characteristic might the institutionalized profession model be said to do better than other possible approaches.
So, the institutionalized profession model leads to many problems and does little to guarantee most of the characteristics desired in a good software engineer. Is there an alternative model that is less problematical? I suggest the individual professional model where an individual’s professional competence for carrying out a particular software engineering task would be judged on a broad range of characteristics as they apply specifically to that task, such as his or her:
- Quality of education, including the quality of the educational institution, the grades obtained, the particular subjects studied, the types of degrees conferred;
- Skills mastered, including specialized knowledge of particular software packages, certified professional expertise, and so on.
- Employment history, including the kinds of jobs performed, how well they were performed, how easily the individual works with others, the quality of the software firms for which the individual has worked;
- Personal characteristics, including personality traits, leadership ability, and communication skills.
And how would these factors be determined? Not on the basis of a blunt instrument like a license, but through an examination of the individual’s resume, personal interview, letters of reference, and so on. And, what recourse would there be should an individual fail in his or her obligation to protect the public safety? The normal civil and criminal legal sanctions would apply, as for any individual in society.
In this individual professional model, the focus is where it should be: on judging the specific capabilities a person needs in order to produce reliable and cost-effective software in any particular context. Making such individual judgments accurately is the only sure way to protect the public safety in an area as dynamic and diverse as software engineering.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment