Good ways to overcomplicate your code and slow down development

[Dar Scott]

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
dsc at swcp.com

Computer programming
**************************************