Re: top-down design + nevermind

[Bill Gribble <grib@linuxdevel.com>]

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