crane@fortune.UUCP (John Crane) (05/10/84)
This is a response to the criticisms of my review of The C Programmers'
Library in which I quoted the author's definition of "bugging" and then
went on to decry the evils of (horrors!) "hacking".
Cheap Shot Department (aka "he doesn't know what he's talking about:
because he works for Fortune"):
Fortune will be the first to admit that release 1.0 of our
operating system WAS very buggy, and since it supported the rest of
the software, it made everything else look bad. I am proud to say
that Fortune has really gotten its act together in the past 9
months. We fixed the operating system and made it run a lot
faster. One of the things we did was implement tight project
controls and have adopted a standard software development
methodology which involves: (1) determining requirements (2)
writing the functional specifications (3) designing the system (4)
then AND ONLY THEN, laying hands on the keyboard and coding (5)
extensive (downright nit picky) in-house testing (6) beta testing
(7) release and (8) maintenance.
I myself have only been with Fortune during the past nine
months, so you can't blame me for all the problems of the
past. I helped implement the new standards here and have
done so at every previous company where I have worked for
the past 15 years.
"I don't do it so it can't be right" Dept.:
For everybody you can point to (including yourself) who
doesn't use standard design methodology, I can point to
somebody who does. So, lets just throw that argument in
the garbage where it belongs because you can't prove
whether or not something works by taking a popular vote.
You prove whether or not something works (and I think
this is the fundamental question) by using it and comparing
results.
Several people mentioned that developing software for somebody else besides
yourself depends on an iterative approach. You build something, show it to
the user, he or she makes changes, you go back and build something else,
and show that to the user, etc. I heartily agree that it is a iterative
approach. I also feel that its not so much that the user doesn't
understand what he wants, its just that he can't communicate his desires to
the programmer and the programmer can't communicate back what he is going
to do until the program is finished and running -- normally.
However, if we could build better communication in the front end. If we
could provide a means for a programmer and user to talk back and forth and
really understand each other in the early design stages without having to
the expense of writing a program that doesn't fit the users needs, we will
have accomplished something. There are several approaches to achieving
this communication. The traditional approach is to put an analyst in
between. Somebody who knows the application as well as computers. Another
method is writing detailed design specs. Another is prototyping. Build a
quick and dirty model and let the user play with it and suggest changes. I
recommend all three.
I think some of you were objecting to what I said thinking I was talking
only about the programming phase of a project. No, I'm talking about the
whole development cycle. If you are strictly a programmer, maybe the whole
thing is speced out before you get it, and all you have to do is write the
code. In that case what I said doesn't apply, and how you write the code
and get it working is your business. As long as the code is efficient,
effective, and maintainable.
I'm glad this subject finally came up on the network, because I really
think it needs to be thoroughly aired.
I may be displaying my ignorance at this point, but I think most of the
UNIX programmers in the audience are either still in the academic
environment, or engaged in systems or scientific programming, kernel
kackers, or like me, writers of stuff like editors, spreadsheets, and other
generic utilities. This is a different world than the IBM commercial data
processing world or accounting applications. It was for this latter world
that Yourdon, de Marco, et al wrote for.
The structured methodology people also developed their theories when batch
processing was the norm. Also, they wrote for in-house software
development, not necessarily for hardware houses like Fortune or software
houses like Microsoft. In a bank if you screw up a report, only a few
tellers or accountants notice it. If Micrrosoft goofs, thousands of
customers around the world notice it and it gets written up in InfoWorld
and on the net.