Re: top-down design + nevermind

[Chris Beggy]

Bill Gribble <address@hidden> writes:

> 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.  

Maybe you just disagree on the definition of redesign vs. bug
fixes/maintenance.

A good flow is design, test, code, test, fix bugs, release, fix
bugs, maintenance release. If you redesign from scratch, you lose
the old bug fixes, and introduce the same or different ones. In
addition, the code base loses the history of maintenance releases.

A good rule of thumb is that the redesign from scratch is
justified if it will lead to a 10x improvement of some sort
(speed, ease of use, cost, maintainability, reduced bugginess.)

> 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.   

I've never seen a project that didn't have a large portion of
top down design, unless it was a "make from" derivative.

> 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.  

Does the list above apply to guile?  I mean, there is a spec,
r5r, and SRFIs.  Beyond that, someone programming in guile should
at least be able to do some fancy math, some regexps, some unix
system programming, nice IO on MS/Mac/*nix, easy connection to
SQL databases.  That's the *minimum* for usefulness, I'd say.
Beyond that, guile needs an extension method (module, package,
etc.), a method of sharing like CPAN or CTAN, and a community.

I think guile has a special feature, it can be an embedded
scripting language for C programs.  I suspect that this is a
harder problem, which can be in a module, separate from the
easily specified parts of a scheme implementation.

Chris