[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: top-down design + nevermind

From: Thien-Thi Nguyen
Subject: Re: top-down design + nevermind
Date: Sun, 21 Apr 2002 00:29:47 -0700

   From: Bill Gribble <address@hidden>
   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!).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]