neff@Shasta.STANFORD.EDU (Randy Neff) (04/15/88)
------ The Cynic's Guide to Software Engineering ------
------ an invitation to dialogue, starting with the personal view of ------
------ Randall Neff @ sierra.stanford.edu ------
------ April 13, 1988 part 4 ------
------------------------------------------------------------------------------
Software Engineering Education
The basic problem is that collectively, we do not know how to solve the
"Software Engineering Crisis". Quoting Fred Brooks, "There is no Silver Bullet"
So we really don't know what to teach (or how). This is my overall
impression of the book _Software_Engineering_Education:_The_Educational_Needs_
of_the_Software_Community edited by Norman Gibbs and Richard Fairley, which
was the report of a conference at the Software Engineering Institute in
Feb, 1986.
I feel that a Software Engineering program needs both a masters degree and
Ph.D degrees along with a very large component of research into the problems
and possible solutions, since we currently don't have a Silver Bullet. One
major problem is finding qualified faculty; SE is not a dignified topic at
some CS departments and faculty should have had several industry
programming jobs. (Can you believe that at some schools, individuals are
teaching how to program that have never been outside of academia or written
a program used by other folks!) Ask your Software Engineering Education
expert: "How many lines of delivered code did you personally write last year?"
The key focus of a Masters program of software engineering should be an
apprenticeship working on a real, large software project, in all phases of
the lifecycle myth. I suggest that a complete software engineering programming
environment be the continuous project for all of the students over the years.
It would be designed to be portable, run on several different hardware /os
platforms and would be given away to anyone asking. It would go with every
graduating student. It would be treated just like a real software product from
a real company, including support, new releases, bug fixes, manuals, training.
The system would start out small, say just the database/configuration/version
management; then be expanded with syntax directed editors, graphic editors,
regression testing, reuse libraries, application generators, whatever the
current fad happens to be.
Students would enter the school at the support end, working on maintenance;
then move into minor enhancements, then major ones; finally, as a team
propose, specify, design, construct, integrate and test a new or replacement
subsystem. Students (and lots of outsiders) would really be using the
system, it is not thrown away; it gets better every year and teaches
everything. The whole point is that the system will greatly enhance the
programming productivity of the students along with being a teaching and
research vehicle.
Classes: basically there are two things that you need to teach. Enhanced
vocational skills and the foundation for future advances. The foundation
is typically mathematical and formal, with perhaps some crystal balls visions.
History: (The Mythical Man Month and more)
of computers and programming languages
famous horror stories
early attempts at SE
State_of_the_Practice (what allegedly goes on now)
contemporary mythology of software development, lifecycle, costing models
version control/configuration management
integration/testing
top down design
twenty five different design methodologies
reuse, application generators
batch compilers and tools
Languages
Fortran, Cobol, Simula, Apl, Snobol
Algol 60, Pascal, Modula-2, C, C++
Ada, Concurrent C
Common Lisp, Prolog, latest functional programming fad
Smalltalk, object oriented
State_of_the_Art (what is happening in universities)
Highly interactive user interfaces
Incremental compilation, loading, debugging, interpretors
Formal languages and methods, specification analysis, incremental program
proving, tasking specification and monitoring
Syntax directed editors
State_of_the_Future (problems and possible solutions)
Standardization, why, how to, validation of, leverage, portability
Distributed environments
Parallel programming
Super programmer tools (ie a correct Pascal compiler in eight hours)
Professionalism, responsibility, licensing
Future architectures for checking correct program execution
New paradigms of software development
The next generation of programming languages/environments
Programming without languagesgerhart@donner.SW.MCC.COM (Susan Gerhart) (04/15/88)
In article <2677@Shasta.STANFORD.EDU>, neff@Shasta.STANFORD.EDU (Randy Neff) writes: > ------ The Cynic's Guide to Software Engineering ------ > ------ an invitation to dialogue, starting with the personal view of ------ > ------ Randall Neff @ sierra.stanford.edu ------ > ------ April 13, 1988 part 4 ------ > ------------------------------------------------------------------------------ > Software Engineering Education Many facets of your software engineering education plea are incorporated in Professor Walt Scacchi's System Factory project at the University of Southern California. In the SF, large groups of students work cooperatively for several months to redo components of a software engineering environment taking advantage of new technology or extending the environment's capabilities. A massive amount of software has been generated, including some novel approaches to maintaining software documents in hypertext and to module interconnection languages. Articles have appeared in: IEEE TSE, March 1987; 1986 Hawaii Systems Conference; the SoftFair proceedings, 1985; Education and Computing, 1987; just to cite a few. A technology transfer perspective appears in MCC TR STP-309-87. Scacchi's net address is SCACCHI@vaxa.isi.edu. +-------------------------------------------------------------+ | Susan Gerhart, MCC, 9390 Research Blvd., Austin TX 78759 | | (512)338-3492 gerhart@mcc.com | |{gatech,harvard,pyramid,seismo}!ut-sally!im4u!milano!gerhart | +-------------------------------------------------------------+
johnson@c10sd1.StPaul.NCR.COM (Wayne D. T. Johnson) (04/16/88)
In article <2677@Shasta.STANFORD.EDU> neff@Shasta.stanford.edu (Randall Neff) writes: > >Languages > Fortran, Cobol, Simula, Apl, Snobol > Algol 60, Pascal, Modula-2, C, C++ > Ada, Concurrent C > Common Lisp, Prolog, latest functional programming fad > Smalltalk, object oriented > I noticed a lack of any Assembly language in there. I feel a good understanding of the hardware of ANY machine (hopefully a somwhat industry standard one) and its associated object/assembly code is very useful. I've seen too many SEs who know nothing of the machine code, trying to fix their software by "twiddeling"* when the simple answer is staring them in the face if only they knew how to read a dump. * twiddeling - making small changes to code to see if that might fix it. This includes adding occasional chicken tracks (print/printf/write etc. statments that mark the trail the software took). -- Wayne Johnson (voice) 612-638-7665 NCR Comten, Inc. (internet) johnson@ncrcce.StPaul.NCR.COM or Roseville MN 55113 johnson@c10sd1.StPaul.NCR.COM The comments stated here do not reflect the policy of NCR Comten.
karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60sC) (04/16/88)
In article <2677@Shasta.STANFORD.EDU> neff@Shasta.stanford.edu (Randall Neff) writes: > >The key focus of a Masters program of software engineering should be an >apprenticeship working on a real, large software project, in all phases of >the lifecycle myth. I suggest that a complete software engineering programming >environment be the continuous project for all of the students over the years. ... >It would be designed to be portable, run on several different hardware /os >platforms and would be given away to anyone asking. It would go with every >graduating student. It would be treated just like a real software product from >a real company, including support, new releases, bug fixes, manuals, training. >The system would start out small, say just the database/configuration/version >management; then be expanded with syntax directed editors, graphic editors, >regression testing, reuse libraries, application generators, whatever the >current fad happens to be. > Sounds great. Personally, I would be interested in a Masters of Software Engineering. The project I would like to work on would be some GOOD software development tools. What a great project for this purpose. Research could be done in the theory of the process of software development as well as implementation. Students would have a reason to take it with them, and actually using something you wrote is one of the greatest learning tools ever. Karen A. Cate Tektronix Inc, Beaverton OR tektronix!amadeus!karenc -OR- karenc@amadeus.LA.TEK.COM
carson@tron.UUCP (Dana Carson) (04/16/88)
In article <2677@Shasta.STANFORD.EDU>, neff@Shasta.STANFORD.EDU (Randy Neff) writes: > programming jobs. (Can you believe that at some schools, individuals are > teaching how to program that have never been outside of academia or written > a program used by other folks!) Ask your Software Engineering Education > expert: "How many lines of delivered code did you personally write last year?" Unfortunitly true in most fields. Shouldn't be encourged though. > The key focus of a Masters program of software engineering should be an > apprenticeship working on a real, large software project, in all phases of > the lifecycle myth. I suggest that a complete software engineering programming > environment be the continuous project for all of the students over the years. > It would be designed to be portable, run on several different hardware /os > platforms and would be given away to anyone asking. It would go with every > graduating student. It would be treated just like a real software product from > a real company, including support, new releases, bug fixes, manuals, training. > The system would start out small, say just the database/configuration/version > management; then be expanded with syntax directed editors, graphic editors, > regression testing, reuse libraries, application generators, whatever the > current fad happens to be. > Students would enter the school at the support end, working on maintenance; > then move into minor enhancements, then major ones; finally, as a team > propose, specify, design, construct, integrate and test a new or replacement > subsystem. NO. There is too much feeling that maintence is where you stick the new/incompatent people already. Start with write the fully defined routine. Write this small set of routines, design a small subsystem, etc. Then when they show that they know how a subsystem works risk letting them work on it. Also teach maintence. How to restructure code, deduce algorithms from uncommented source, check for globals that cause unexpected linkages, old language standards etc. -- Dana Carson Westinghouse uunet!umbc3!tron!carson
dickey@ssc-vax.UUCP (Frederick J Dickey) (04/18/88)
In article <3396@zeus.TEK.COM>, karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60sC) writes: > In article <2677@Shasta.STANFORD.EDU> neff@Shasta.stanford.edu (Randall Neff) writes: > > > >The key focus of a Masters program of software engineering should be an > >apprenticeship working on a real, large software project, in all phases of > >the lifecycle myth. I suggest that a complete software engineering programming > Sounds great. Personally, I would be interested in a Masters of Software > Engineering. The project I would like to work on would be some GOOD > software development tools. The following comments are not intended to be serious criticisms of the above, but ... It strikes me as interesting that most of the software engineers I know would, if given the opportunity, prefer to work on the development of SE tools rather than work on some application program. I am certainly sympathetic to this view, it's what I would rather do. However, it seems paradoxical to me. The reason why SE is called engineering is because it is supposed to be focused on solving other peoples' problems using "engineering" techniques. Most customers do not view SE tools as their problem. I agree that one needs tools to do the job, but tools seem to be used as an excuse for ignoring what SE is all about: solving someone else's problem. Thus, I tend to view discussions of tools (at least in the context of SE) as symptoms of a malaise rather than elements of a solution. I also wonder sometimes if the metaphor "tool" is the wrong metaphor. d
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (04/19/88)
In article <1865@ssc-vax.UUCP> dickey@ssc-vax.UUCP (Frederick J Dickey) writes: >It strikes me as interesting that most of the software engineers I know would, >if given the opportunity, prefer to work on the development of SE tools rather >than work on some application program. (Hi Fred!) I observed that too when I was at Boeing, but I figured it was because the applications were not always the most admirable ones. Cruise missile targeting, sub killing, electronic warface all sound exciting, but the reality of DoD software is pretty sordid, and one can't help but be bothered by the fact that the software is intended to be the brains behind devices that kill other people (not a political flame, just an observation). This brings up a general issue having to do with applications in general. Software engineering is billed as mostly value-neutral with respect to the application software, and SE ethics is pretty much concerned only with personal responsibility for quality and perhaps the short-term effects of automation on human workers. Some people in the CPSR are keen to have SEs consider long-term overall societal and environmental effects of their work, such as whether the code in more sophisticated remote controls on TVs leads to excessively sedentary lives :-), or whether home computer games lead to the breakup of families (no :-) - check out CPSR newsletter about three issues back). So - the question: does an ethical software engineer work on whatever the boss says, or only on those applications or parts of applications that are considered "good"? stan shebs shebs@cs.utah.edu
pete@wor-mein.UUCP (Pete Turner) (04/20/88)
In article <1865@ssc-vax.UUCP> dickey@ssc-vax.UUCP (Frederick J Dickey) writes: >It strikes me as interesting that most of the software engineers I know would, >if given the opportunity, prefer to work on the development of SE tools rather >than work on some application program. I am certainly sympathetic to this view, Perhaps software engineers show such strong interest in working on software tools because they have experienced or sense a lack of the tools needed to do software engineering. I find that a very large proportion of the time that I spend on any project is devoted to developing the tools I need, because existing tools are too limited - they impose unreasonable preconditions on the methodology to be used. This is a problem which may never be solved entirely, since I see little evidence so far that anyone has much of a handle on what software engineering is. I would suggest that software engineers, and potential software engineers, make good use of their Master's thesis effort when they apply it to an area which they will probably only be able to address in an ad hoc manner in the "real" world of tight schedules and the bottom line.
jiml@uwslh.UUCP (James E. Leinweber) (04/25/88)
There is a simple reason why one would spend a goodly portion
of ones time on a project writing tools, even in the presense of a
supportive systems environment. As was mentioned in one of the
programming pearl's columns (if memory serves), building a large
software project is analogous to building a large structure like a
bridge or skyscraper. You need some scaffolding along the way.
Software scaffolding consists of tools to manipulate your source,
manage configurations, generate test data and analyze test runs, etc.
Even though the kind of scaffolding you use on a bridge or a software
project may be quite standard and built from re-used arts, each
project requires assembling some afresh.
Jim Leinweber jiml@uwslh.uucp jiml%uwslh.uucp@cs.wisc.edu
...!{rutgers, ucbvax, ihnp4, ...}!uwvax!uwslh!jiml
State Laboratory of Hygiene @ Univ. of Wisconsin - Madison; (608) 262-8092
--
Jim Leinweber jiml@uwslh.uucp jiml%uwslh.uucp@cs.wisc.edu
...!{rutgers, ucbvax, ihnp4, ...}!uwvax!uwslh!jiml
State Laboratory of Hygiene @ Univ. of Wisconsin - Madison; (608) 262-8092