The use of flowcharts has fallen out of style 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 noticed programmers comment that they plan their particular code within their head as they type code, and sometimes with an air flow of superiority like they are the just people who can perform such a fete. Ideas suspended within one’s mind although are fluid and constantly inside 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 development directly from our minds we just focus upon resolving the current problem and then move on to the next algorithm without taking into account other factors that may make our programming difficult much further into our own development. Once code has been composed, laying the foundation and future path of our algorithms, it becomes difficult to see any other alternatives to a particular criteria or options to replace an algorithm; all of us end up forcing relationships between algorithms and objects under the illusion of saving time. Often code created directly into an IDE without a previous design means wasted time and effort when you have to re-architect it to fit a subsequent algorithm’s needs or whenever we have epiphanies of missing backup 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 should are doing is experimenting in uncharted waters as an exercise of analysis into object usage or issue solving. For the latter, a trial and error approach with slapdash mistake handling is quite acceptable, as the ensuing application will be either refactored into a more elegant solution or thrown away altogether.
Flowcharts help make substantial organizations 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 all of those other design within the back of our minds, and we can step back to see the included picture clearly at any one time. You will see any missing error handling or even kinks in logic whilst mulling over an algorithm’s process movement. As a personal example, I use a small flowcharting application called WizFlow to develop my applications. On one particular app I had designed all of the class objects, the sub-systems with their interdependent agreements 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 style was streamlined to cooperate with my application from my better understanding of the system which flowcharting had given me. My conclusion has been:
A flowchart approach results in a completely integrated system where all elements are consonant with each other and made to work seemlessly together.
Most code difficulty is removed before coding has even begun. It is also a lot more expedient to change the design of an protocol or application when represented inside a flowchart, by moving a few symbols and adding or removing other people, 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 on 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 even 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 the current position in code is also useful when we have to drop our own development work on one application and begin work on another as flowcharts helps it be 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 task.