johnson@p.cs.uiuc.edu (10/30/89)
I proposed iterative design as an object-oriented programming method. Jim Burke replied >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. Jim's best points were that without a formal design it would be impossible to tell how much work a project would take and whether the developers are on target or not. I am sure that this is one of the main reasons that people shy away from a rapid-prototyping approach to building systems. As Jim said >When people don't have such goals with which to measure success, nobody will >give them the money to do anything. I talked to someone at OOPSLA who was using this approach to build a banking system in Smalltalk. (There were 20 or so programmers involved, I believe.) I asked him how his management let him get away with this using rapid prototyping. His answer was that they had done it before, and their management trusted them. Of course, they also had alternate ways of measuring their success. The usual technique is to take an initial list of features that the system is to support and to assign a date to each. Naturally, the features get reordered as time goes on, but it is still fairly easy to see whether a project is on track or not. >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. The only reliable program documentation is the code. User documentation is something else entirely. However, program documentation that is not related to the code is always out of date and wrong. This is a simple fact of life. One of the bad consequences of this fact of life is that, since most languages don't let you put pictures in comments, pictures can't be reliable documentation. My solution to this is to put pictures in code, however. By the way, define "formal design". How are programming languages not formal? In what way is a programming language bound to be a bad design language? >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. Naturally, this is not at all what I meant. Researchers always know the problem they are trying to solve and propose methods to solve it. They just don't know which one will work best.