johnson@p.cs.uiuc.edu (10/17/89)
From jnino@cs.utexas.edu >My impression by reading the literature, is that there is no programming >methodology that has been recognized to be successful, and furthermore >that there is still need to develop a design methodology adequate for >OOP applications. 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. You can't always find out the methodology that people use by asking them, they might not understand your question. Moreover, I think that the people asking the question might not always understand it, either! What is a methodology? A programming methodology is a way of programming. Smalltalk programmers have a fairly consistent way of building systems, so there exists a Smalltalk programming methodology. It is centered around a number of key ideas. One is the importance of iteration and revision. Smalltalk programmers sit down to the keyboard very early in the life of a project, and some people mistake this for "programming without thinking". This is easy to do, because if you ask the programmer whether he/she is programming, the answer will probably be "yes". After all, classes are being created, methods are being written, and often code is being executed. However, if you ask the programmer whether the code for the final product is being written, the answer will be quite different. The programmer is really doing design, trying to discover the correct set of classes and how functionality should be distributed among them. The programmer expects to completely redo the design several times, until it is right. Another key idea is the importance of reuse. It isn't enough for a class to work, it should be reusable. There are many particular techniques for making a design more reusable, but the key point is that revision and reworking are always necessary. Each class should be as independent of other classes as possible, and this is hard to do. Another key idea is that a computer system should be a simulation of the design. The programmer should think of objects as components of an active system. This provides a concreteness that makes object-oriented systems easier to think about. Note that a computer system is not necessarily simulating anything out in the real world, so it fine for objects to correspond to newly invented ideas. OOP consists of making classes and adding methods to them. OO design also consists of making classes and adding methods to them. Thus, it is easy to confuse the two. The difference is in the level of detail of the methods (the bodies of methods are often ignored during design) and in the completeness of the class hierarchy, since designers aften just write a few typical subclasses and assume that the rest will be similar. It is true that OOD is quite a bit different from traditional design. It is also true that it is not written down much. The people who know it do it instead of writing about it. However, since people are successfully designing object-oriented systems, there must be some "method to their madness". The problem is in learning it. Ralph Johnson -- University of Illinois at Urbana-Champaign
jimb@athertn.Atherton.COM (Jim Burke) (10/27/89)
In article <135300011@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: >What is a methodology? A programming methodology is a way of programming. >Smalltalk programmers have a fairly consistent way of building systems, >so there exists a Smalltalk programming methodology. It is centered around >a number of key ideas. One is the importance of iteration and revision. >Smalltalk programmers sit down to the keyboard very early in the life >of a project, and some people mistake this for "programming without >thinking". This is easy to do, because if you ask the programmer whether >he/she is programming, the answer will probably be "yes". After all, >classes are being created, methods are being written, and often code is >being executed. However, if you ask the programmer whether the code for >the final product is being written, the answer will be quite different. >The programmer is really doing design, trying to discover the correct >set of classes and how functionality should be distributed among them. >The programmer expects to completely redo the design several times, until >it is right. I heard this argument as a project manager at my last job. I don't buy it. True, this is how Smalltalk programmers may work. I do not believe a moderately large commercial software project can ever be done this way. It would be unthinkable to undertake a hardware project without a reasonable design. One does not build a bridge without first developing a design. The folks who resist formal design tend to be the same folks who tell you that the best and only documentation required is the code. IN other words, hackers. "When will the project be done?". "When it's done". The idea of sitting down and writing a bunch of code until you stumble upon something that works is indeed a methodology. It is just a poor one and is unacceptable in most commercial settings. The primary reason is that most projects are run with somebody else's money. Without a concept of design early in system development, the people with the money have no way of estimating how much of their money will be required. If I told you I'd like you to fund a project where I would keep experimenting until I found something that worked, would you do it? How could you ever see any end point. How would you measure progress? What are the milestones? When people don't have such goals with which to measure success, nobody will give them the money to do anything. Besides, if you have more than two or three people working on the project, what co-ordinates their activities except for a common design goal? I can just see 20 programmers all prototyping away and then trying to integrate what they have come up with. OO ain't that good yet... -- ****** Views expressed herin are my own ******* Jim Burke - consultant 408) 734-9822 | I'll stop posting when they pry my jimb@Atherton.COM | cold, dead fingers from the smoking {decwrl,sun,hpda,pyramid}!athertn!jimb | keyboard.
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/27/89)
In article <14114@athertn.Atherton.COM> jimb@athertn.UUCP (Jim Burke) writes: ... >The folks who resist formal design tend to be the same folks who tell you >that the best and only documentation required is the code. IN other words, >hackers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Baloney. In those cases where the code is capable of being sufficient documentation, IT IS THE BEST DOCUMENTATION, when written properly. It took me a long time to come to this conclusion, but the arguments are powerful and persuasive. 1) If the code is its own documentation, then it is not necessary to revise external documentation in order to reflect changes in the code. This is NOT a trivial problem. 2) Tools for extracting some forms of "documentation" from code can and have been written. ("short", from Eiffel, for one.) 3) It is difficult to fully describe an algorithm in a form that is more readable and comprehensible than a suitable implementation in a high-level language, especially given the presence of a few lucid comments in the code. Examples where the code cannot be sufficient documentation: 1) a user manual 2) a scientific paper 3) a balloon chart for the sales reps "When will the project be done?". "When it's done". The idea >of sitting down and writing a bunch of code until you stumble upon >something that works is indeed a methodology. This is a gross generalization. There is no more efficient way to prototype individual modules or algorithms than by writing the code and refining it, assuming that the programmer understands the problem and has a solution in mind. (What he does to get to that point of understanding is best decided by him and his maker.) On the other hand, it would be very poor practice indeed to design the interfaces between modules on the fly; this is something that does require involved consideration, meetings, paper, etc. It is just a poor one and is >unacceptable in most commercial settings. The primary reason is that most >projects are run with somebody else's money. Without a concept of design >early in system development, the people with the money have no way of >estimating how much of their money will be required. If I told you I'd >like you to fund a project where I would keep experimenting until I found >something that worked, would you do it? This is called "research." It's kind of fun. The corporations who fund it find it exasperating, but they pay for it anyway (usually). The US government will find all kinds of weird stuff. Rog-O-Matic, for example. You will not find any method of doing research, ever, that you can guarantee will conform to a timetable. On the other hand, you can develop all kinds of accounting software on strict schedules ... How could you ever see any end >point. How would you measure progress? What are the milestones? When >people don't have such goals with which to measure success, nobody will >give them the money to do anything. Wrong. Besides, if you have more than >two or three people working on the project, what co-ordinates their >activities except for a common design goal? I can just see 20 programmers >all prototyping away and then trying to integrate what they have come up >with. OO ain't that good yet... > This has been going on for years. 20 programmers all prototyping away = 20 graduate students all working on theses and dissertations. Integrating code doesn't HAVE to be difficult in the right environment. Lots of people have written UNIX tools, and by and large they integrate very well, don't you think? OO promises to allow the same ease of integration at a more microscopic level. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
marc@dumbcat.UUCP (Marco S Hyman) (10/29/89)
In article <14114@athertn.Atherton.COM> jimb@athertn.UUCP (Jim Burke) writes: Without a concept of design early in system development, the people with the money have no way of estimating how much of their money will be required. It's not a design that's used for estimating costs, it's a schedule. And if the schedule doesn't include the time to throw one design away, it's not worth anything. Why do you thing that software engineering and software projects in general have such a bad reputation in some circles? Non-trivial projects are (almost) always late and over budget. Why? Because, IMHO, most programmers are no good at saying NO. They feel pressured to not include the time for the second design in the original schedule and, when the design problems crop up, feel pressured to somehow make it work. Too many programmers give in to this pressure -- and therefore are placed in a position where they are guaranteed to fail. It's my hope that object-oriented programming will help by limiting the amount of re-design needed in addition to class/object re-use. Often the re-design effort is on changing the data flow. When this happens it may be possible to keep many of the existing objects. In article <4323@ncsuvax.ncsu.edu> jnh@ecemwl.ncsu.edu (Joseph N. Hall) replied: >The folks who resist formal design tend to be the same folks who tell you >that the best and only documentation required is the code. IN other words, >hackers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In those cases where the code is capable of being sufficient documentation, IT IS THE BEST DOCUMENTATION, when written properly. It took me a long time to come to this conclusion, but the arguments are powerful and persuasive. In any non-trivial piece of code the source code alone is NEVER enough. (The only exception to this is when the source code is WEB or something like it.) The source code does not say *why* certain decisions were made and, sometimes just as important, does not include a history of what didn't work. This is important information. Too often I've seen someone go in and ``clean up'' some code while fixing a bug just to have it break someplace else. All this because the original programmer did not note *why* things were done the way they were. Unfortunately, programmers don't seem to learn the necessity of adding this kind of documentation, preferably to the source, until they've been bitten while cleaning up their own code many months after it was written. Some don't even learn it then. --marc -- // Marco S. Hyman {ames,pyramid,sun}!pacbell!dumbcat!marc