Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!athertn!jimb From: jimb@athertn.Atherton.COM (Jim Burke) Newsgroups: comp.object Subject: Re: programming design methodologies fo Message-ID: <14114@athertn.Atherton.COM> Date: 26 Oct 89 17:30:24 GMT References: <910@gorath.cs.utexas.edu> <135300011@p.cs.uiuc.edu> Reply-To: jimb@athertn.UUCP (Jim Burke) Organization: Atherton Technology, Sunnyvale, CA Lines: 48 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.