Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd From: rsd@sei.cmu.edu (Richard S D'Ippolito) Newsgroups: comp.software-eng Subject: Re: Theory vs. Practice in CS Education Message-ID: <5044@ae.sei.cmu.edu> Date: 21 Nov 89 17:32:05 GMT References: <880@dms.UUCP> <7044@hubcap.clemson.edu> <4251@pegasus.ATT.COM> <4979@ae.sei.cmu.edu> <6738@cbnewsm.ATT.COM> Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito) Organization: Software Engineering Institute, Pittsburgh, PA Lines: 99 In article <6738@cbnewsm.ATT.COM> leland.f.derbenwick writes: >Richard D'Ippolito appears to think engineering (specifically software >engineering) ends with high-level design. The engineering disciplines >apply all the way down to implementation details. I'm sorry that's the message you got. The original context of this discussion was what to add/change/emphasize in CS to teach software engineering. Several folks suggested that courses on compilers and operating systems were valuable to teach SE. I strongly disagreed, especially with the comments made about worrying what the compiler does with the code during the _design stage_, arguing that at that stage, engineering design is possible only with fully captured models. What is missing here is an understanding of the engineering method, precisely that thing which is _not_ taught in any CS/SE program. You will not get it by studying compilers and operating systems. >Needing to meet specified performance is common in all branches of >engineering. How one goes about that is part of engineering. >Why should software be different? You must differentiate between model performance and system performance. >For example, a chemical engineer who doesn't understand how spray >towers work could design one that's 99% fluid and 1% air. (Which >isn't a spray tower, it's occasional bubbles in a pot of fluid, >and it's _not_ going to work as intended!) A chemical engineer who doesn't understand spray towers is not an engineer; HOWEVER, understanding how to apply one is not the same as knowing how to design one. >> Architects are not doing architecture if they are worrying about how their >> designs are implemented at the beam and rivet level Architects and other >> engineers can only work effectively when the working models exist. How can >> there be working models when the lowest-level specifications are interpreted >> differently? The lowest-level components in engineering disciplines are >> truly standardized and portable. > >Very bad example. The Hartford Civic Center's roof collapsed (when the >place was empty, luckily) because "beam and rivet level", as understood >by the architects (and their CAD programs), didn't match the reality >of how things are put together. There was a misapplication of the correctly working CAD program in the description of the joint. The failure was due to sloppy engineering procedure (work not independently checked), not due to a lack of adequate tools and methods. This does not contradict my statement that the working models must (and did, in this case) exist. When will it be the case that the failure of a SW system makes more news than the success of one? >And people _died_ a few years ago (the multi-level pedestrian walkway >that collapsed) largely because an architect didn't properly understand >the "beam and rivet level". Architects routinely provide "detailing" >of how buildings are to be constructed. The detailing for the joints >to attach each level of the walkway wasn't feasible to build, so the >contractor used a feasible method that had only about half the strength >that the architect intended. Think about what you just wrote -- an architect specified a design for which he had no working model. That's not engineering, is it? Again, it makes news in other fields, but not in ours as it happens all of the time. >> >What if I just want to learn about lexical analyzers, parsers, etc. so >> >I can apply them to *other* areas? What about a little breadth in >> >education? ... >> >> Of course, as long as you realize exactly what you are learning and are not >> told that you are studying engineering. >> [...] > >That's like saying that a chemical engineering student who is learning >about how to design chemical reactors isn't learning engineering. No, it isn't like that at all. Learning about lexical analyzers and parsers is not the same as learning engineering design anymore than learning how to hammer nails into is learning how to design walls. Chemical engineers learn models in the form of unit operations. >And even the high-level portions of software engineering can be taught >(or at least practiced) in any course that involves software >development. A compiler course is no exception. And what are these high-level portions of software engineering? Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------