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 utilized. However , flowcharts should not be discredited since legacy just yet!
I have often heard programmers comment that they plan their own code within their head as they kind code, and sometimes with an atmosphere of superiority like they are the only people who can perform such a fete. Principles suspended within one’s mind though are fluid and constantly inside a state of flux. Being able to concentrate upon a particular part of the code while maintaining it’s interdependence within the gestalt reality of the rest of the application’s program code is akin to trying to see the woodland 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 the development. Once code has been created, laying the foundation and future direction of our algorithms, it becomes difficult to find any other alternatives to a particular protocol or options to replace an algorithm; we end up forcing relationships between algorithms and objects under the illusion of saving time. Often code created directly into an IDE without a prior design means wasted time and effort if you have to re-architect it to fit the subsequent algorithm’s needs or whenever we have epiphanies of missing backup planning within algorithms.
The only period I would recommend writing code directly from the very best of one’s head into an application is if what we 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 producing application will be either refactored right into a more elegant solution or thrown away 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 all of those other design within the back of our thoughts, and we can step back to see the incorporated picture clearly at any one time. You will see any missing error handling or kinks in logic whilst mulling over an algorithm’s process movement. As a personal example, I use a little 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 features I changed the database schema three times, discarding some tables and reducing others to fields inside another table. My database style was streamlined to cooperate with my application from my much better understanding of the system which flowcharting had given me. My conclusion was:
A flowchart approach results in a fully integrated system where all elements are consonant with each other and made to work seemlessly together.
Most coding difficulty is removed before code has even begun. It is also a lot more expedient to change the design of an criteria 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 a summary of an application’s purpose and how it performs it’s functions. This exact same documentation will help us with maintenance and making future decisions on upgrades. Because we have graphically documented the application already we can use our flowcharts to mark off the different stages of our application’s development once we build. I often mark from the various parts of a flowchart with a highlighter as I build each algorithm. This can be a thrifty process as all the guesswork over how an algorithm will work has been removed by the flowcharting procedure. 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 start work on another as flowcharts makes it is easier to work out where you left away and easier to conclude our coding at an appropriate juncture before relocating our development focus to another task.