tanstaafl, thanks for that insight. Thankfully, I've been through this once while developing a custom small business application. Creeping Feature Creature must be kept at bay. That's why I believe in writing a strong design specification and searching for the roadblocks in the entire process before doing too much detail work. On my application, I did a proof of concept of every questionable function first. Then, putting them to use in the final program was straightforward busywork.


I recently heard the following similar interpretation:
To write a truly solid program, you must write the entire thing, start to finish, three times.

During the first write, you learn how components will interact in ways you didn't initially plan, and you see how the limitations of the language shape your design. After the first write, the code will be a jumble of primitive and evolved ideas, but your design will be solid.

During the second write, you will learn how to best use the language for the finalized design, finding more efficient ways to achieve the known goal. After the second write, the code will again show different stages of evolution, but you'll know what works.

During the third and final write, your proven design shell will be filled out with proven optimal code, all at the same stage of evolution for consistency. This code is clean enough to begin a long life cycle.

One of my plans was for me to hack out a first write of the code, learning the syntax as I went. This would iron out my design and give me a proof of concept that I could shop around to developers (and begin building business partnership deals and raising funding). The developers would do the second (and third?) write to apply their knowledge of the syntax to my knowledge of the design at that deep level.

Is any of this even reasonable? Is app development easy enough for a copy-code-off-Usenet hack like me to make a first draft? Full disclosure, this app is complex, merging many technologies used by the big boys.