Good ways to overcomplicate your code and slow down development

[Jerry Daniels]

Josh,

I think the earlier versions of Constellation were actually quite  
good, but I decided to accommodate every request (nearly) and ended  
up with a product that was more difficult to use than intended.

Taking too much user feedback to heart and not sticking to my  
original design resulted in Constellation being very powerful for the  
folks who used it from its genesis, but not as easy to break into  
from scratch. Thus as it got more feature-laden and preference- 
constrained, less people adopted it, but it did have a faithful  
following of hundreds.

Since Galaxy is now 2.6 Rev compatible, almost all Constellation  
users have moved over to Galaxy which isn't as "in your face" with  
its features as the latter day Constellation.

Best,

Jerry Daniels

Tool makers for the 21st century
http://www.daniels-mara.com


On Sep 18, 2006, at 3:03 PM, Josh Mellicker wrote:

> 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.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>