Articles

---

Do You Have a License to Drive That Mouse?

Dave Parnas has written extensively on many aspects of software engineering and recently has written in favor of the licensing and certification of software professionals, which he believes is, in principle, as necessary as the certification and licensing of doctors, lawyers, hairdressers and other professionals. He believes strongly that the coverage of academic programs for software professionals is often spotty and inconsistent. Parnas is Director of the Software Engineering Programme, Department of Computing and Software, Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada.

In one recent paper called "Licensing and Certification of Software Professionals" [Parnas, D.L., "Why Software Developers Should be Licensed," Dimensions, Vol. 22, No. 3, Professional Engineers Ontario, May/June 2001, pp. 36-39.], Dave Parnas specifically addresses the question, "What knowledge should be required of those who are licensed or certified to develop critical software?" His answer: the principles and concepts that should be essential for software engineers go far beyond merely knowing how to use a particular piece of software, and knowing various programming methods, languages and software development techniques. They also require an understanding of basic science and traditional engineering that is not included in a typical Computer Science programme. Parnas also argues that computer scientists are not necessarily qualified to develop critical software products, because they often have gaps in their knowledge; the lack of standardization in the relatively young field of computer science has resulted in a situation where there is no single fact or technique that is known to every computer science graduate. His conclusion is that neither computer science nor traditional engineering programs typically provide all the knowledge that is necessary for the creation of a competent software engineer. Licensing and/or certification are needed to help the public to identify competent practitioners.

UBIQUITY: In your paper "Licensing and Certification of Software Professionals" you mention licensing and certification of doctors, lawyers, engineers, hairdressers, and so forth. Are those certification programs always happy developments and always effective?

DAVE PARNAS: No, there are frequent complaints about them; nobody would claim perfection. I would still argue that we're better off with them. Let's take doctors as an illustration. Some people say that doctors are too conservative and don't use natural medicines and things like that. They want to broaden the rules so that chiropractors and those who use natural remedies can practice as doctors and so that doctors can use some unconventional therapies. On the other side there are many people who notice that doctors make many mistakes, are often negligent and even incompetent. Those who note those failings want to tighten up the system. It's a compromise. I don't think doctors are perfect, and I don't think engineering is perfect.

UBIQUITY: What about hairdressers?

PARNAS: I've never had a complaint about a hairdresser. Others have. However, at least where I live, hairdressers seem to have some basic knowledge of hygiene and basic skills so that they do not cut ears when they mean to cut hair.

UBIQUITY: That's good, but thinking about hairdressers now, is it not the case that certification tends to be what could be called the lowest common denominator set of requirements? In other words, the main reason for the certification of hairdressers is not aesthetics or creativity but cleanliness.

PARNAS: Yes, the analogy in engineering is safety. You're not asking that every engineer be able to design the most efficient or the most elegant structure, but you are asking that they know enough about, let's say statics and dynamics, so that the bridge won't fall down. I think it is a minimum requirement, just like with architects. There are good architects and there are others. But at least the majority know the fire regulations. The architect who is managing our current building project is far from perfect, but he does understand why certain doors need closers and others do not need them.

UBIQUITY: What do you think is the basic distinction that ought to be made in terms of the design of a curriculum and the design of a certification program for a profession?

PARNAS: We have both up here in Canada. We have CEAB, the Canadian Engineering Accreditation Board, which is the Canadian equivalent of ABET. It has approved and accredited three software engineering programs, meaning that the graduates can take the shortcut to getting a license as an engineer. Graduates of accredited programs take fewer exams than those who are not. Theoretically, anybody can get an engineering license if they pass enough tests. However, if you come from an accredited program, there's a reduction in the number of tests you have to take. For accreditation, a curriculum must have a certain amount of basic science, a certain amount of basic math, a certain amount of design, etc. There are general rules that apply to all of the engineering disciplines. The rules allow the universities a great deal of freedom, but, in each discipline, there's usually something that everybody knows called a core body of knowledge. The visiting committees that accredit a programme check to see that the elements of that core have been taught and are understood. The accreditation criteria are demanding but they still leave each university a lot of freedom and each programme has its own unique flavor.

UBIQUITY: Describe the differences between the three software engineering programs.

PARNAS: The three programs accredited here are very different. One of them includes many previously existing courses, about equally split between existing computer science courses and computer engineering courses. (In Canada, computer engineering is basically electrical engineering with a digital emphasis.) Another program has almost no computer science in it. It is essentially a modified computer engineering programme. They took students who had already finished two years and added a few software courses for them. In contrast, the program at McMaster was designed from scratch and doesn't have any previously existing computer science or computer engineering courses in it. Each course in our programme was designed with an idea of what will these people really be doing and which things are most important to give them. The important technical courses were designed explicitly for this programme. Although the three programs are all very different, they all satisfy the minimal requirements. I would argue very strongly that although those requirements are important, they are not very constraining. Of course, I would argue very strongly that ours is the best of the three. If it weren't, I would change it to be more like the other two.

UBIQUITY: Is there some danger of developing a certification program that would be subject to the kind of criticism that some engineering degree programs are faced with -- namely that there's too much packaged into a program, that engineering students are run ragged with courses and requirements and don't have time to think?

PARNAS: Well, in 1958 I was saying that myself, because I was an engineering student then. I certainly have heard it. It does seem to me that the reputation on most campuses is that the engineering students have less free time than some others. I don't know whether that is true or not. All students seem to think that they are overworked even when they are not. However, engineering students do have much less choice in what they take, because we have to make sure that our students all take the courses that are required for accreditation. If we let one student get the degree without taking all of the required courses, then we could lose our accreditation. As a consequence of this, our engineering students don't have any technical electives until their fourth year. Our department also has a computer science program (administered through the science faculty rather than engineering), and they have choices right from the beginning. So, it seems that all of those rumors are true. I think they follow from the need to be able to look at the weakest path analysis that the accreditation board goes through. When they come, they try to figure out whether there is any path through this program to get to a degree without having all of the requirements, and if there is, then they fail the program. So you try to reduce the number of paths by leaving out any optional courses.

UBIQUITY: And you don't make exceptions?

PARNAS:No. We sometimes get students who will come to us and say, well, I had part of this in this course and part of this in that course, and I don't think I really need, for example, this materials course or thermodynamics course. Unless they provide evidence that they took an equivalent course, we make them take it anyway because otherwise we can't be sure that they meet the minimal requirements of our program.

UBIQUITY: Do you feel that there's any dissonance between the highly structured certification program you promote and the current educational fashion for customized, just-in-time, tailored education for a particular student who's going to do a particular kind of thing?

PARNAS: Yes, I do, but let's consider the medical analogy again. There are certain basic things you expect of a doctor. I don't want to go to a doctor who says, "You seem to have a blood problem, but I didn't take the blood course." And maybe she might not even notice that I had a blood problem. I think everybody expects every doctor to take the basics, and then specialize afterwards. That's the way I feel about engineers too. I've seen computer scientists, for example, designing air conditioning control systems without realizing that they will not be able to achieve their goals because they're not taking into account the heat flow into and out of the building. They would probably argue that an understanding of those topics is not part of computer science; I would agree, but I consider some knowledge of this essential for those who are going to identify themselves as engineers.

Student who do not want to take strict engineering programs should not be forced to do so, but they should not expect to be able to identify themselves as engineers. They make a choice either to meet the strict requirements or take another program. If they want a professional designation, they must meet the requirements. If they are willing to do without the designation, they can choose from many other programmes.

UBIQUITY: Your experience of doctors is different from my own. [I never met a doctor who wasn't focused on his own specialty.]

PARNAS: Well, here we get into a Canadian-U.S. difference. When I lived in the States, for example, I would often go to a specialist instead of going directly to my general practitioner. In Canada, the way the system is set up, you don't get to a specialist without a referral from a general practitioner. That's true in a lot of other countries too. I've lived in Germany, same thing. I've met lots of doctors who are general practitioners. The German word for them was house-doctor. They would actually come to your house. They have to be broadly educated and they have to know when to send you to a specialist. Similarly, engineers are expected to have broad knowledge, but can get a master's degree and specialize in the master's degree.

UBIQUITY: Are your expectations of engineering students accused perhaps of being too ideal?

PARNAS: I teach real students. I have some top students that come pretty close to meeting my hopes. And I have some bottom students where I really ask myself, should I let these guys out or not? I don't have any delusions that they're all the same and that they're all going to be like the top students. What we try to do is to set some minimal standards and not graduate a student who doesn't meet those minimal standards. We do lose a few students for whom the programme is too difficult and we are actually trying to tighten our requirements.

UBIQUITY: Well, you have an extremely structured program, and you certainly don't countenance a do-it-yourself, roll-your-own educational program. Is that an unfair assessment?

PARNAS: We thought that we had more knowledge about what was important in the field than a student would. There was a committee that put a lot of time into thinking about what our students would be able to use when they got out and what they would never use, and we decided to leave out what they would never use. We will change this program when we discover ways to improve it, but we won't abandon it in favour of a more liberal approach. The committee resisted a lot of currently popular, but not very substantive, approaches and focussed on things that we believe to be fundamental and of lasting value. Students often hear a new buzzword and want to take a course in it. If they want to do that in our programme, they must overload.

UBIQUITY: You've written that some other software programs show graduates how "to build the thing right," but don't help them learn how "to build the right thing." And you've made the point that for software engineers "to build the right thing in design, they must also be able to analyze some aspects of what goes on outside the computer." Then, as an example, you say, "It is possible to get a computer science degree without taking a course in physics or chemistry," and so forth. Now, one could also say it's also possible to get a computer science degree without studying law or medicine or biochemistry or sociology or management -- yet computer scientists and engineers are just as likely to interact with any of those disciplines. In other words, your examples could be considered very traditional. What would your comment be on this point?

PARNAS: Your question seems to equate computer scientists and engineers. I don't. Our software engineering graduates are particularly well qualified to work on traditional engineering tasks where software is now replacing older technologies. Computer scientists are often not prepared for such work. My examples were chosen as traditional engineering examples.

There are two levels of argument about our curriculum. The first is a discussion about the rigidity of the programme; it is what is called professional education, where you aim towards a certain area of practice and you're pretty strict with the students to make sure that they are qualified for practice. The second issue is, should they be engineers or should they be some other kind of professionals? At McMaster I'm now advocating a second professional program that would not be called software engineering; it would be called something like software development and would include more of those other things -- maybe something about law and the computer, and less traditional engineering material. They graduates wouldn't be called engineers, and wouldn't be eligible for licensing as engineers.

UBIQUITY: Because the difference in domains would require that?

PARNAS: That's right. What I'm saying is that there are two separable issues. If you were to identify to me a large area of practice where people should have knowledge in the area that you mentioned, I could design a professional program that made them qualified to work in those areas. Because we only have four years, they would no longer be qualified to do the engineering work that we've identified for the present program.

One of the things that we've proposed here at McMaster is to take a four-year program, say within engineering and science, and take any of the existing programs and add a fifth year of computer stuff. McMaster has programs like that in engineering now. For example, we have an Engineering in Society Program. They take the four years of material required for the accredited engineering program over five years. In the gaps that are created by spreading that over five years, they take courses in various aspects of societal issues and impact their engineering decisions have on society and so forth. We also have an engineering and management program that allows students to do mechanical engineering and management, for example. I don't see why we couldn't do mechanical engineering and software, physics and software, or sociology and software. I think that these could be valid educational programs too. What I would have to do is look around and see if there's a sufficient need for these people that our graduates would be able to work with in the area that we've prepared them for.

UBIQUITY: What have others had to say about your educational philosophy?

PARNAS: I think the most controversial things about what we did here is that we took the phrase "engineering program" seriously. We said if they're going to call themselves engineers, then they should be able to do those traditional engineering tasks that now require building and using software. For example, 25 years ago, when I learned about control systems, there was no software in a control system. Today there are software systems doing the same tasks. And 25 years ago there were many things that we did with very simple methods but today we use optimization algorithms because they do a much better job. That's why, for example, communication systems are so much better today than 25 years ago. There are many people who use the word "engineering" as if it means no more than "development". They have focus on programming and project management. These people think that our emphasis on physical systems is wrong.

UBIQUITY: What has been the reaction to your call for engineering licensing and accreditation?

PARNAS: The issues of licensing and accreditation are quite controversial. In Canada the CS chairs have taken a position that rejects the idea of strict standards for their programmes. They believe that this violates the concept of academic freedom. In fact, I think that they should be able to teach anything they want, but if they refuse what they call the engineering approach, they should not use the engineering designation. Academic freedom is not the right to confuse students. Graduates from those programmes do not have the right to identify themselves as engineers and should not be misled into thinking that they can. I am a strong defender of academic freedom, but an equally strong defender of clear and accurate labeling. The engineering designation is worth something because of the strict standards and it is destructive to use the designation but be unwilling to satisfy the standards.

UBIQUITY: Speaking of confused students, how do you introduce them to the different engineering programs that you offer so that they can make informed choices about their academic goals?

PARNAS: Our present programme is essentially what we might call software-intensive engineering. At McMaster, students come to the engineering faculty with the decision to be an engineer. They're given one year to try to decide which type of engineer they want to be. In that one year, they get several introductions to the different engineering programs and then they apply for the one they want. If they have good grades, they'll get their first choice. They may end up with their second, third or fourth choice if they're at the bottom of the class. I guess my point is, they're all people who decided that they want to be engineers, and the specialty we're offering now is software in addition to chemical, electrical or mechanical. There are many people who decide not to become engineers, but they still like computers. They might want to work on banking systems or maybe legal information retrieval systems or any one of other applications that our present students are not especially well prepared for.

UBIQUITY: Your own students would not be well-suited to such jobs?

PARNAS: The students that I have now, graduating from this program, would not be optimally prepared for those roles. They learn a lot about software design that is generally applicable and might be very useful in those jobs. However, if I were to design a program, say, for business and legal work, I would probably take out the thermodynamics course, for example, and teach more about such topics as grammatical inference and information retrieval in texts.

UBIQUITY: You don't see a problem in trying to design a single certification program for people who are going to be doing all kinds of different things?

PARNAS: In Ontario you get a license of an engineer, not as a mechanical engineer or a chemical engineer. But you are made aware of your responsibility not to practice in an area where you weren't educated. So if somebody is, let's say, a civil engineer, and they're given an electrical engineering problem, they're supposed to say "No, I can't do it." If they get a problem that's interdisciplinary, they're supposed to find a partner who's in the other discipline. We're just adding one more specialty. It's a broader specialty in some ways, because computers are used so broadly, but it's just one more specialty within that philosophy. The profession as a whole has debated the use of more restricted licenses but it is difficult to know where to draw the lines between the disciplines.

UBIQUITY: You've presented your ideas so lucidly that one is compelled to ask 50 percent of your colleagues in the computer science and engineering community apparently disagree with you?

PARNAS: That's a complicated question. I was on a task force that debated this and was amazed by a number of things. For example, many people made the argument that we don't know enough to write perfect programs, so we shouldn't do licensing. Well, my response was: we don't know enough to make perfect cars or perfect bridges either. Not one person who supported licensing believed that we could write perfect programs, so I felt this was a red herring. I couldn't tell for sure whether it was because some people really thought you only licensed in fields where you could do something perfectly, like hair cutting (even though that's not perfect either because I go to a barber shop where there's a good barber and a bad barber). So that was one part of it.

UBIQUITY: What were the other objections?

PARNAS: There were other people who objected to the fact that it was on a state-by-state basis. For example, you can't be a civil engineer in Texas if you're licensed in Alabama. You have to take the Texas exam or get some kind of temporary permit. We have that problem here too in Canada. But I think that is a whole separate issue and I don't know why it was raised. I think nationwide and maybe worldwide licensing make sense because what makes a good bridge in one country also makes a good bridge in another country. We have colder weather in Canada, but there are parts of the U.S. that have colder weather too. I don't see any reason for it to be on a state-by-state basis.

UBIQUITY: Are you optimistic that, in due time, your own view of certification will prevail?

PARNAS: Well, I don't know whether I'm optimistic or pessimistic. From what I learned in the early engineering ("propaganda") course you get about the profession, we have licensing and engineering because there were some horrible accidents where people made steam engines that blew up and people built bridges that fell down. Upon investigation, it was discovered that these people had no education in the topics that were important for those tasks. These disasters led to a licensing system that tries to eliminate at least the most flagrant cases of such incompetence. If we have similar disasters caused by software design incompetence, the public will demand a licensing system. Without public awareness of the danger caused by incompetent developers, we are unlikely to get any protection. Is it optimistic or pessimistic to say that in time we will have a licensing system for software developers? Personally, I would like to see the licensing before a major catastrophe but I think that is unlikely.

UBIQUITY: How can people in the profession be persuaded to go forward with licensing?

PARNAS: A lot depends on the wisdom and vision of people who are now in the profession. If they are able to look beyond their own well-being and comfort and admit that the lack of licensing and accreditation has led to the presence of many under-qualified people in our field, they will argue for a licensing system of some sort. If they only think of protecting their jobs and their status, they will oppose regulation of any kind. In fact, those who are least qualified will oppose it the most.

UBIQUITY: So the essence of the licensing issue is the need to assure public safety?

PARNAS: Yes. One way we might eventually get licensing is if we have a few engineering disasters and somebody asks, "Why was this person with absolutely no training in safety-critical soft-ware, or software of any kind, allowed to make a radiation therapy device that killed 30 people?" I think as long as people accept the really poor quality of software we have today and think it's somehow inevitable and don't realize that even today we can do better, it won't happen. It will take people not willing to accept that any more.