Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: Comments on book review Message-ID: <3823@utzoo.UUCP> Date: Sat, 5-May-84 23:14:37 EDT Article-I.D.: utzoo.3823 Posted: Sat May 5 23:14:37 1984 Date-Received: Sat, 5-May-84 23:14:37 EDT References: cubsvax.219, <2414@ecsvax.UUCP>, <3231@fortune.UUCP> Organization: U of Toronto Zoology Lines: 65 John Crane comments: If you built a house the way some of you seem to think you should build a program, we'd be in trouble. The software sevelopment cycle is more that just a textbook approach. It is a reality in the commercial world of industrial-strength business software. The contention that the software development cycle is more than just a textbook approach is half true, but only half. If one defines "textbook approach" as "a long and convoluted procedure that is unnecessarily complex for any real purpose", then clearly the s.d.c. is more than this. Advance planning is a real necessity. Unfortunately, the s.d.c. is a "textbook approach" in another, related but not identical, sense: "something that sounds good in the textbook but ignores important real-world complications". Specifically, John says: You gotta plan ahead. If not how do you know what you are going to build and how will you know when you've built it? What we're going to build is "something that satisfies the customers". We know we've built it when the customers are happy. Since the customers *INVARIABLY* cannot specify exactly what they want in advance, the idea of "plan first, then implement" is preposterous. An iterative approach is inevitable and necessary. Places that claim to follow the s.d.c. but still produce quality software are always REALLY following an iterative approach, even if they don't admit it or recognize it. The classic symptom of rigid adherence to the s.d.c. is that the first release of the new software package is a piece of garbage, the second release is starting to be useful, and by the third or fourth release the thing is actually fit for humans. Note that what we have here is the iterative approach in disguise, usually at far greater expense (to both the suppliers and the customers) than if it had been done explicitly. The prevalence of this approach within the industry is clearly indicated by the intense reluctance of many organizations to be the first customers for a new product. Note that when I say "the customers *INVARIABLY* cannot specify exactly what they want in advance", I don't mean that they have absolutely no idea what they want. They generally do have a rough idea, and some advance planning based on this is wise. But even if they are willing to write exact specs for everything in advance, using the system will change their perceptions of how they want the details to work. In the prevailing s.d.c. approach, the result is major rework jobs before subsequent releases, rendering obsolete much of the detailed advance planning done during the "development" phase. This is not to say that advance planning is futile for major software packages. On the contrary, it remains very important. But the pretense that every detail can be spec'ed in advance is silly. Advance planning time is best spent identifying issues, gathering data, running experiments with real users, exploring general approaches, and generally doing things that will be valuable regardless of how the final details come out. There is nothing wrong with trying to draw up a detailed spec in advance -- it can be a very useful way to explore the problem -- provided you recognize that it's unlikely to bear much relation to the final result. I can hear the system-development-cycle folks lighting their afterburners now. Just remember, folks: you, too, use the iterative approach. Your users know that, even if you don't. And they wish you'd admit it. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry