Re: Structured Programming using Forth
- From: "J Thomas" <jethomas5@xxxxxxxxx>
- Date: 30 Mar 2007 07:18:42 -0700
On Mar 30, 7:22 am, Duke Normandin <merr...@xxxxxxxxx> wrote:
Seems like some half-ass "hit-n-miss" way of thinking about software
development, to me.
I'd rather have "a plan" of some kind, instead of fumbling around. So as
far as I'm concerned, the top-down approach for planning is just fine.
However, I can see where your "iterative and incremental" approach would
dovetail nicely with the traditional "bottom-up", "break-it-down"
approach.
If you can hold the whole thing in your head at once before you start
testing everything, and you can make sure it's all correct in your
head, then top-down is a good way to go.
If you aren't completely sure ahead of time how it will work, then
"plan to throw one away". You will probably run into problems you
didn't expect, that might simply keep your idea from working. Top-down
is no solution to that.
Sometimes it works to start top-down and bottom-up at the same time.
The bottom-up side starts with drivers and such and it builds things
that look like they'll be useful that are easy to build. The top-down
side starts with untested code that looks like it's arranged to do
what you need. As you work toward the middle at some point you notice
whether you have a problem or not. If your bottom-up code is simple
and elegant, it probably can be used toward getting the results you'll
need. If your top-down approach leads to things that are hard to
implement, chances are it's better to replace it than struggle with
ways to give it what it needs. It wasn't really working code anyway.
Sometimes it works to start middle-out. Build flexible tools that are
likely to be useful, and work down to make sure you can make them
work, and also work upward to make sure they can build the top-level
things you want.
If it's something very complex, though, then Andrew Haley's advice is
vital. Build something simpler that uses some of the functionality
you'll need. Use that to get an idea how to proceed on the bigger
project. Then build something that's still simple but which does more
of what you need. Keep heading toward what you want, and each step you
get something that works. You might still find a grievous error that
makes you fall back and do a different simple stage that you'll build
up a new way, but it's less likely than with other approaches.
John Gall's Systemantics says: A complex system that works is
invariably found to have evolved from a simple system that works.
Complex systems designed from scratch never work and cannot be patched
to make them work; you have to start over, beginning with a working
simple system.
Still, a rigid top-down strategy is likely to work when the problem is
simple enough that you can hold all the details in your head and solve
all the problems before you start.
.
- Follow-Ups:
- Re: Structured Programming using Forth
- From: Jerry Avins
- Re: Structured Programming using Forth
- References:
- Structured Programming using Forth
- From: Duke Normandin
- Re: Structured Programming using Forth
- From: Andrew Haley
- Re: Structured Programming using Forth
- From: Duke Normandin
- Structured Programming using Forth
- Prev by Date: Re: Structured Programming using Forth
- Next by Date: Re: Structured Programming using Forth
- Previous by thread: Re: Structured Programming using Forth
- Next by thread: Re: Structured Programming using Forth
- Index(es):
Relevant Pages
|
Loading