* top-down design + nevermind @ 2002-04-08 4:29 Thien-Thi Nguyen 2002-04-08 12:47 ` Bill Gribble 0 siblings, 1 reply; 3+ messages in thread From: Thien-Thi Nguyen @ 2002-04-08 4:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: top-down design + nevermind 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 0 siblings, 1 reply; 3+ messages in thread From: Bill Gribble @ 2002-04-08 12:47 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: top-down design + nevermind 2002-04-08 12:47 ` Bill Gribble @ 2002-04-21 7:29 ` Thien-Thi Nguyen 0 siblings, 0 replies; 3+ messages in thread From: Thien-Thi Nguyen @ 2002-04-21 7:29 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-04-21 7:29 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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).