questions from using lint
Frank Adams
franka at mmintl.UUCP
Sat May 17 11:18:53 AEST 1986
In article <6667 at utzoo.UUCP> henry at utzoo.UUCP writes:
>> All too often, one sees programmers writing code before
>> a proper job of analysis and design has been done. I
>> also believe that is partly because semi-running code
>> makes it appear as though progress has been made,
>> while a complete design doesn't convey the same impression.
>
>Sorry, Doug, I can't let that one go by.
>
>All too often, one sees programmers writing detailed design specifications
>before writing any code.
>
>The alternative is to recognize that (a) the user probably does not have
>a complete and coherent idea of what he needs, and hence cannot write a
>spec or meaningfully assess one you write, and (b) in any case, the presence
>of the software itself will change the user's tasks and therefore his needs.
>Given recognition of this situation, it is not even theoretically possible
>to avoid a trial-and-error process of software development. Hence you
>should aim to make your inevitable mistakes as early as possible. Which
>puts a heavy premium on getting initial prototype software into the hands
>of the customers right away, so that you can learn what's wrong with it.
>One progresses by iteratively enhancing (and perhaps sometimes re-doing)
>the prototype, with regular user feedback.
Sorry, Henry, I can't let that one go by.
Your points about the lack of definition of the task are well taken, but
your solution doesn't work very well for large or even medium-sized
projects. The problem is that you fairly quickly wind up with very bad
code, and spend inordinate amounts of time making relatively small changes.
Yes, I know you said "sometimes re-doing", but that is often impossible,
under the press of circumstance.
What I think works better (and I don't know of anything which works really
well) is to do an initial design which is as flexible as possible (keeping
speed considerations in mind). Then, with a little luck, when the user
comes back and wants you to do it differently, you can make a fairly small,
clean fix. Of course, they usually manage to come up with a variation in
a direction you never even contemplated, and you're back at square one.
On another level, design first is likely to produce something you can show
the customer sooner than plunging right in, for large and medium-sized
projects. Beyond a certain minimum size, design/code/debug is faster than
code/debug.
Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
Multimate International 52 Oakland Ave North E. Hartford, CT 06108
More information about the Comp.lang.c
mailing list