On Sep 16, 2006, at 11:52 AM, Mark Wieder wrote:
All good ones. One of the problems with RAD tools is that they make
the task of prototyping a bit too easy. I find myself whipping up a
prototype as a proof of concept and then start building an app from
there without having thoroughly thought out the game plan ahead of
time. And then I'm at the point where I don't really want to toss out
what I've built and start from scratch, so I end up spending time
refactoring, reengineering, and patching. And then sometimes reworking
things from scratch anyway.
I understand. And there is extra pressure to go with the prototype
if the customer has seen it.
Something that helps me is to go for a walk or draw pictures or play
with toys with the Grandkids. I am sometimes caught staring at the
wall. I am sure I must have been doing some creative thinking some
of the times that happens.
Sometimes on a walk and away from scripts I'll try looking at things
from another angle. How about pushing data instead of pulling it?
And I come up with a schema for report layout and data setup based on
layers of setprop with interesting characteristics. Things like
that. Sometimes I try to generalize, often coming up with a simpler
solution.
When I read a standard I see how it fits in my first experiments, but
I also try to let the standard write the script. As Robert uses
pseudocode in scripts, I often use lines from standards.
I watch for hints of new ideas and explore those collecting a catalog
of potential tools. When I first saw graphEq work, my brain went
into a fit and a half-dozen books when onto my Amazon work wishlist.
I recently saw the (flash?) game Fancy Pants, which is "excellent in
class," it inspired some notions of alternate GUI. When I look at
how to decompose a problem, I now have some notions cached away as
possible components. I still have a vague memory of math,
linguistics, physics and engineering classes I took last century and
draw ideas for components from those.
Thirty years ago I kept programmers happy by making sure every
project included a fun, tool-building, new tech portion, usually
something off the critical path (or in parallel to an off-the-shelf
or other fast option). I now treat myself the same way. The
schedule might say that you need to salvage much of the prototype,
but you might allow a fun rewrite of the part that needs it the
most. Or you might build a tool so you don't start all over the next
time.
I don't usually have a desire to cling to quick code. My problem is
usually the opposite. That is not too bad. If I can make the script
smaller and simpler, it is usually more reliable. Usually the
elegant is faster, smaller, easier to understand, more adaptable, and
more reliable. Usually. Where I do have a problem is dropping some
elegant but slow idea to go to some other approach. But in a day or
two I feel blessed that that door was closed because I ended up using
something much cooler.
Prototypes often do not lend to automated testing or testing & timing
of lower level components. For me that has tipped the balance on
these decisions.
Often it is not really a question. My prototype is really a
collection of experiments. In that case, I might keep a few
functions, but I feel free to dream up cool stuff. And for many of
us, experimenting is a way to wrap our minds around a problem.
But as I said, I deviate often from what I have said.
My wife is a costume designer. In theatre costume design they have a
saying: Done is beautiful.
I hope these ramblings of an old bitsmith are helpful to those
learning to create with Revolution.
Dar
--
**************************************
Dar Scott
Dar Scott Consulting and Dar's Lab
http://www.swcp.com/dsc
[EMAIL PROTECTED]
Computer programming
**************************************
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
