tarry@sirius.UUCP (Steve Tarry) (02/04/89)
It has long puzzled me why there are so few masters degree programs in Software Engineering and even fewer (none that I know of) bachelors programs. Consider what universities offer our engineering brethren: Students interested in research study, for example, chemistry, math, or physics; those interested in building products get a degree in, e.g., chemical engineering, electrical engineering, or civil engineering. Of course, the engineering students must learn a foundation in the underlying sciences, but they also learn how to apply science to real commercial problems. In the world of software, there would seem to be similar educational needs: Computer science for those exploring frontiers of the software art, and software engineering for (the much greater number of) people who are building software products. In article <67605@ti-csl.CSNET>, myjak@home.csc.ti.com (Michael Myjak) writes: > ...I have often wondered how well pure CS people perform at > tasks (like software engineering ?) that require a moderate (to > in-depth) level of hardware understanding. Exposure to the hardware side of computing is but *one* aspect of what distinguishes a software engineering education from a computer science education. In illustration of some other aspects, I'll mention a few of the features of the Masters of Software Engineering program that I recently completed (at the now-defunct Wang Institute of Graduate Studies): --Two years of work experience with software was required for admission; students fresh out of a B.S. program were not accepted. --Thorough grounding in computer science fundamentals (e.g, discrete math and data structures) was required. As one who got his B.S. in the Old Days, I found meeting the admissions requirements almost as valuable as the degree program itself. Then the first course in the program was APPLICATION (emphasis mine) of Formal Methods, such as classifying real problems according to complexity theory. --Group work on projects was required. In particular, instead of an individual thesis (which was not an option), one had to develop and deliver two software products with teams of fellow students. --Exposure to non-technical aspects of software development was an essential part of the degree. For example, a course in software project management was required, not to mention the lessons learned in the group projects. --There was a heavy emphasis on techniques (e.g., structured analysis vs. Jackson's methods) and tools (from spreadsheets to compiler generators). Hey, it's tough being a cheerleader for an alma mater that no longer exists! But there are other programs with a similar slant (such as at the various institutions where the former Wang Institute faculty have landed). And enterprising students can bend traditional computer science programs in this direction. Use your electives to take the courses required of "real" engineers (Electric Circuits, Thermodynamics, Statics, ...). Work as a programmer summers or between degrees or in a co-op program. Develop a program useful to others (including the users manual!) as part of your thesis. -- Steve Tarry ...dartvax.dartmouth.edu!sirius!tarry Northern Telecom, Network Supports Systems Div., Concord, N.H. (for now)
jerbil@cit-vax.Caltech.Edu (Stainless Steel Gerbil [Joe Beckenbach]) (02/06/89)
> Steve Tarry ...dartvax.dartmouth.edu!sirius!tarry > Northern Telecom, Network Supports Systems Div., Concord, N.H. (for now) In his article <530@sirius.UUCP> Steve Tarry writes: >It has long puzzled me why there are so few masters degree programs in >Software Engineering and even fewer (none that I know of) bachelors >programs. Consider what universities offer our engineering brethren: >Students interested in research study, for example, chemistry, math, >or physics; those interested in building products get a degree in, >e.g., chemical engineering, electrical engineering, or civil engineering. >Of course, the engineering students must learn a foundation in the >underlying sciences, but they also learn how to apply science to >real commercial problems. It frankly puzzles me that people are puzzled at the lack of masters and bachelors programs for Software Engineering. Why? To my mind, this profession of computer programming is simply FAR TOO YOUNG!! As I and several people at the USENIX conference agreed in informal gabfests after the paper presentations, there is simply too little 'real formal content' to justify a large amount of learning. I mean, look at this profession and compare it to another profession; I'll use architecture, since my father is an architect and I grew up surrounded by the tools and some of the culture of that profession. Architecture began with building simple little huts. With a few simple tools and an observant mind, someone could put up a decent dwelling. We're talking about something that anyone from mid-Stone-Age on could and can do. Larger buildings, such as agricultural storage silos and cistern systems could be designed by one person, but implementation and maintainence required multiple people. And very few first designs of anything work; that's why architects needed to look at the works of the previous generations in making their buildings-- see what worked in the past, and adapt it. Once mathematics and physics got together, architects began acquiring tools to analyze structure stresses, materials' limitations, and other data. This allowed further design and weakened the reliance on trial-and-error and tradition in the course of designing buildings over an architectural group's career. These tools were nurtured, strengthened, and extended by the training process of the student architect; over the course of the centuries the simple compass-and-straightedge-and-intuition approach received the augmentation of mathematics for structural stress analyses, water delivery, air circulation, and so on. The more complex the profession, the longer it takes to train a new member up to the minimum acceptible standard. For architects in the Middle Ages, I believe that the apprenticeship period covered the same amount of time, but had less material to pass on, and a lower rate at which it could pass on the essentials of the craft. I think you can see the parallels I am about to draw. Anyone with access to the right materials can craft toy programs on a machine, and one with an observant mind can do something useful consistently. The larger projects require more discipline, training, and background; but still a well-organized person can go a long way towards finishing the smaller stuff, and getting the people to start a larger project. However, the fundamental difference is that we have had computers for about a generation or so. Architecture has had several millenia. 'Software Engineering' has the benefit of the past experience of architecture's methods, and the other engineering disciplines as well-- but we simply have not had the time yet to become a coherent profession. This touches on many central points of 'Computer Science' debates: should we be licensed? what should be the ethics of the profession? what is a proper term for what we do? Back to 'Software Engineering' in particular, it is still possible and quite commonplace for a major project to be haphazardly given, produced, distributed, and maintained. And, in general, no one cares one way or the other, since the goods are somehow being delivered. But is, in the main, software being engineered, to a rigor even partly approaching other fields? No. Is computing actually firmly grounded as a science? Yes, but not in most jobs which are associated with 'Computer Science'. So, my view of it all is that we have a smattering of those who are professionals in the sense that most architects, doctors, and the like are professionals; some pretend to it, others strive for it, and some ignore it entirely. [I could give some examples in each category, but that's overkill.] Architecture, civil engineering, and other disciplines have had this stage; 'social science' and economics are doing so as well, and are in slightly different stages of the process of acquiring the rigor, scholarship, and discipline necessary to be a profession in the same class as the current civil engineers, architects, and doctors. >In article <67605@ti-csl.CSNET>, myjak@home.csc.ti.com (Michael Myjak) writes: >> ...I have often wondered how well pure CS people perform at >> tasks (like software engineering ?) that require a moderate (to >> in-depth) level of hardware understanding. I would say it depends on the programming skill of the CS guy. Mind you, to me, real CS has heavy use of mathematics, and need not understand the hardware or hardware interface to either be a software engineer or to provide insights which could be best expressed in hardware. I cite Prof. Chuck Seitz' work leading to the Caltech Cosmic Cube, and all its derivative works. [Aside: these are all based on computational nodes with separate memory for each CPU, and communication between nodes by passing messages between nodes along wiring.] Besides, is it not true that the hardware simply allows the theoretical von Neumann machine to be expressed and used as something that approaches a reasonable speed? >Exposure to the hardware side of computing is but *one* aspect of what >distinguishes a software engineering education from a computer science Glad to see someone points out a major distinction! >education. In illustration of some other aspects, I'll mention a few >of the features of the Masters of Software Engineering program that I >recently completed (at the now-defunct Wang Institute of Graduate Studies): > >--Two years of work experience with software was required for admission; > students fresh out of a B.S. program were not accepted. Lets the student understand and find the common core of what he had been taught-- this should already be part of the BS program!!! >--Thorough grounding in computer science fundamentals (e.g, discrete > math and data structures) was required. As one who got his B.S. in > the Old Days, I found meeting the admissions requirements almost as > valuable as the degree program itself. Then the first course in > the program was APPLICATION (emphasis mine) of Formal Methods, such > as classifying real problems according to complexity theory. Again, another hole in most BS programs. > >--Group work on projects was required. In particular, instead of an > individual thesis (which was not an option), one had to develop > and deliver two software products with teams of fellow students. Another hole missing in BS programs. > >--Exposure to non-technical aspects of software development was an > essential part of the degree. For example, a course in software > project management was required, not to mention the lessons learned > in the group projects. Ditto. > >--There was a heavy emphasis on techniques (e.g., structured analysis > vs. Jackson's methods) and tools (from spreadsheets to compiler > generators). Ditto. What I am seeing is very much like what is going on with the 'social sciences': it is in the descriptive phase of its existence, about where physics was before Sir Isaac Newton's generation. What seems to be happening is more like a semi-technical general-education degree rather than a real embryonic 'software engineering' or 'computer science' discipline (looking as a whole). To fill the current gaps as a student: >Use your electives to take the courses required of "real" engineers >(Electric Circuits, Thermodynamics, Statics, ...). And _not_ just EE! Spread it around. And add math as well. An engineer without the proper mathematical tools is not as worth hiring or working alongside. >Work as a programmer summers or between degrees or in a co-op program. This is HIGHLY recommended by most; I think it should be REQUIRED. >Develop a program useful to others (including the users manual!) as part >of your thesis. Again, recommended, though most of the seminal theses I've seen have been still at the level of first prototype. BEFORE YOU MAIL ME A FLAME OR POST ONE: This is my own opinion, based on my own observations, the conversations I have had with other in several fields, professions, and walks of life. I am in no way, shape, or form, attempting to insult the integrity, intelligence, or reputation of any individual, group, or organization. If I offend, please consider why, start correcting the problems, and then think before flaming. I'd rather have a well-thought-out roasting over the coals than a flash-in-the-pan flame. Joe Beckenbach CS Dept asst system manager joe@cit-vax.caltech.edu jerbil@csvax.caltech.edu BS CS 1989, currently filling in the gaps in my BS program with more real work -- Joe Beckenbach joe@csvax.caltech.edu Caltech 256-80, Pasadena CA 91125 Should programmers be licensed? Yes, but not yet: once we've got it together enough to be a profession.
coggins@coggins.cs.unc.edu (Dr. James Coggins) (02/07/89)
In article <530@sirius.UUCP> tarry@sirius.UUCP (Steve Tarry) writes: > >It has long puzzled me why there are so few masters degree programs in >Software Engineering and even fewer (none that I know of) bachelors >programs. There is a good case to be made that Software Engineering is not an appropriate baccalaureate field of study and that the professional M.S. as you described Wang Institute's M.S.E (R.I.P.) is the only reasonable way to go. Wang's entrance requirements helped to ensure that the MSE was not just an advanced hacker's degree. (yech, what a concept.) There is, in fact, a strong case that can be made to the effect that software is OVERemphasized in current B.S. CS programs at the expense of problem-solving, analytical skills, mathematics, and CS theory. The question to ask is, "How much of our undergrad program will be obsolete in 10 years?" Too many places must answer with too high a figure. Students are better served in the long run by not getting a CS(E) undergrad degree - especially the narrow, inflexible, hacker-driven mush being pushed by the accrediting agencies. >Of course, the engineering students must learn a foundation in the >underlying sciences, but they also learn how to apply science to >real commercial problems. See this month's CACM for yet another attempt at defining what a CS curriculum is. Since the underlying science is so ill-defined, the engineering discipline sits atop sand. It is appropriate for intensive study only by those who really need it immediately - people working in the field who, one hopes, have outgrown their hacker phase and are ready to adopt the mantle of professionals. In other words, Software Engineering remains most appropriate for a professional M.S. program. --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department UNC-Chapel Hill Software Engineering Laboratory Bawss Chapel Hill, NC 27514-3175 (UNC COMP 145/227) ---------------------------------------------------------------------
sue@murdu.OZ (Sue McPherson) (02/09/89)
In article <530@sirius.UUCP> tarry@sirius.UUCP (Steve Tarry) writes: > >It has long puzzled me why there are so few masters degree programs in >Software Engineering and even fewer (none that I know of) bachelors >programs. I read Steve Tarry's article on the wonders of an MS in Software Engineering and the shortage of MS programs with some confusion. I certainly can't speak CS degrees in the US but in Australia I did a BSc with a Comp Sci Major, a three year course which had the following content; 1st Year Comp Sci - Fundamentals, Information Structures, Algorithms & Systems Chemistry Physics Pure Maths 2nd Year Comp Sci - Hardware/Low-level stuff, Numerical Methods & Systems Pure Maths Statistics 3rd Year Comp Sci - Advanced Data Strcutures, Real-Time systems, Database Management, Theory of Computation, Computers & Society AND Software Engineering I chose the "software stream". Other "theoretical", "Numerical" and "Hardware" subjects were available. There was a free choice from the subjects offered in the science faculty available in 1st and 2nd year. In regards to the contents of the MS program, I would like to make the following comments; >--Group work on projects was required. In particular, instead of an > individual thesis (which was not an option), one had to develop > and deliver two software products with teams of fellow students. We did two group projects, a specification and a software product (My group developed a Word Processor, others did forms entry systems, database systems..) >--Exposure to non-technical aspects of software development was an > essential part of the degree. For example, a course in software > project management was required, not to mention the lessons learned > in the group projects. Part of the Software Engineering subject >--There was a heavy emphasis on techniques (e.g., structured analysis > vs. Jackson's methods) and tools (from spreadsheets to compiler generators) In SE we covered design methodologies. Tools such as compilers, compiler generators, editors and DBMSs were covered in various subjects, we were never introduced to spreadsheets but perhaps that was because most people can figure that out by reading a few pages of a manual. I'm sure that the course content of the MS in Software Engineering is worthwhile, what worries me is that it Steve seems to be suggesting that these things aren't in a normal CS degree. The MS seems very useful for engineers/accountants/other graduates who find themselves in programming but for anyone who has done a good CS degree it would seem superfluous. Perhaps now that the supply of CS trained programmers is starting to meet the demand, there is no longer the same need to "re-train" other graduates? Sue McPherson Consultant, Software Contracts Group University of Melbourne sue@murdu.mu.oz
myjak@home.csc.ti.com (Michael Myjak) (02/10/89)
>> I wrote: >> ...I have often wondered how well pure CS people perform at >> tasks (like software engineering ?) that require a moderate (to >> in-depth) level of hardware understanding. Steve Tarry writes: >Exposure to the hardware side of computing is but *one* aspect of what >distinguishes a software engineering education from a computer science >education. In this case I was referring to a systems software engineering; i.e. one who is applying the skills and techniques of software engineering to a hardware related application. Granted Steve, it *is* an application, but one that all computer scientists should be versed in; otherwise they would just be programmers. :-) The original point of discussion which started all this was: "Who is better qualified to develop software that requires moderate to in-depth level of hardware knowledge and software engineering, a BSCS or BSEE?" The second point I would like to quibble about is that a "software engineering education" is something that all computer scientists should have been exposed. IMHO, software engineering is not a separate discipline, but it may be an area of specialty for a phd dissertation. Bill Wolfe writes: > The field of software engineering is INDEPENDENT of the realm of > application; [...] Any application area can > benefit from the utilization of software engineering principles, > but software engineering is in no way tied to any particular area > of application. Exactly where is the "field" of software engineering? is it in Boise? :-) Many industrial locations call any body which authors programs a software engineer. While in many instances this may be true, I do not believe that it is completely accurate. A BSCS (CIS?) may graduate without ever having had a single course in software engineering and yet industry still refers to them as software engineers. Scott G. writes: >A software engineer is the typical term for someone with a BSCS. see? Bill then goes on to make an incorrect statement: > It DOES cover: [...] > Modern Programming Language Features (Ada) ... This is incorrect because Software Engineering is independent of, and in no way related to a *particular* language, its features, or its associated environment. While it is true that some languages lend themselves to software engineering techniques better than other languages do, software engineering and ADA are mutually exclusive. Quoting from _Software Engineering: A Practitioner's Approach_ by Roger S. Pressman; McGraw-Hill, 1982.: Software engineering "... techniques deal with software as an engineered product that requires planning, analysis, design, implementation, testing, and maintenance." To sum this up, Software Engineers are people who apply software engineering techniques to their programming tasks. -- Always mount a scratch monkey --