The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 10 Issue 41

Tuesday 18 September 1990


o Software Certification
Michael J. Konopik
Joe Marshall
Jerry Glomph Black
Martyn Thomas
Phil Windley
Theodore Ts'o
o Info on RISKS (comp.risks)

applicability of software curricula

Michael J. Konopik <zzz@NISC.SRI.COM>
Fri, 14 Sep 90 17:02:21 PDT
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.

The need for software certification

Joe Marshall <>
Sat, 15 Sep 90 10:26:13 PDT
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.


Software Workers Guild/Union

Jerry Glomph Black <>
Sat, 15 Sep 90 10:43:48 EDT
>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)

Re: The need for software certification

Martyn Thomas <>
17 Sep 90 14:02:54 GMT
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:

Re: The need for software certification

Phil Windley <>
Mon, 17 Sep 90 10:27:22 PDT
Theodore Ts'o <tytso@ATHENA.MIT.EDU> 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

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

RE: The Need for Software Certification

Mon, 17 Sep 90 15:19:38 EDT
   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                919-737-3195

Re: The need for software certification

Theodore Ts'o <tytso@ATHENA.MIT.EDU>
Fri, 14 Sep 90 13:56:55 -0400
>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
>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

Please report problems with the web pages to the maintainer