rbl@nitrex.UUCP ( Dr. Robin Lake ) (04/06/88)
This is a compendium of fact and comments replying to a number of recent articles discussing software engineering styles and how they could/should be taught and applied. Background: I developed and directed two graduate programs for a decade. I also have visited at least 3 or 4 college campuses each year since leaving academia, either as a site visitor or for industrial liaison or recruiting. I often now face REAL software engineering problems on a day-to-day basis. Being long in the saddle and grey in the beard, let me share some experiences with you. 1.(FACT) The GENERAL state of software engineering education is poor. However, there are singular examples where dedicated stable faculty, a good faculty/student ratio, and a coherent PROGRAM can transform a generally poor program into an excellent one. (EXAMPLE) Observed at Enormous State University. Hundreds of undergrads in CS program. Several optional curricular tracks. One track deliberately developed with small student/faculty ratio (about 2:1 !!), relatively stable faculty, strong interest in teaching, good (but not great) computer resources. Contrast with "usual" ESU approach of huge classes, uncoordinated curricular track, high student/faculty ratio. Observation: first group was superb!! There was only one student I would not immediately consider hiring. Second group were code-hacking. Cut and try. No design, no forethought. Largely no idea WHY they were coding what they were coding. (ADDITIONAL PROOF) Our own program, as measured by the positions attained by the graduates 5 years after their M.S., worked. Student/faculty ratio about 5:1, not great computer resources. Design emphasized to the EXTREME from the beginning of the curriculum. Used top-down design, successive refinement, what Brad Cox came to call Software ICs* (but a decade before [* As mentioned by D. Jones in Message-ID: <421@goofy.megatest.UUCP>] we ever heard of Brad). Students largely hated the discipline of formal, rigorous design IFF they had programmed before. Novices (professionals in non-computer fields) accepted it better. Both groups came to appreciate it as they had to solve real problems. Thanks to a National Library of Medicine Training Grant, this program was well funded and had the freedom (funds) to provide a stability that I have not seen in many CS programs. It was NOT based in the CS dept. 2. (FACT) The largest block to introducing either a new technology or a new (software engineering) methodology into industry is the skill set of the existing staff. (NON-PROOF) I suppose some Industrial Psychology student could get a Ph.D. on this one. This 'fact' comes from observation of several large organizations (Fortune 100's) over about 8 years. For whatever reasons, a 'culture' grows around certain technologies/methodologies --- a technical support base gets established; managers make the same decisions their predecessors do because the same 'environmental' truths prevail; and anything new has one heck of a time making it thru the door. "How can we handle that? We're too short-staffed to handle what we already know how to do!" Note: I am not referring to our own organization --- but to ones where my former students work and try to bring in the structured disciplines, CASE, UNIX, Macintosh, etc. etc. 3. (SUGGESTION) A software engineering organization needs a Tsar --- a manager who works with his/her staff to select a methodology, ordains that that methodology be followed, retrains the existing staff accordingly, reviews staff efforts on a weekly basis to be sure the methodology IS followed, then kicks ass and takes names if it isn't. This need not be oppressive in spite of the severe way I've stated it. The daily work of design and programming teams certainly should be cordial and fearless --- but some shock therapy is necessary to break out of the depression of current software development non-methods. ALSO: In: Message-ID: <1583@ur-tut.UUCP> msir_ltd@ur-tut (Mark Sirota) writes: > To get around this, people have suggested writing 10,000 line > programs, or continually working on the same program for 4 years. > This is fine; it closely mirrors what actually happens out there in > the programming world. However, I really don't think it will ever > happen in colleges; these things are really too hard to manage. > I'd disagree. DESIGNING 10,000 line programs maybe. But coding should be in small, re-usable modules. The student should graduate with a personal toolbox of modules which have been used and re-used in a number of applications. (Remember the ball peen hammer you made in high-school machine shop --- for those of us who grew up in the Rust Belt.) (Of course, if your toolbox only contains one hammer, everything looks like a nail!) >(2) Computer Science departments *shouldn't* be teaching programming > skills anyway; leave that to the Software Engineering department. > ... deleted for brevity > Why not have Computer Science/Software Engineering? > (Hardware Engineering exists too; it's usually called Computer > Engineering, which I don't think is really very fair.) > Amazing --- It turns out that the VERY SAME structured design disciplines can be used for both Software and Hardware. Pause a moment and think how that might be used in a CS/SWE/CE curriculum. :=} Best paths: decvax!mandrill!nitrex!rbl mandrill.CWRU.EDU!nitrex!rbl -- Rob Lake {decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl