This book has been superceded by Professional Software Development

gr.gif (9552 bytes) After the Gold Rush: Creating a True Profession of Software Engineering. 208 pages, Redmond, Wa: Microsoft Press, 1999. Retail price: $24.99. ISBN: 0735608776.


Excerpted from:
Chapter 10
Stinking Badges

Badges? We ain’t got no badges. We don't need no badges.
I don't have to show you any stinking badges.
— Gold Hat Bandito, Treasure of the Sierra Madre

Few issues are as controversial to software developers as licensing and certification, and in few areas are the conclusions as inescapable. If you are a software developer who plans to be in the field for 10 years or more, you will have to confront these issues.


Certification is a voluntary process administered by a professional society. The intent of certification is to give the public a way of knowing who is qualified to perform specific kinds of work. Certification requirements usually include both education and experience. In most cases, a written examination is used to determine the competency of the individual seeking certification. Certification usually extends beyond a limited geographic area to national or international regions. The best known example of professional certification in the United States is certified public accountant.

Some organizations have offered certification for software workers for many years. The Institute for Certification of Computing Professionals offers Associate Computing Professional and Certified Computing Professional designations. The American Society for Quality Control offers a Software Quality Engineer designation (although the organization’s usage of the term "engineer" may expose it to legal problems because the term is regulated by most states and throughout Canada). At this time, there is no universally accepted certification program for software engineers.

Many companies offer certification programs related to specific technologies. Microsoft offers a "Microsoft Certified Professional" designation. Novell offers a "Certified Network Engineer," Oracle offers an "Oracle Certified Professional," and Apple Computer offers an "Apple Certified Server Engineer" designation. The focus of this kind of certification is limited to a single company’s products, which makes it narrower than true software engineering certification would be.

Software is mysterious and complex enough that non-software practitioners need help in selecting qualified technical personnel. Certification offers employers and customers a way to recognize software personnel who have achieved at least some minimum level of qualifications. The market is already supporting this. At the time I write this book, lists 25 categories of books on various kinds of software-related and computer-related certification exams. Nearly all these exams are related to specific technologies. A widely recognized, broader software engineering certification program would be a useful addition to the field.


Licensing is a mandatory, legal process that is intended to protect the public. Licensing is typically administered by jurisdictions (states, provinces, and territories). For many professions, national organizations advise the jurisdictions on appropriate licensing requirements and exam contents.

Most professions are licensed, including doctors, architects, lawyers, and engineers. No occupation that affects the public as much as software does remains unlicensed. The following list gives examples of occupations that require licenses in the State of California.

  • Acupuncturist
  • Alarm company operator
  • Amateur boxer
  • Architect
  • Attorney
  • Barber
  • Certified public accountant
  • Contractor
  • Cosmetologist
  • Custom upholsterer
  • Dentist
  • Embalmer
  • Family counselor
  • Funeral director
  • Geologist
  • Guide dog instructor
  • Hearing aid dispenser
  • Jockey
  • Locksmith
  • Manicurist
  • Mule jockey
  • Nurse
  • Pest control operator
  • Physician
  • Physician’s assistant
  • Private investigator
  • Professional engineer
  • Real estate appraiser
  • Repossessor
  • Retail furniture dealer
  • Veterinarian

 In engineering the majority of engineers do not obtain licenses. Engineering companies are required to employ some licensed engineers, but not all of their engineers have to be licensed. Almost half of civil engineers are licensed, whereas only 8 percent of chemical engineers are licensed. The difference lies in how replicable the engineered artifact is and how much impact the item has on public safety. Artifacts that are replicated in large numbers can be tested before they are manufactured and sold to the public; this testing generally minimizes the risk to the public and reduces the number of licensed engineers needed for a particular kind of work.

Civil engineers design many one-of-a-kind, safety-critical artifacts—highways, bridges, baseball stadiums, airport runways, and so on. Electrical engineers design artifacts that are reproduced in large quantities—toasters, televisions, telephones, and so on. So, as Table 10-1 shows, more civil engineers than electrical engineers are licensed.

Table 10-1. Percentage of Licensed Engineering Graduates in the United States as of 1996

Discipline Licensed
Civil 44%
Mechanical 23%
Electrical 9%
Chemical 8%
All Engineers 18%

 Where would software engineers fit into this table? We produce many one-of-a-kind artifacts, but we also produce operating systems, tax preparation software, word processors, and other programs that are replicated by the millions. We produce some safety-critical systems, but many more business systems that have less significant impacts on the public safety. On balance, perhaps 5-10 percent of people currently practicing as computer programmers will eventually get their badges—their professional engineer licenses in software.

Bootstrap Licensing

The movement to license software developers began to gain momentum in 1998 when the Texas Board of Professional Engineers adopted software engineering as a distinct licensable engineering discipline, resulting in a professional engineer, or "P.E.," designation for professional engineers specializing in software. The ACM and IEEE-CS are currently working with the Texas Board of Professional Engineers to create a Principles of Practice Examination that will allow software professional engineers to obtain their licenses the same way other professional engineers do.

In the meantime, Texas has begun licensing professional software engineers under a restrictive exam-waiver clause. To obtain a P.E. license before the exam becomes available, an applicant must have one of the following:

  • 16 years of engineering experience
  • 12 years of engineering experience and a bachelor’s degree from an accredited university program
  • 6 years of experience and a Ph.D. in engineering or a related subject from a university whose undergraduate program is accredited

In addition, each applicant must provide at least nine references, at least five of which must be from licensed professional engineers (not necessarily software engineers).

The same criteria for waiving the professional engineering exam apply to other engineering disciplines in Texas.

How many practicing software developers could qualify as professional software engineers under Texas’s current licensing procedure? Not very many, and that’s one of the smartest things the state of Texas has done. The natural tendency would be to make the exam-waiver clause so loose during the bootstrapping phase that most current practitioners would automatically qualify. The net effect of that would be to degrade the term "professional software engineer" to mean the same as "run-of-the-mill programmer." By making its exam-waiver clause restrictive, Texas has maximized the likelihood that professional software engineers will represent some of the best software developers in Texas, and it has safeguarded the reputation of the "professional software engineer" title.

Texas is significant because, along with New York and California, Texas is a bellwether state. In high school textbooks, for example, Texas’s approval clears the way for about 40 other states to approve a textbook automatically. Other states are watching Texas’s software licensing actions carefully. Where Texas goes, others will follow.

After I wrote the first draft of this chapter and while I was awaiting comments from my peer reviewers, the Association of Professional Engineers and Geoscientists of British Columbia (APEGBC) began registering software professional engineers (P. Eng.) in British Columbia. Like Texas’s program, APEGBC’s program contains a bootstrapping provision that allows software developers with the appropriate combination of education and experience to obtain their professional engineering licenses.

Your Stake

One of the consequences of being a professional engineer is that you can be held personally liable for the work your company performs under your signature. Courts in the United States have held that only members of a profession can be found guilty of malpractice. Doctors, lawyers, and architects can be guilty of malpractice. Garbage truck drivers, short order cooks, and computer programmers cannot be guilty of malpractice because, legally, they aren’t considered to be professionals. By establishing software engineering as a profession, we are paving the way for the courts to find that software engineers can be held liable for malpractice just like other professionals. On the other hand, following commonly accepted engineering practices can be a defense in a some cases.

Many programmers will choose not to become professional engineers. Some won’t be interested in the studying required to pass the P.E. exam. Some will think that, since a P.E. designation doesn’t guarantee an increase in salary, the reward doesn’t justify the effort. Others will choose to avoid the possibility of personal liability.

The disadvantages of becoming a professional engineer might appear to outweigh the benefits, but inducements to become a professional engineer will come both from the government and software organizations. No individual engineer will be required to be licensed, but some companies will be. The specific kinds of companies that will be licensed is an open question and will depend on the political climate during the next few years and on the extent to which software-related problems catch the public’s attention. The companies most likely to be required to employ professional engineers include:

  • Companies that sell software engineering services to the public
  • Companies that perform software work for public agencies
  • Companies that produce safety-critical software

Other companies may voluntarily employ professional engineers to take advantage of the marketing cachet of hiring workers with the best available credentials or because they see hiring professional engineers as a way to strengthen their technical talent pool. (Hiring software engineers who have obtained certification but not professional engineering status might serve these companies’ interests as well.)

Professional engineers in these companies will review software engineering work and sign off on the software their companies deliver. To those companies, employing professional engineers will be a legal necessity, and, in the early days of licensing when professional engineers are in short supply, software companies will reward professional engineers accordingly. If software companies follow other engineering disciplines, the company that hires a professional engineer will pay for the professional engineer’s liability insurance as part of the employment package, which will minimize that disadvantage of getting your professional engineering license.

Professional engineers will gain other benefits. The professional engineers who put their signature and reputation on the line for their companies will have final say over methodology choices, design approaches, and other decisions that affect the quality of the software for which they might be held liable. Without professional standing, your boss can come to you and demand that you commit to unrealistic schedule, make short-sighted design compromises, or sacrifice quality in order to get the software out the door. As Fred Brooks pointed out a quarter century ago, it’s difficult to make a vigorous, job-risking defense of something that has no quantitative foundation and is certified chiefly by your hunches. A well-defined profession—consisting of education, a code of ethics, and licensing—will give you a stronger foundation than mere hunches. You will be able to say, "The standards of my profession don’t allow me to shortchange quality in this situation. I could lose my license." You will have a professional and legal basis for standing up to unenlightened managers, marketers, and customers—a basis that is sorely lacking today.

People who choose not to become professional engineers will encounter a glass ceiling that prevents them from rising to the top of the technical ranks in companies that employ professional engineers. Above a certain technical level, companies will be disinclined to promote software developers who can’t sign off on a software release. Achievement of professional engineering status also says a person is serious about his or her profession. That demonstrated commitment to the software field may improve promotion prospects too.

At the organizational level, we may see an interplay between an organization’s SW-CMM rating (discussed in Chapter 7) and the professional engineering license. Professional engineers will potentially be liable for the software written under their supervision. Professional engineers won’t be able to personally review every line of code on large projects. Even if the organization pays for professional engineers’ liability policy, I think that professional engineers will generally want to work for organizations in which they receive the most technical and process support—in other words, organizations that have the most sophisticated software organizational infrastructure. I predict that we’ll see a concentration of professional engineers in organizations that have achieved higher SW-CMM levels. This will reinforce the phenomenon that Harlan Mills observed 20 years ago: good developers tend to cluster in effective organizations and bad developers in ineffective organizations.

For the rest of this chapter, see the book, After the Gold Rush.

This material is (c) 1999 by Steven C. McConnell. All Rights Reserved.

Email me at