The Lost Art of Flowcharting

Table of Contents

With the growing reliance of AI assisted code writings, gone are the days where we would see one pull out their notebook and sketch out algorithams or plans to solve a given problem. Back in the day flowcharting was one of the fundamental ways one could use to map out and make their solutions visual! It sure does take time, but in the long run it produces less buggy solutions, so maybe, just maybe, it’s worth picking up again!

Below is a snippet of writing taken from the book “programming the 8086/8088 by James W. Coffron”, I take no credit in the insights to its writings. It was published back in 1983 when people were still writing code on their fat almost fridge like IBM PCs with just simply good old assembly, poking around in memory to find their way through the logic of their code.

What a different time it was…

Flowcharting

A flowchart is simply a symbolic representation of an algorithm, usually expressed as a sequence of rectangles and diamonds. On a flowchart, rec­ tangles are used to represent commands, (or executable statements), and diamonds are used for tests such as: If information X is true, then take action A; if not, take action B.

Figure 1.1 shows an example of a flowchart. Flowcharting is a highly recommended intermediate step between the specification of an algorithm and the actual coding of a solution. Remarkably, it has been observed that perhaps 10% of the programming population can write a program successfully without having to prepare a flowchart. Unfortunately, it has also been observed that 90% of the popula­tion believes it belongs to this 10%! The result, then, is that, on the average, 80% of the programs fail the first time they are run on a computer. (These percentages are naturally not meant to be accurate.) In short, most novice programmers seldom see the necessity for drawing a flowchart.

Diagram from the book Programming the 8086/8088 by James W. Coffron

Ignoring the flowcharting step usually results in an erroneous program, and the programmer must then spend a long time testing and correcting his or her program. (This is known as the debugging phase.)

The discipline of flowcharting is, therefore, highly recommended in all cases. Flowcharting generally requires a small amount of additional time prior to the coding, and usually results in a clear program that executes correctly within a short period of time. Once the procedure of flowcharting is well­ understood, a small percentage of programmers can perform this step mentally, without using paper. Unfortunately, in such cases, the programs they write are usually difficult for others to understand, since the docu­mentation normally provided with a flowchart is not available. It is univer­sally recommended that flowcharting be used as a strict discipline for any program more than ten or fifteen instructions long.

While this practice might no longer be necessary to ship robust working code it might still remain a good tool when coming up with good solutions when impromptu just feels impossible sometimes.