Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!uflorida!haven!uvaarpa!virginia!uvacs!hsd From: hsd@uvacs.cs.Virginia.EDU (Harry S. Delugach) Newsgroups: comp.software-eng Subject: Re: hackers Keywords: software Message-ID: <2999@uvacs.cs.Virginia.EDU> Date: 25 Feb 89 13:03:35 GMT References: <899@wpi.wpi.edu> Reply-To: hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) Organization: U.Va. CS dept. Charlottesville, VA Lines: 79 In article <899@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >I would like to present the opposite side of the argument about hackers. I appreciate your posting this, but your arguments leave me unconvinced. I have tried to indicate my points of disagreement. >I generally program in the hacker style. i.e. >No flowcharts or writting code out on paper. >Use comments only where needed. I thought hackers never needed comments anyway. :-). >Allow programs to evolve. You mean without any real design. >Atleast 50% of the code I have written has been for use on various research >projects. I believe allowing code to evolve has some important advantages over >working from specs. For example a typical project: >Person needs a program to do something. Quickly write code to do it. Show it >to them and ask what they would like added to it, suggest things that might be >useful and could be easily done. Repeat until satisfied. Clean up and optimize >the final code. Of course the complaint about this is that you have to make >changes in the code. But it has to be considered that you saved huge amounts >of time by not writting reams of paper work, and have also given the person As has been mentioned before in this newsgroup, the huge amounts of time you saved by not writing down what you did will probably cost someone else huge amounts of time later in trying to figure out/fix/modify what you did. >what they wanted instead of what they initially asked for. This is fairly >important since many people don't know what the computer can do for them. I agree with your point, but if you haven't documented anything, how does the person know the program really does what you tell them it does? For that matter, how do *you* know? It's easy to say the program works when you have no statement of what it's supposed to do, other than "keep the user happy". >For example an extra ten minutes of coding can add a feature that will save >hundreds of hours of time. Whose time? If poorly documented, or poorly designed, that extra "feature" may introduce new bugs, may be difficult to maintain (even by another hacker), and may not be re-usable in its original form. >I have seen figures from the software industry and they are abismal, only 10% >of programs are ever successfully finished. Most hackers I know have from 75% >to 90% success. This is a huge amount of money considering that a hacker can >also produce this code with out the cost of 10 paper shufflers. How do you measure your success? Do you mean your program eventually ran? This is how CS101 students generally measure their "success". Does it mean the user finally quit complaining? Maybe he just got fed up with your making changes. And what kind of programs are you talking about? The software industry figures are for software *products*, which are much tougher to produce than programs. Programs get the job done, but *products* are documented, maintained, robust, reliable, etc. Although some good programs can be written as you suggest, I believe that producing a good *product* requires you to apply some software engineering principles. >Another fact that is often over looked is people who enjoy what they are doing >do a much better job than those who don't. Given the choice of working for a >company that requires you to fill out a form for every change in the code or >Mc Donalds, I would pick Mc Donalds any day. FLAME ON! Here's my analogy for software engineering: Hackers probably think that if you already know how to cook a hamburger, working in a McDonald's shouldn't be too much different. Next time you're in McDonald's, look around. There's a lot more going on besides just cooking hamburgers. McDonald's knows how to produce a *product*. FLAME OFF! -- Harry S. Delugach Dept. of Computer Science, Univ. of Virginia, Charlottesville, VA 22901 U.S.A. INTERNET: hsd@cs.virginia.edu BITNET: hsd2x@virginia UUCP: ..!uunet!virginia!uvacs!hsd CIS: 72727,2363