Subject: RISKS DIGEST 10.41 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 18 September 1990 Volume 10 : Issue 41 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Software Certification (Michael J. Konopik, Joe Marshall, Jerry Glomph Black, Martyn Thomas, Phil Windley, GaryFostel, Theodore Ts'o) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]GET RISKS-i.j ; j is TWO digits. Vol summaries in risks-i.00 (j=0); "dir risks-*.*" gives directory; bye logs out. ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. The most relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Fri, 14 Sep 90 17:02:21 PDT From: zzz@NISC.SRI.COM (Michael J. Konopik) Subject: applicability of software curricula In his discussion of software certification in RISKS 10.38, Theodore Ts'o made a sweeping condemnation of the MIT software engineering curriculum. He argued that it sidesteps the real world by teaching "completely dated" languages and not teaching the use of any commercial SE tools in the classes. I never thought I'd stand up to defend anything about MIT; but I wanted to add some more context on the issue for those who weren't exposed to this curriculum. It would seem that Theodore was so intent on blocking out the Liskov philosophy of programming that he didn't hear the statement of the purpose of 6.170. In fact, the same teaching strategy was applied in 6.001 and 6.004, as well. None of those classes taught their material using any "real world" languages or tools. The professors all gave pretty similar disclaimers that went something like this: We're not here to teach you C. We're not here to teach you how to use any particular set of tools. On the contrary - our purpose is to teach you a framework of fundamental concepts. And if we use commercial tools and languages to teach it, many of you will spend too much time concentrating on those things instead of the material itself. The languages and tools we use are in themselves functionally complete. They are tailor-made to facilitate teaching the material. And when you finish the class, you will be able to apply what you learn to whatever environment in which you find yourself working, without being biased to any one specific set of languages or tools. After the exam for 6.001 (in '82), I met Sussman on the 9th floor of NE43 to express my appreciation for the course. I told him that I had really grown to like Scheme in a big way, and I asked him if it would be possible for me to obtain updates to the language manual as it evolved in the next few years. His stern answer was "Absolutely not!" I pressed him - "Why??" His answer has stuck with me. Quote not quite exact: "You completely missed the point, Mike. Scheme was just a teaching tool. So what if you can write programs in it? After 6.001, you should be able to pick up half a language in half a week. And for almost any program you want to write after this, there will be at least three other languages out there that are more suitable for writing the program than Scheme will be. Forget the language - remember the material!" Heck, the assembler they taught when I took 6.004 didn't even exist, except on paper!! But it still conveyed the ideas they wanted to teach pretty well. Regarding CLU and Liskov's "religion": Theodore's assessment sounds a little bit extreme. We had the evils of globals preached to us, too. But the point was made that programmers should avoid using globals WHENEVER POSSIBLE; because for one thing, it's usually cheaper to pass around one-word pointers to large objects than to have to manage a huge heap of globals. We were also force-fed the top-down programming methodology. But one of our lectures had a mention of how it usually works in the "real world", calling it something like the Iterative Method (design - code - test - loop). The "One True Way" was just the idealized classroom method. Maybe they don't discuss that anymore, or maybe Theodore punted that particular lecture... To make a short story long - sure, they didn't teach a lot of reality in MIT's SE curriculum. But in my opinion, what they did teach was of much greater long-term value. For the concepts being taught apply to more than just the software development environment that is preferred at the time. Teaching everything with "current" models runs a risk of rapid obsolescence. -Mike ------------------------------ Date: Sat, 15 Sep 90 10:26:13 PDT From: Joe Marshall Subject: The need for software certification I am against certifying software professionals. I agree with Mr. Ts'o that professional certification would lead to a "guild". Like Mr. Ts'o, I think that my style of programming is near perfect and I always write nearly bug-free code. Like Mr. Ts'o, I am afraid that I would be excluded from the "in-group" for reasons that have little to do with my outstanding ability to write bug-free code on the first pass with no expressed design goals. But before we start excluding undesirables from our midst, we should look at what we are trying to accomplish. I think most of us would agree that we want to have computer systems that reliably accomplish their stated purpose (leaving aside the ethical questions of what purposes are worthy). In order to scientifically engineer such systems, we need a way to measure the reliability. This would include examining failure modes, assigning probabilities to them, and evaluating the undesirability of such failures. To some extent, this is a black art in the realm of software engineering. I know that I haven't been trained in this. If we could devise some measure of reliability of software, then we could easily determine which design methodologies are best suited to producing reliable software. Then, any person who could not or would not follow these methodologies would find it difficult to make a career in software engineering. The CLU group at MIT made a concerted effort to address some of the issues of software reliability. While many people found the "religious" atmosphere of the class repressive, I think the basic principles behind the religion have merit and cannot be dismissed as "dated" or "archaic". It was developed in the 70's, long after teletypes and punch cards. "Modern" languages (C++) and "modern" operating systems (Unix) have yet to address the goals of such "arcane" languages such as CLU and ALGOL and "arcane" systems such as Multics. I understand that MIT does not offer an accredited computer science program. ~JRM ------------------------------ Date: Sat, 15 Sep 90 10:43:48 EDT From: black@ll-null.ll.mit.edu (Jerry Glomph Black) Subject: Re: The need for software certification (T'so, RISKS-10.38) Subject: Software Workers Guild/Union >I am against the "certifying" of software professionals. ... I fully agree, all we need is another champion of excellence rivalling the public teachers' unions. One of the last bastions of intellectual and economic freedom & independence is in the software industry & craft. Trash this enterprise as well, and we all might as well start cracking open our 'Dick & Jane' Japanese primers. Now I know why so many computer nerds espouse Libertarian dogma, it is their appreciation of their relative intellectual & economic freedom compared to most stifled workers. In most endeavours, creativity, originality, and excellence is stomped on by some actual or de-facto regulatory or union body. TYTSO's description of the Software Engineering course at MIT sounds like another tentacle of the octopus. Global variables are anathema? How about pointers to data structures? Jerry Glomph Black, black@MICRO.LL.MIT.EDU (Independent software guy) ------------------------------ Date: 17 Sep 90 14:02:54 GMT From: Martyn Thomas Subject: Re: The need for software certification In RISKS 10:38, Theodore Ts'o gives many reasons why he believes that ceryifying software professionals is a bad idea. Certification undoubtedly brings problems - but so does absence of certification. The criticisms he makes would apply, mutatis mutandis, to certifying medical practitioners and lawyers, yet many societies have decided that such certification is desirable. On balance, I believe that some limited certification is desirable, for staff who hold key positions of responsibility on projects which have significance for society. (This is an imprecise phrase, which is intended to include safety-critical systems, systems involving national security, systems involving substantial sums of public money, and so on. I have no doubt that an adequate mechanism for defining such projects could be devised). Many countries (including the UK) already have such mandatory certification for other engineers. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk ------------------------------ Date: Mon, 17 Sep 90 10:27:22 PDT From: Phil Windley Subject: Re: The need for software certification Theodore Ts'o makes several objections to certifying software professionals: [...] Couldn't these same objections be made to professional certification in other engineering disciplines? I will grant that what constitutes "good engineering practice" is much better defined in mechanical engineering than it is in software engineering and thus it might be easier to develop a test for mechanical engineering competency than it is for software engineering. What is the history of this? Does anyone know when the first professional engineering certifications were done and what kind of trouble this caused for the discipline trying to figure out what to put in the test? Even so, having to come up with such a test would certainly create a lot of discussion, much of it worthwhile. The second point is, I think, more easily dealt with. I don't think that professional certification has led to a "unionization" of engineering. And certainly no one would contend that the fact the a person is certified means that their designs are error free. So why would this occur for software engineers? Most engineering activities that affect public safety (in areas where certification is done) must (by law) be reviewed and approved by a certified engineer. This approval say, in effect, "This design conforms to good engineering practice for my field." Has anyone on the list been involved in a large software project that affected public safety where such a review was or was not done (and will they admit it ;-). Phil Windley, Department of Computer Sciencem University of Idaho, Moscow, ID 83843, Phone: (208) 885-6501 ------------------------------ Date: Mon, 17 Sep 90 15:19:38 EDT From: fostel@eos.ncsu.edu Subject: RE: The Need for Software Certification As an old alum of both the MIT undergrad computer science program and an early version of Liskov's software engineering course, my eye's perked up when I saw Ts'o rip it assunder in the course of analyzing the need for "software certification". I also teach an undergrad course on software engineering here at NCSU, and perhaps that somewhat colors my perspective. Although the title of the post by Ts'o was "software certification" the subject matter seemed to be more focused on "programmer certification". While I share much of the trepidation that motivates Ts'o, my concerns are somewhat different. An analogy might help. In the construction industry, there are a number of different classifications of individuals by their training, function, experience and so on. Two that are well understood are "architect" and "master carpenter". To some degree, an architect can generally do many of the things a master carpenter can do, and vice versa, and to some degree, each probably thinks that their own slant on the problems of construction cuts to the core of the "real" problems in construction. But, is the distinction between the two one which is unwise and a danger to the building industry and more generally to society at large? Clearly No. It may, however, be a danger to a skilled carpenter who wishes to move into the domain typically populated by architects. Even though that carpenter may in fact have talent and experience which is superior to many architects, it is not in the interest of society to freely allow such fluidity in job descriptions and job certifications. Conversely, the architect may find their actions on a job site to be limited by lack of certification as a carpenter. (My brother is an architect and this is a very frustrating problem for him at times.) The reason for the limitation of the roles of the architect and the carpenter is the underlying assumption that without an individual going thru a certain process of training and examination, that individual can not quite be trusted to perform certain actions that could bring risk to the public as a result of an error made in that capacity. Precisely the same sorts of reasons can be used to justify the existence of certified skills within the domain of software engineering, and no doubt it is only a matter of time until this is done. Ts'o is concerned that this will lead to a limitation of an individuals ability to work on certain projects and of course this is precisely the intent. Perhaps Ts'o would be more content with this arrangement if the prevailing trend in software engineering were towards the flamboyant and powerful style of development at which he is no doubt quite expert. After all, in this way he could be more confident that the software controlling the 747 he flew in or the nuclear powerplant he lived near, was not built in a plodding fashion by people who believed in flowcharts and pseudo-code, or by people who bothered to design a system before they began to build it, or by people who had their designs validated by independent experts before wiring potentially erronious assumptions into hundreds of thousands or millions of lines of code. I would have little fear of living in a house hammered together by my brother the architect, nor would I be concerned if Norm the carpenter (From PBS This old house series) designed the layout for my house. But I'd not set foot in a 50 story building built without consultations from CERTIFIED structural engieers, with blueprints thouroughly reviewed by CERTFIED architects, and construction performed by professional, CERTFIED contractors. The issue is scale. I trust Ts'o or most other competant programmers to develop a simple data base program, word processor, compiler, or a host of other applications programs. (Though I might not trust them with my capital without a track record as "certified moneymakers".) But large, complex software systems have problems that are not readily visible in the small scale applications. In my software developement courses, I commonly tell students that the methods which will be required of them are not necessarily the most efficient methods for the class project required of them. For the trivial sort of work I can require of students in a semester, there is really no need for comments since they will remember everything all the time, and there is no need for requirements analysis since they will usually be both customer and producer, and there is no need for formal design since they must begin work on the code before I have a chance to provide formal feedback on their formal design, and so on for most of the techniques of software engineering. On the other hand, as the size of the problem grows, and the customer becomes distinct from the development, and the development staff becomes fluid, and the effort expands in numerous other dimensions towards bewildering complexity, the methods I prescribe are in fact neccesary...but that must be taken as an article of faith. There is no way for students to actually participate in a 5 year development of million line system in a few months of class time. It's unfortunate that more students, esp the bright and energentic ones like Ts'o, do not understand that. Perhaps equally, it is unfortunate that the professors, like Liskov, do not find ways to make these students understand it. Will programmers be certified? Definitely. How will they be certified? By the processes and standards used by the leaders of the industry when certification finally becomes inescapable. When will certification begin? Probably shortly after a disaster involving software that was not up to snuff and was produced in questionable fashion. Will it be a source of frustration to software developers? Of course. Will it make the public safer? Hopefully. Gary Fostel, Dept of Computer Science, North Carolina State University, Raleigh, NC, 27695-8206 fostel@eos.ncsu.edu 919-737-3195 ------------------------------ Date: Fri, 14 Sep 90 13:56:55 -0400 From: Theodore Ts'o Subject: Re: The need for software certification >Surprisingly, version control (such as RCS) was never discussed at all. >I suppose the theory was that if we designed everything in pseudo-code >from scratch, we would never need to rewrite or revise any of it, so >version control was considered important. I will leave it to the Gentle v not >Reader's judgement as to whether or not you can teach a reasonable >Software Engineering in today's environment, when several people can be >changing files on a networked filesystem, without at least mentioning >version control. Err.... oops. I should have proofread this a bit better. The sentence makes a lot more sense with the negation in there..... Sorry about that! - Ted ------------------------------ End of RISKS-FORUM Digest 10.41 ************************