I like to put it all together, and admire the transformation from nothing to something.

This is the way I have built software products. Daring to dream big, then breaking it down, and finally small enough pieces that a plan naturally forms.

Recurrent division through each design piece is done until actually build-able code is envisioned via pseudo-code. Now the language, platform selection and finally code can begin. As discoveries are found along the way, the master pieces are adjusted until an actual usable product forms.

Something like this testing/feedback loop:

Like this:

1. test feature
2. design feedback and change
3. document (exit for release)
4. code

Finally I ensure technical documentation is complete, accurate and easy to use. Nothing worse than stepping into someone else's pile of code without any clue to "Why?" I have found that it's easier and better in the long term to place as much documentation for the "Why's" very close and sometimes inside the actual source code so it is easy to find and maintain.

Very much like Unix/Linux/BSD files; README, INSTALL, etc...

Dream big, solve small.

-- Don Cohoon

--

____          
|  _ \  ___  _ __  
| | | |/ _ \| '_ \ 
| |_| | (_) | | | |
|____/ \___/|_| |_|                             

¯\_(ツ)_/¯