Under what circumstances are flowcharts still a valuable and useful tool?

Question

When I first started programming, I relied heavily on flowcharts (and printer spacing charts). While I was in COBOL class, I couldn't start writing any code until my flowchart was signed off by the instructor. Back then, I had to make flowchart for everything.

Today, twenty-five years later, I find myself only flowcharting two types of things. Very specific algorithms where the logic is tricky or very general concepts to ensure that I get all the big steps defined and in the proper order.

Are there other use cases for flowcharts that I've simply overlooked?

Answer 1

Absolutely.

Whenever I'm implementing something that I haven't done before (and the algorithm takes more than a few steps), I'll chart it out. I find that it really forces me to analyze the entire solution at a more atomic level and more thoroughly than if it wasn't charted out. I find that there are three major benefits to this practice:

• Fewer "oh craps" because I've thought the entire algorithm through
• Flushes out any potential knock on issues that may occur throughout the rest of the system
• Allows me to easily walk someone else through the algorithm

The two different occasions where I actually use these are:

• Low(ish) level algorithms. I mean a very specific solution to a very specific problem. I'll generally pass these by peers prior to implementation.
• User flow. Not only can I use this to pass by a peer, but I'll also use it to explain (in a very non-technical manner) flow to a usability expert.

Having said all that, I don't produce flowcharts daily (and even when they're done, it's a generally a whiteboard session unless I'm writing a technical design doc).

Answer 2

Never

Flowcharts - especially as practiced 25+ years ago - have been superseded by far more expressive diagramming techniques (c.f. Action Diagrams, Sequence Charts, State Charts, et al).

IBM's own studies showed that the use of flowcharts had no effect on the quality of a system's design or implementation (though they were marginally useful for communicating with users and other developers) [precise reference not readily available, but was cited in James Martin's Diagramming Techniques for Analysts and Programmers].

Answer 3

I haven't drawn a classical flow chart since my first programming class in 1976, and haven't seen anyone else create one since the early 80's. Flow charts were useful to communicate program logic when the code was in assembly language. By the late 1960's, assembly language programmers were using pseudo-code. When programming in modern OO languages, neither flow charts nor pseudo-code have any value. You may just as well write high-level code in the implementation language.

I do occasionally draw UML diagrams, mostly on paper, to express design ideas, but those diagrams only live until the end of the discussion. I also draw state transition diagrams from time to time, then convert them to a state table in the implementation language.

Answer 4

I use flowcharts all the time for a number of reasons:

1. They are better than UML use case diagrams in my opinion. They can reflect a number of different use cases and how they interact, and they do a better job overall bringing the user experience and decisions together.

2. They are easier to understand and more intuitive. Your mind naturally follows the arrows like a maze from start to finish. You can use flowcharts to end and reference another flowchart for a different user story. I can typically print them in a page numbered book and quickly flip pages to navigate to the next flow chart.

3. They are universal. Few people outside of software engineering know and understand UML diagrams, where Flowchart diagrams are much more recognizable by users and business analysts. I try to communicate complex use cases to a customer and they struggle to comprehend sometimes, I draw them a flowchart and they understand why the finally understand all the nuances that make it MUCH MORE complex than they thought.

Answer 5

Flowcharts are useful when things need to be done in a specific order. Where they really shine in my mind is showing where decisions are made and making sure that each possible decision has a path. This prevent creating programs where a mamager approval is required but have no way to deal with it if the manager (who approves 98% of the time) says no. They remind us that the most common path is not the only path. I find them useful in talking to users about requirements because often they will only tell you the most common path.

Answer 6

UML Activity Diagram and Flowchart are useful to show low-to-medium complexity of a process or algorithm.

They are very good when communicating with business users about business rules.

A variation exists on the form of BPMN 2.0 which is very useful in Business Process Modeling.

Some BPMN tools can generate running web applications from charts.

So yes, flowcharts still have a place but they need to be used wisely.

Answer 7

Flow Charts can be useful for reverse engineering very badly structured code. Particularly if it has gotos. Thankfully I haven't seen much goto-riddden code recently.

As others noted for communicating with end-users. I saw the startup of a TV transmitter documented by flow chart. The hardware and software people had a common specification to work to.

Answer 8

I am not a programmer. I am a hardware engineering tech.

It make sense to me to at least start with comments explaining the logical blocks that will be used. After that, fleshing out the program skeleton with actual code. It is similar to starting a movie script with a story board and then filling in the action details and dialog afterward.

Shouldn't any worthwhile endeavor be carefully planned out? In the hardware realm, we start with a customer requirement doc, then write out a hardware specification document, then flesh out the schematic, then draw a board layout, then come up with assembly documentation. We don't just start grabbing parts and soldering them together as we come up with ideas to make the end product.

I do not see how efficient code can be written in a 15KB or 15MB program without plenty of prep work before starting the actual coding.