Good ways to overcomplicate your code and slow down development

Josh Mellicker josh at dvcreators.net
Mon Sep 18 16:03:50 EDT 2006


I believe no human is brilliant enough to foresee all core issues  
with a project, regardless of how much planning is done beforehand.

In the end, one must jump in and start coding. If you are smart, you  
only have to tear the whole thing down and rewrite it a few times.  
And it's usually faster the second or third time, since you are not  
really starting from scratch, now that you know the problems you ran  
into, the new design is much cleaner, better and faster to code. (And  
you can probably reuse some handlers, some UI, etc.)

Look at Galaxy- unmistakably a "second generation" product. I can see  
places where Jerry must have "painted himself into a corner" with  
Constellation, and where starting over in those areas with Galaxy  
allowed him to "do it right this time".

It wasn't lack of planning that caused the flaws in Constellation...  
it was lack of the real world experience of coding it, selling it,  
hearing comments from users, then finally realizing how it should  
have been coded in the first place. (Jerry, correct me if I  
mischaracterize)

I'm NOT saying not to plan at all, that is as deadly as overplanning...

But Revolution's huge differentiating factor as a dev tool is that:


                                                                         
                                                   The prototype IS  
the project.


Guy Kawasaki's philosophy is:

1. stop planning, jump in and start writing the dang thing
2. test, fix and rewrite as you go
3. If you can't fix it, just start over

(I paraphrase)





On Sep 16, 2006, at 2:03 PM, Dar Scott wrote:

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



More information about the use-livecode mailing list