UH2@PSUVM.BITNET (Lee Sailer) (10/19/89)
In article <135300011@p.cs.uiuc.edu>, johnson@p.cs.uiuc.edu says: > >This is an incorrect impression. People have been building large >object-oriented systems successfully. This indicates that they must >have some sort of methodology, since large systems cannot be built >successfully without one. The problem is to determine their methodology. True, but what if their "methodology" implicitly includes that two or three of the lead programmer/designer/analyst types happen to be really, really, really smart? The existance of successful projects is not proof that a set of teachable skills and procedures exists for other people. >What is a methodology? A programming methodology is a way of programming. Yeah, but we need non-programming methodologies, too. I am thinking of Analysis and Design, User Needs specification, and particularly Project Management. For example, we need a way to estimate how much money we've spent so far, and how much more we are going to have to spend, and we need to be able to compute those estimates at periodic intervals. Furthermore, we need a way to bring new staff up to speed when our lead programmer gets the dream job at Commodore, and his two most-likely successors die in the car crash on the way back from helping him move. A note: In an Analysis and Design course I teach, the CS students often eventually comment: Gee. It never occurred to me before that someone has to decide what programs need to be written, and who should write them. I always just sort of took the program as a given. A problem I see with the OO Anything is that it blurs some of the traditional distinctions that the bean counters used to use. Another note: Shouldn't it be "method"? A discussion of methods might qualify as "methodology". Another note: B# over high C
johnson@p.cs.uiuc.edu (10/19/89)
I said >This is an incorrect impression. People have been building large >object-oriented systems successfully. This indicates that they must >have some sort of methodology, since large systems cannot be built >successfully without one. The problem is to determine their methodology. UH2@PSUVM.BITNET said >True, but what if their "methodology" implicitly includes that two or >three of the lead programmer/designer/analyst types happen to be really, >really, really smart? The existance of successful projects is not proof >that a set of teachable skills and procedures exists for other people. The point I was trying to make was the best way to develop a set of teachable skills and procedures is probably to study how sucessful people do it. Like all research approaches, this might not succeed, but it seems much more likely to succeed then the purely theoretical, "let's invent a methodology" approach that seems too common. If you agree with me then you will find one of the papers at OOPSLA'89 very interesting, because it studied how Smalltalk programmers did design. The authors were psychologists, not programmers. UH2@PSUVM.BITNET said >Shouldn't it be "method"? A discussion of methods might qualify as >"methodology". I agree completely, but unfortunately the CS community seems to have decided that a "methodology" is a way of doing something, not the study of ways of doing something. Ralph Johnson -- University of Illinois at Urbana-Champaign
UH2@PSUVM.BITNET (Lee Sailer) (10/22/89)
In article <135300012@p.cs.uiuc.edu>, johnson@p.cs.uiuc.edu says: > > >The point I was trying to make was the best way to develop a set of >teachable skills and procedures is probably to study how sucessful >people do it. Like all research approaches, this might not succeed, >but it seems much more likely to succeed then the purely theoretical, >"let's invent a methodology" approach that seems too common. A disclaimer: I am (or at least used to be) a social scientist, so if anyone should agree with you, it should be the younger version of me, but... Was structured programming invented this way? That is, did researchers study how successful programmers work, and then discover they used structured programming ,or did theoreticians, using introspection, just invent it? I think the latter. Likewise for just about every break through in computing, I think. People do it, and do it some more, til some bright guy finally just *sees* that there is a better way to do it. Now, it helps if that bright guy is surrounded by a bunch of other bright guys, and they spend a lot of effort kicking the ideas around, and they aren't under pressure from marketing to make it user-friendly or whatever. Sounds like a university, I guess. Can you imagine what Unix or Smalltalk might have looked like if they had been designed by psychologists, sociologists ,or cultural anthropologists ,based on studies of the way people used computers? It has always been the case that these types of methods are best at distinguishing between alternatives when comparing two or more cleat alterna- tives in cases where the questions are well-formed. Very rarely do these methods lead to the invention of a new way of doing things. lee
johnson@p.cs.uiuc.edu (10/26/89)
Maybe I should just quit posting. Nobody seems to understand me. UH2@PSUVM.BITNET says >Was structured programming invented this way? That is, did researchers >study how successful programmers work, and then discover they used >structured programming ,or did theoreticians, using introspection, just >invent it? I think the latter. Neither. Bright people discovered that they really hated unstructured code and tried to teach their colleagues how to program better. Eventually Dijkstra wrote "Go-to Considered Harmful". Note that the paper was written after structured control statements were invented. Thus, it was based on experience, not just on theory. I most certainly was NOT claiming that social scientists should be inventing programming methods. However, knowing how to program well is a precondition to inventing programming methods. Lots of people who are trying to tell us how to do object-oriented programming do not, in fact, do much object-oriented programming. I am skeptical of what they say. The only way to learn how to program is to program. Ralph Johnson -- University of Illinois at Urbana-Champaign