Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!uwm.edu!lll-winken!xanth!mcnc!ncsuvx!ecemwl!jnh From: jnh@ecemwl.ncsu.edu (Joseph N. Hall) Newsgroups: comp.object Subject: Re: programming design methodologies fo Message-ID: <4323@ncsuvx.ncsu.edu> Date: 26 Oct 89 21:47:11 GMT References: <910@gorath.cs.utexas.edu> <135300011@p.cs.uiuc.edu> <14114@athertn.Atherton.COM> Sender: news@ncsuvx.ncsu.edu Reply-To: jnh@ecemwl.UUCP (Joseph N. Hall) Organization: North Carolina State University Lines: 87 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.