Flow Chart

Flowcharts map or represent the ordered steps in a process. The major components of a flowchart include start and end points (circles), decision points (diamonds), abstract or detailed description of units of work (rectangles), and an ordering of the components (arrows). Software flowcharts are generally used to describe a software module. Possibly the first recorded systematic development of the technique were the flow diagrams developed by Goldstine and Von Neumann in 1946.

Flowcharts are often derided for a number of reasons: they can be used to selectively abstract out or hide code complexity, they can be sufficiently detailed to be directly translated to code (thus inefficient), they are often mandated deliverables in many legacy processes, flowcharting software is generally painful (time-consuming) to use, and they do not well represent the complexity of modern interfaces.

According to post-1960s computing science all of this can be attributed to the same root cause: a lack of expressive power.

Clearly the sequencing, choice and loop primitives suffice to describe the control flow in any imperative computer program. Therefore they can be used to document such programs in full detail. However, there is a more compact representation of the same, that is generally much easier to comprehend, namely, the source code itself. Of course some abstraction is possible, by omitting details of data manipulation, taking steps together, etcetera, but programming languages have the notion of subroutine to do the same in a more precise, more general and more comprehensible fashion. In other words, any kind of abstraction performed by means of flowcharts is better performed within the source code itself. This means a flowchart is little more than a simple device to more or less explain the meaning of a particular piece of code to someone who doesn't yet grasp the concept and syntax of semicolons, if and while statements.

This explains why flowcharts only tend to be drawn after the code is already in place, to satisfy some documentation requirement: the programming language in which the code is written offers more powerful abstraction mechanisms than flowcharts, and these mechanisms are needed when developing code.

From this observation many in software development and computing science draw the conclusion that using diagrams to describe control flow is an inherently silly idea. But there is another option, namely, that we just need to pick better primitives. We need primitives that suit the way in which we think of algorithms when we design or analyze them. The least we'd expect is some way to express that steps can be performed in any order (NonDeterminism?). For more complex systems, we also need to express that several processes can run in parallel and can communicate and synchronize. PetriNet-based techniques, for instance, support this. They are no more complicated than flowcharts, just have different primitives.

Flowcharts can be useful, when used selectively. Complicated sections of code (existing or planned) once converted to flowcharts often highlight logical errors. Flowcharting an entire system or application provides little added benefit. Flowcharts are more efficient when a strong review process is in place among a team of willing developers. Flowcharting in layers or aspects can be a useful way to deal with issues regarding the appropriate level of abstraction to depict.

In choosing defect-prevention tasks, flowcharts are inefficient compared to UnitTesting, CodeReviews, and DesignReviews. However, flowcharts have been known to detect defects not caught by traditional testing and review methods. Flowcharting requires far less skill than FormalMethods.

In practice, flowcharting shares many attributes with P.D.L. (ProgramDesignLanguage?).

Flowchart History

Once in the past programmers were believed to have to think first and code later, much later, really later. It was also a fact that the programming interaction cycle - code, compile, test, debug - was longer, something like code in paper today, queue to use a card puncher, punch your cards, queue your cards in a card queue (maybe for a week!), receive compile errors, goto to punch card until no errors are received, debug your program, go to the punch card until you believe it worked, run your real big problem. The slow iteration of this process produced a strong emphasis on correcting mistakes early. Flowcharts would help to detect errors early in the process.

Flowcharts are still used in many formally (formal!=successful) defined (defined!=better) software processes with low defect requirements. Software flowcharts predate structured programming, yet the two are strongly identified as being associated. Though they are less useful in modern software, flowcharts are unfortunately still taught in many colleges.

Flowcharts are still commonly seen in digital logic spec sheets and other formal definitions of interfaces and protocols. It is a pictorial alternative to PseudoCode when you can fit the described algorithm on a single sheet of paper.

[EditHint: some pictures or AsciiArt examples of the standard flowchart elements would be nice to have.]

First cousin of the DataFlowDiagram

For an example, see ProblemSolvingProcess