top-down design + nevermind

top-down design + nevermind

[Thien-Thi Nguyen]

this is related to recent guile-snarf weirdness but could be said to
apply generally to ends such as setting guile's direction.  top-down
design values interface elegance more than implementation elegance.  the
implementation does what it needs to support the interface and in return
for bearing this burden is given the freedom to evolve.

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.

either style of design is fun.  people write books about their own
personal design philosophies and how it helps you (10min a day).  in any
case, what users perceive determines their happiness w/ the result.

so how to choose the style that fits best for the job?

guile-user cc'ed, to also mention how little reponse there was to the
mailinglist unification (5 resp., 4 yes).  perhaps the question was not
worthy of the survey idea.  damn, i knew i was nuts.

what is guile's direction, btw?

thi

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

Re: top-down design + nevermind

[Bill Gribble]

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-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: top-down design + nevermind

[Thien-Thi Nguyen]

   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