Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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
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
>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)
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
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 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
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
>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
Please report problems with the web pages to the maintainer