bryan@sierra.Stanford.EDU (Doug L. Bryan) (11/09/89)
>`Just once I'd >`like to see a homework assignment in some CS course be something like >` >` "add features X and Y to this 60,000 software system (which the >` students have never seen before) and turn it in next week". > >Would someone (or more) please address why this is not done. (1) Inertia. Computer science, like it or not, is young and not very well understood. Academia, like it or not, is very old and deliberate. Look at how many major universities have computer science departments. Not information science, not data processing, but computer science. Then look at how many of the universities have the computer science department in the school of engineering. Not the school of science, not the school of linguistics, but the school of engineering. I think you'll see that computer science is still working toward settling itself into academia. (2) Zero mass -> zero inertia. If computer science is young, then software engineering has yet to be born. The aforementioned assignment using the 60,000 line system is desired by software engineering educators, not computer science educators. Only once software engineering exists as a sort-of-understood disciple can it begin to find its place in academia. (I could go on and on about why IMHO s/w eng doesn't exists, but this isn't the place for that thread.) Other minor reasons why the above assignment isn't assigned include: - it's pretty difficult to grade, - there aren't many decent, easy to obtain, public-domain 60,000 line systems for educators to chose from, and - students hate it (yes, pleasing the customer is a part of even education). Flame me if you must, doug Disclaimer: I work for a university. I have tried to teach software engineering at this university. I once gave an assignment like the one being discussed and the students hated it. My course was canceled.
dgh@unify.UUCP (David Harrington) (11/10/89)
In article <371@sierra.stanford.edu> bryan@sierra.Stanford.EDU (Doug L. Bryan) writes: > > >(I could go on and on about why IMHO s/w eng doesn't exists, but >this isn't the place for that thread.) I, for one, would like to hear your HO about why s/w eng doesn't exist. It is extremely relevant to my work, managing the development group for a large, complex product in the 60K source lines class. When I hire new engineers, the main thing I look for is exposure to methodology and experience with large, complex systems. In new grads, what I have to settle for (happily, in most cases) is coursework exposure to methodology, which isn't too bad, and energy and enthusiasm. In experienced engineers, I generally have to settle for relevant experience, but "seat of the pants" mentodology. I'd like to have the best of both. (I realize that the deterioration of methodology skills is something industry, not academia, needs to address.) Anyway, since I've started this here, if it isn't the place for the thread, where is it? > >Disclaimer: I work for a university. I have tried to teach software >engineering at this university. I once gave an assignment like the >one being discussed and the students hated it. My course was >canceled. That's unbelievable.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/11/89)
From dgh@unify.UUCP (David Harrington): >>(I could go on and on about why IMHO s/w eng doesn't exists, but >>this isn't the place for that thread.) % % Anyway, since I've started this here, if it isn't the place for the thread, % where is it? comp.software-eng is the appropriate place. Bill Wolfe, wtwolfe@hubcap.clemson.edu
johnson@p.cs.uiuc.edu (11/16/89)
I think it is common for CS courses to have students modify programs instead of writing them from scratch. This is common in O.S. courses; Tanenbaum's new book and Comer's book both use this approach. It is also common in compiler courses, although the standard "dragon" book does not have a lab set up and so everybody has to do it themselves. I use this technique in the OS course I teach even though the book I use (by Deitel) doesn't include code. The programming language course that we teach uses a new book by Sam Kamin that uses a set of related interpreters. The project in the assembly language and machine organization course usually involves as much program modification as program writing. Even the "Intro to programming for engineers" course involves a lot of program modification, at least when I teach it. Thus, most of the software courses here (U. of Illinois at Urbana-Champaign) require program modification as well as program writing. Note that none of the programs are even close to 60,000 lines. That was a silly suggestion. It takes a skilled programmer to make a non-trivial modification to a program of that size within a few weeks. I find that it takes most grad students a couple of months before they can make changes to my 50,000 line Smalltalk compiler, and it is much better written than most software, at least in the top 10% in terms of readability and changeability. One of the advantages of getting an MS here is the opportunity to work on some large projects and to learn how to navigate through a large system. I believe that reusable software in general, and object-oriented programming in particular, are the wave of the future. This means that it is even more important to teach students how to read softare and to modify systems than it has been in the past. The typical Smalltalk programmer spends 3/4 of the time reading code, and the lines of code written per day are not particularly high. However, the functionality per day is extremely high because so much code is reused and not rewritten. This argues that it is more important to read code well than to write code well. One of the things that interests me is how to write programs so that they are easy to read. Knuth's work on literate programming is interesting, though after reading TeX I think I disagree with him on the best way to present a program. Programs should be presented top-down, even though I am a firm believer in writing them in all directions at once. Describing a program is a lot like presenting the proof of a theorem. You say what you are going to do (i.e. specify the program), break the work up into pieces that are small enough to understand (lemmas or subroutines) and finally pull it all together. The order that you present a program is determined primarily by what is easiest for the reader to understand, not the order that the program executes or the order that the routines were written. I've gotten a bit off my main topic, which is that it is becoming more and more common to have students read code as part of a class. It will become even more common in the future. I think of Abelson and Sussman's book, which is making a big impact on how computer science is taught, and uses program modification very heavily. It indicates who CS will be taught in the future. Ralph Johnson