From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Bill Gribble Newsgroups: gmane.lisp.guile.user Subject: Re: top-down design + nevermind Date: 08 Apr 2002 07:47:28 -0500 Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1018284406 7929 127.0.0.1 (8 Apr 2002 16:46:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2002 16:46:46 +0000 (UTC) Cc: guile-devel@gnu.org, guile-user@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16ucI1-00023m-00 for ; Mon, 08 Apr 2002 18:46:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16uacv-00062o-00; Mon, 08 Apr 2002 11:00:13 -0400 Original-Received: from grib.customer.jump.net ([216.30.103.2] helo=firewall.linuxdevelopersgroup.com) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16uYYa-00032U-00; Mon, 08 Apr 2002 08:47:37 -0400 Original-Received: from flophouse.internal.billgribble.com (unknown [192.168.0.66]) by firewall.linuxdevelopersgroup.com (Postfix) with ESMTP id E9601FEE; Mon, 8 Apr 2002 07:47:30 -0500 (CDT) Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by flophouse.internal.billgribble.com (Postfix) with ESMTP id 58FE58A00D; Mon, 8 Apr 2002 07:47:29 -0500 (CDT) Original-To: ttn@glug.org In-Reply-To: X-Mailer: Ximian Evolution 1.0.3 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:151 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:151 On Sun, 2002-04-07 at 23:29, Thien-Thi Nguyen wrote: > this is obviously in contrast to bottom-up design which i believe can > get a lot of unfocused work done but often presumes to know the future > too much in practice, eventually causing re-design, because elegance is > measured in the implementation and guesses are made about usage. What's wrong with redesign? In my experience, there's no such thing as a software design that's correct from the start. Redesign should be built into the process, because it *will* be required. Top-down design takes the closed-loop process of software engineering and tries to make it open-loop. The only way to do this is to assert by fiat that implementation experience does not feed back into design. IMO, that's dumb. Customer needs, developer experience, and strategic (management) goals all are parts of the design process. None of these things can be completely specified in advance. Design and implementation must proceed together and iteratively in order to use resources most efficiently, IMO. Software "architecture" is not like building "architecture"... if it was, there would be no need for programmers to be more educated than construction workers. All the interesting work would be in the design phase, and no code would be written until the "blueprint" was complete. That might be a management jerk-off fantasy, but it's a recipe for a train wreck. Why? Lots smarter people than me have taken that on. My understanding is rooted in the construction analogy. Why can an architect design a building completely up front? Well, part of it is that we know more about the material properties of reinforced concrete than any other substance. There are shelves of books devoted to the ways in which reinforced concrete behaves in every imaginable condition of temperature, moisture, composition; ways in which different patterns of reinforcing bars affect flexibility, strength, strain and shear properties; failure modes, etc, etc. When it comes to software, our equivalent level of knowledge is "if you mix cement, sand, and water, and pour it in a form with metal bars, you can build things". It's just not reasonable to design a bridge with that level of knowledge. Thankfully, '$ cd bridge; make check;' takes a lot less time than building a bridge. so it's reasonable to have prototyping, redesign, and implementation feedback built in to the process. b.g. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user