The use of flowcharts has fallen out of vogue with each passing year. There are many programmers who no longer know what the symbols mean and how flowcharts are used. However, flowcharts should not be discredited as legacy just yet!

I have often heard programmers comment that they plan their code within their head as they type code, and sometimes with an air of superiority like they are the only people who can perform such a fete. Concepts suspended within one's mind though are fluid and constantly within a state of flux. Being able to concentrate upon a particular part of the code whilst maintaining it's interdependence within the gestalt reality of the rest of the application's code is akin to trying to see the forest through the trees.

Usually when programming directly from our minds we only focus upon resolving the current problem and then move on to the next algorithm without considering other factors that may make our programming difficult much further into our development. Once code has been written, laying the foundation and future direction of our algorithms, it becomes difficult to see any other alternatives to a particular algorithm or options to replace an algorithm; we end up forcing relationships between algorithms and objects under the illusion of saving time. Often code written directly into an IDE without a prior design means wasted time and effort when you have to re-architect it to fit a subsequent algorithm's needs or when we have epiphanies of missing contingency planning within algorithms.

The only time I would recommend writing code directly from the top of one's head into an application is if what we are doing is experimenting in uncharted waters as an exercise of investigation into object usage or problem solving. For the latter, a trial and error approach with slapdash error handling is quite acceptable, as the resulting application will be either refactored into a more elegant solution or discarded altogether.

Flowcharts help make substantial entities of the liquescent concepts in our minds' eyes. We can focus much more intently upon any particular area of our application's design without having to sustain the rest of the design within the back of our minds, and we can step back to see the integrated picture clearly at any one time. You will see any missing error handling or kinks in logic whilst mulling over an algorithm's process flow. As a personal example, I use a small flowcharting application called WizFlow to design my applications. On one particular application I had designed all of the class objects, the sub-systems with their interdependent contracts with a fully normalised database design. During the process of flowcharting my functions I changed the database schema three times, discarding some tables and reducing others to fields within another table. My database design was streamlined to cooperate with my application from my better understanding of the system which flowcharting had given me. My conclusion was:

A flowchart approach results in a fully integrated system where all components are consonant with each other and designed to work seemlessly together.

Most coding difficulty is removed before coding has even begun. It is also much more expedient to change the design of an algorithm or application when represented within a flowchart, by moving a few symbols and adding or removing others, than continuously refactoring code.

Flowcharts also provide documentation of our design decisions before building our application. It is easier to write documentation when you have an overview of an application's purpose and how it performs it's functions. This same documentation will help us with troubleshooting and making future decisions upon upgrades. Because we have graphically documented the application already we can use our flowcharts to mark off the various stages of our application's development as we build. I often mark off the various parts of a flowchart with a highlighter as I build each algorithm. This is a thrifty process as all the guesswork over how an algorithm will operate has been removed by the flowcharting process. Using a flowchart to mark our current position in code is also useful when we have to drop our development work on one application and start work on another as flowcharts makes it is easier to work out where you left off and easier to conclude our coding at an appropriate juncture before moving our development focus to another project.

So in conclusion we should use flowcharts to design our application and it's code because:

• Flowcharts show the logic of our design decisions and allow us to plan the most elegant way to build an application by giving us a tangible gestalt view of how our application will fit together, from algorithm to database to network.
• Flowcharts document our design decisions which will be useful during maintenance and future upgrades of our applications.
• Flowcharts provide a means to mark milestones of application development as we build upon our application algorithm by algorithm. We will not overlook a crucial piece of code so easily.