In brief, as engineering students several years ago, we learned 'structured' programming to establish our baseline technique. In essence, each function or subroutine had its own 'theme' or purpose and expected results. Each subroutine was likened to a paragraph having its own 'main idea' so to speak. This type of programming also seemed to 'reduce the clutter' of some programs that are written in a top-down manner (maybe 'clutter' is not the word I am looking for -- it may be that 'structured' programming makes it easier to see the 'overview' of the program and then be able to view the details of the subroutine when and if desired). Yes, you must jump to the subroutine to see what it does, but all of the code associated with that routine is in one place as a 'module'. At times, you may not need to see the detail of each subroutine in viewing the program's logic. Sometimes, just the 'overview' of its structure is needed. Also, subroutines can reduce 'code duplication' within a program.

Each 'module' could be tested before adding another 'module', and so on. It just seemed easier to add 'modules' than to squeeze multi-lined code between other code.

Adding variables instead of hard-coding PLUS adding a sufficient amount of comments which explain what the code is to do, etc., makes it easier to adapt certain 'modules' and snippets to other programs as well as to make it easy to go back to a program in the future and quickly determine 'what' is going on and 'why'.

For me, it also seemed to make it easy for me to learn multiple programming languages, just by adapting the syntax to the structure of the code, and by looking at the 'overview' of other programs written structurally, as a guide. Of course, this can also be true of 'top-down' coding, but structured is clearer to me due to its 'overview' nature.

What helps me to formulate the 'logic' of a project, depends on the project. Sometimes, creating an 'outline' as though I am writing a technical report is appropriate. At other times, creating the 'screens' geared toward what the end-user is going to see may be appropriate for another project. At other times, I may use a combination of the two. Next, I may create a flowchart whereby I also create 'what-if' scenarios. These 'what-ifs' may be for the purpose of minimizing security concerns or to minimize errors that the user may encounter if they enter data incorrectly (this helps with creating a more user-friendly environment). Flowcharts greatly enhances the building of the program's logic so that it is more efficient and self-explanatory to the user, others, and to me. Creating notes for future user and 'admin' documentation should also be done during the program's development. Trying to recap at the end leads to 'weaker' documentation.

Sometimes, depending on the project, I may begin coding as my first step, because I could see the project clearly in my head, and then document and design as I go along, to carry me to the next step. It all depends. I guess this is the same part of my brain that allows me to hear a song and 'play it by ear' on the piano. That is why I enjoy designing (not just programs but anything mechanical, processes, etc.) because it combines the analytical with the creative juices to form a nice end-result. I guess it is the 'freedom' of thought that is my 'carrot'. Sometimes, rigidity and an overabundance of constraints stymies creativity. One of my previous boss' (an product design manager) philosophy was, for us to design WITHOUT the budget being a constraint. Most times, we would not know if there was a specified budget for a given project. He felt that a better product would be created without adding the monetary constraint which tends to restrict creativity. He preferred to streamline the product's definition AFTER the design in order to fit the budget, otherwise, maximum creativity may not be achieved.

Well, this is it in a nutshell. Structure is great; outline the specifications up-front as required or practical or to use as a guideline; define the expected outcome; reducing the likelihood of operator error; increase security; and optimize the 'flow' and efficiency of the code; and increase the software's 'user-friendliness' as practical. Continually revisiting these items throughout the software's development is a must to any successful project. How you get there is most times an 'individual thing'. That is the best part. I don't have to think like someone else to design whatever. The project and I become 'one' (as much as practical) until I and/or others know it is 'good and very good'...

Hope this helps.
--newbie00