Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!decwrl!labrea!Shasta!neff From: neff@Shasta.STANFORD.EDU (Randy Neff) Newsgroups: comp.software-eng Subject: Cynic's Guide to SE, part 2 Message-ID: <2586@Shasta.STANFORD.EDU> Date: 17 Mar 88 19:25:31 GMT Reply-To: neff@Shasta.UUCP (Randy Neff) Distribution: na Organization: Stanford University Lines: 88 Keywords: metrics, software engineering ------ The Cynic's Guide to Software Engineering ------ ------ an invitation to dialog, starting with the personal view of ------ ------ Randall Neff @ sierra.stanford.edu ------ ------ March 17, 1988 part 2 ------ ------------------------------------------------------------------------------ My Software is Better than Your Software, So There !! One of the serious flaws in Software Engineering is there is no standard methodology for determining that one software program or methodology is "better" than another. This makes it hard for me to say "Software Engineering" with a straight face. The only available measure is to perform a benchmark task and time it with a stopwatch. But there is no way to compare the abstract "goodness" of programming languages, operating systems, editors, windowing systems, etc. There is no metric for functionality, or usability, or user-friendliness, or capability, or reuability, or complexity, or just plain "goodness". This is unlike other engineering fields; say electrical engineering. There a audio power amplifier can be judged by its cost, power output, distortion, frequency response, crossover, phase delay, power in, heat disipated, and weight. These are all numeric quantities that most EEs can measure; there are no subjective biases or opinions expressed. Together, the values form an absolute "goodness" based on electrical engineering practice. In constrast, in the software arena, we have feature lists, platitudes, grandious claims that result in giant flame wars with all of the rationale of religious dogma and persecution. Let me give you an example: The programming language Ada ... (now admit it, already your internal flames have started) while not perfect, was designed to assist with portable software, reusable packages, well defined interfaces, a build-in tasking model, and all compilers are validated against a standard definition. Now X windows was designed to be portable, with reusable libraries, well defined interfaces, a kludgy tasking model built by passing procedure pointers, and there is no C standard and no compiler validation. So the question is "why wasn't X windows written in Ada?" (Ouch, Ouch, here come the flames.... ARGH!) The design goals of Ada (which the language comes close to) seems to sort of match the goals for X windows. Instead, X windows is written in a language that is at least fifteen years old, has no standard or compiler validation, and has to be stretched to provide the pseudo tasking and pseudo inheritance. I already know some of the flames: Ada is terrible, Ada compilers cost money, we don't know Ada, we don't want to learn Ada, Ada compilers generate bad code (without trying any compilers), C is the only and best programming language, we inherited old dusty deck code, Ada is too long a name to type, breaking a program into logical modules and well defined interfaces is hard, etc. So don't bother sending me any flames! [Also note I do not want to critice the X window project people. They made the correct choice when aiming for the least common denominator systems. However, interfacing other languages to Xlib is non trivial.] Now the point of this article is not the answer to this particular question, but to show that one of the failing of software engineering is there is no rational basis for answering that sort of question. The same sort of questions arise over operating systems, editors, languages, tools, windowing systems, etc. Why is spending money to buy bit mapped windowing workstations a great idea over buying glass teletypes into a timeshared main frame? (It is, isn't it?) A second example: suppose that I work for a computer manufacturer. I go to the top level management and propose a new hardware project. I want ten people for two years and three million and at the end there will be a new implementation with twice the performance and half the manufacturing cost. Now compare if I go the same management and propose a new software project. I want ten people for two years and three million and at the end there will be a compiler for a new language with twice the ___blank___ and half the ___blank___. Now what goes in the blanks so that I can sell the project? I have been involved in religious wars about text editors (EMACS, vi, EDT, several home built), and about operating systems (UNIX 4.3 bsd, UNIX other, VMS, CMS, TOPS-20, SAIL, Apple Macintosh, DG AOS), and programming languages (Pascal & various extensions, C, MAINSAIL, Ada, Lisp & variations, Prolog, Fortran, APL). And they all seem to boil down to "I like this and you're wrong!". A message in one of the newsgroups says something like: "we want to improve programmer productivity. Does anyone know of any tools for VMS?" My internal response (admittedly bigoted) was "first drop braindamaged VMS and switch to ULTRIX or 4.3!". It seems to me, that given a set of requirements, for example, text editing; there should be an software engineering methodology to determine what is the "best" program for the job. The same should apply to operating systems, languages, windowing systems, and other tools. Once such a methodology was in place, then it could guide the incremental improvement of those programs. Engineering, it seems to me, is based on universally agreed methods of measurement. All Software Engineering has now is a stopwatch.