Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
@Guys - Thank you for rephrasing how I should ask this question. I'll learn one of these days. ;-) – Michael Riley - AKA Gunny Sep 10 '11 at 16:53
rephrasing the question made the answers nonsensical! – Steven A. Lowe Sep 11 '11 at 4:13
Rephrasing the question made the censors happy. :D – maaartinus Sep 15 '11 at 6:19
up vote 16 down vote accepted


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).

share|improve this answer
@Cape Cod Gunny: you might find Dialog Design Diagrams a tad more useful (an early form of Activity Diagram) – Steven A. Lowe Sep 10 '11 at 3:40
@Cape Cod Gunny: Microsoft SketchFlow might also be of interest. – Jörg W Mittag Sep 10 '11 at 4:02


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].

share|improve this answer
Superseded is a harsh word, we just have more options now. More expressive isn't always better. My clients want to know what the software is doing and they don't want to waste time learning UML. I can't blame them. – maple_shaft Sep 10 '11 at 3:24
@Steven: +1, but flow charts were long gone 25 years ago. When I entered Carnegie-Mellon in 1975, research programming at CMU was done online in ALGOL, SAIL, PASCAL, LISP, Simula, C, and other high-level languages, mostly using EMACS. No one bothered with flow charts. We just wrote a little code, tested it, corrected it, then wrote some more. – kevin cline Sep 10 '11 at 3:50
@Demian: boxes and arrows are really all you need ;-) – Steven A. Lowe Sep 10 '11 at 15:39
@Steven Low and Steven Jeuris: sorry, you are both 100% correct. "Supersede" is the usual spelling. – kevin cline Sep 10 '11 at 23:11
@Steven Jeuris: so would I; I looked as well but found nothing. I'm fairly certain my memory is correct on where I read it, but unfortunately at the moment all of my reference books are packed up in storage (moving house). The study stuck in my mind because it was conducted by IBM on their own people using their own flowchart template! – Steven A. Lowe Sep 11 '11 at 4:06

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.

share|improve this answer
+1 For Flowcharts recognizable by users and BA's. What tool flowcharting tool do you use? – Michael Riley - AKA Gunny Sep 10 '11 at 3:16
Flow charts don't represent use cases at all. If you wanted to correlate a flow chart to a UML diagram, it would be more like a sequence diagram, communication diagram, or activity diagram. In fact, activity diagrams are meant to show workflows. What, in my opinion, makes UML activity diagrams better than a flowchart is that the symbols and terminology used is standardized, allowing for anyone (who knows it) to read it easily without having to look up the symbol meanings. – Thomas Owens Sep 10 '11 at 3:20
@Thomas, Different strokes... You are right though that Activity diagrams are more expressive but they require more input, UML knowledge and precious precious time that I simply do not have when the customer needs a diagram NOW NOW NOW!!! I can whip up a quick and dirty flowchart. To the user the actual UML use case diagram tells them common sense. The flowchart gets to the meat of the matter. – maple_shaft Sep 10 '11 at 3:27
@Cape, I just use Visio. It certainly isn't the best tool but you know what they say, People pick a familiar comfortable hell over an unfamiliar alien heaven. – maple_shaft Sep 10 '11 at 3:30
@Maple - Thanks. I'm blown away because I thought flowcharts were not relevant anymore. I feel like an ostrich ;-) – Michael Riley - AKA Gunny Sep 10 '11 at 3:48

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.