Subject: RISKS DIGEST 10.41

Subject: RISKS DIGEST 10.41
REPLY-TO: [email protected]

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 [email protected], with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to [email protected].
TO FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>GET RISKS-i.j <CR>; j is TWO digits. Vol summaries in
risks-i.00 (j=0); "dir risks-*.*<CR>" 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: [email protected] (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 <[email protected]>
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: [email protected] (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, [email protected] (Independent software guy)

------------------------------

Date: 17 Sep 90 14:02:54 GMT
From: Martyn Thomas <[email protected]>
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: [email protected]

------------------------------

Date: Mon, 17 Sep 90 10:27:22 PDT
From: Phil Windley <[email protected]>
Subject: Re: The need for software certification

Theodore Ts'o <[email protected]> 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: [email protected]
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 [email protected] 919-737-3195

------------------------------

Date: Fri, 14 Sep 90 13:56:55 -0400
From: Theodore Ts'o <[email protected]>
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
************************