unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: guile-devel@gnu.org, guile-user@gnu.org
Subject: Re: top-down design + nevermind
Date: Sun, 21 Apr 2002 00:29:47 -0700	[thread overview]
Message-ID: <E16zBn9-0005F3-00@giblet> (raw)
In-Reply-To: <1018270049.27252.36.camel@flophouse> (message from Bill Gribble on 08 Apr 2002 07:47:28 -0500)

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 08 Apr 2002 07:47:28 -0500

   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.  

redesign is fine (and i concur that it should be built into the
process), but forced redesign is not so fun.

   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.

well wouldn't you agree that customer-driven development is indeed a
form of top-down design?  rather than set up an exclusive-or algorithm
to choose top-down or bottom-up, i'm hoping to entice discussion to
learn other people's heuristics on how they effectively use these two
approaches concurrently.

   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. 

most "programmers" are not as well educated as construction workers,
actually, in the craft of their choosing.  there are certain organizing
principles programmers can learn from construction workers: regularity,
the the plumb and the square, using orthogonal units, choosing (or
creating) the right tool for the job, saving leftover pieces of good
material for fun later... generally, how to live comfortably taking
advantage of the physical world's simple constraints.

any profession can learn to code, evidently.  the code is of course
specific to that profession.  what is the programming profession but the
art of translating vague requirements (like "the release must be
stable") into code, and knowing where to put the interpretive hooks?

programmers who can manage themselves don't need additional professional
managers, although many might want one (who can program, too!).

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


      reply	other threads:[~2002-04-21  7:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-08  4:29 top-down design + nevermind Thien-Thi Nguyen
2002-04-08 12:47 ` Bill Gribble
2002-04-21  7:29   ` Thien-Thi Nguyen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E16zBn9-0005F3-00@giblet \
    --to=ttn@giblet.glug.org \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=ttn@glug.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).