lfoard@wpi.wpi.edu (Lawrence C Foard) (02/19/89)
I would like to present the opposite side of the argument about hackers. I generally program in the hacker style. i.e. No flowcharts or writting code out on paper. Use comments only where needed. Allow programs to evolve. 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 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. For example an extra ten minutes of coding can add a feature that will save hundreds of hours of time. 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. 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. -- /----------------------------------------------------------------------------\ | My opinions are violently objected to by my employer. I was fired last year| | but they forgot to remove my account. Lawrence Foard (entropy) | \----------------------------------------------------------------------------/
tada@athena.mit.edu (Michael Zehr) (02/19/89)
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 generally program in the hacker style. i.e. >No flowcharts or writting code out on paper. >Use comments only where needed. >Allow programs to evolve. >[...] >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. >[...] >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. For the type of programming you're doing, that sounds perfectly reasonable. But that certainly isn't the "software industry." Have you compared the success rates of hackers completing a 10 man-year project vs. non-hackers completing the same project? Most software projects can not be done by a single person. They're simply too big. Saving time by not writing things down only works if one person can remember the entire structure of the program. And what if the client insists on a functional spec before paying money, so they know what they're getting? The software industry does use the method you describe -- it's called proto-typing. You take a couple of months and put together something that has most of the front-end of the system, and a bit of the back end, but without any real data or whatever. Then you let the client look at it and see if that's what they want. i'm sure there will be lots of other replies, so i'll end this one now... -michael j zehr
vincent@ditsyda.oz (David A. Vincent) (02/22/89)
in article <899@wpi.wpi.edu>, lfoard@wpi.wpi.edu (Lawrence C Foard) says: > I would like to present the opposite side of the argument about hackers. > I generally program in the hacker style. i.e. It strikes me that what Lawrence presents isn't a terribly good definition of the hacker style. I'm sure many non-hackers program in this 'hacker style' too. At this stage I'd rather not get into an argument about the merits or otherwise of hackers & hacking. But I would like to pin down just what it is. Let's look at how Lawrence sums up the 'hacker style'. > No flowcharts or writting code out on paper. I don't think you have to be a hacker for this to be part of your style. Flowcharts are a no-no for structured programming anyway; writing code out on paper is probably dying too as editors improve. I think it would be true to say instead that hackers simply don't like to create abstract models (like flowcharts or pseudocode) of their programs. > Use comments only where needed. This really says nothing, since it's a matter of opinion where comments are 'needed'. Naturally, hackers and non-hackers have different opinions on this subject. Comments only get put in when someone thinks they need to be. > Allow programs to evolve. This is pretty vague. Hackers don't *only* allow programs to evolve; otherwise hackers would always be modifying existing programs and never starting new ones. On the other hand non-hackers don't always *prevent* program evolution either. After all, putting suitable comments into a program ensures that the program can be more easily modified later, which surely encourages program evolution. My favourite definition of hacker is 'compulsive programmer' (due, I think, to Weizenbaum (sp?)). But here is another, perhaps better, definition of 'the hacker style': * No flowcharts, writing code out on paper, specification, or indeed any abstract modelling of code outside of the author's skull. Just get on with it. * Don't let comments obscure the author's understanding of the author's code. * As long as their authors are around, allow programs to evolve. David A. Vincent vacation student, CSIRO Division of IT ACSnet: vincent@ditsyda.oz Post: GPO Box 1710-T Phone (w): +61 2 887 9383 Hobart TAS 7001 FidoNet: 3:670/700 Australia ---------------------------------------------------------------- Irrationality is the square root of all evil. - D R Hofstadter
hsd@uvacs.cs.Virginia.EDU (Harry S. Delugach) (02/25/89)
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
lfoard@wpi.wpi.edu (Lawrence C Foard) (02/27/89)
>.... > > * No flowcharts, writing code out on paper, specification, or indeed > any abstract modelling of code outside of the author's skull. > Just get on with it. > > * Don't let comments obscure the author's understanding of the > author's code. > > * As long as their authors are around, allow programs to evolve. > >.... Thats pretty much what I said any ways. But I guess I should have included the compulsive programmer part in the definition to. This is fairly important to the hacker style of programming, you have to enjoy it and be interested in what you are doing for it to work correctly. If you are interested in what you are doing you don't need to fill out reams of forms to show that you haven't been reading playboy all day. Although more planning is needed for big projects, I don't think 100's of pages of spec's helps much, a large number of informal meetings between programmers would work much better. I don't think managerial attempts to enforce good programming style are a good idea this acts only to impose arbitrary restrictions. It is much better for some one to learn good programming style from experience rather than have a set of arbitrary rules to follow. Before some one starts programming for money they should have enough experience to know what they are doing. P.S. Our mailer seems to throw up on quite a few addresses so I wasn't able to get mail back to several direct replys I received. P.P.S. I can program better than I can write. -- /----------------------------------------------------------------------------\ | My opinions are violently objected to by my employer. I was fired last year| | but they forgot to remove my account. Lawrence Foard (entropy) | \----------------------------------------------------------------------------/
djones@megatest.UUCP (Dave Jones) (02/28/89)
Pity the poor "hacker". He does the job. He makes it work. Then
people say, "But you didn't go about it the right way. It's sure
to cause horrible trouble later on."
What to do?
Form your own startup company; bank a few million for yourself;
and face the impending doom with equanimity!
...
Pity the poor computer "scientist". He pretends to know how
to do things that nobody knows how to do. His projects slip,
month after month. But that's okay. He had a design, with Gant-
charts, and circles and arrows, and man-month projections. It just
needed a few "revs". Rev 14 still has bugs. People say he must have
done it wrong.
What to do?
Become a professor; ship no product; and never be wrong again!