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?


8 Answers 8



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

  • @Cape Cod Gunny: you might find Dialog Design Diagrams a tad more useful (an early form of Activity Diagram) Commented Sep 10, 2011 at 3:40
  • 1
    @Cape Cod Gunny: Microsoft SketchFlow might also be of interest. Commented Sep 10, 2011 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].

  • 6
    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
    Commented Sep 10, 2011 at 3:24
  • 2
    @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. Commented Sep 10, 2011 at 3:50
  • 5
    @Demian: boxes and arrows are really all you need ;-) Commented Sep 10, 2011 at 15:39
  • 1
    @Steven Low and Steven Jeuris: sorry, you are both 100% correct. "Supersede" is the usual spelling. Commented Sep 10, 2011 at 23:11
  • 1
    @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! Commented Sep 11, 2011 at 4:06

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.


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.

  • 4
    +1 For Flowcharts recognizable by users and BA's. What tool flowcharting tool do you use? Commented Sep 10, 2011 at 3:16
  • 4
    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
    Commented Sep 10, 2011 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
    Commented Sep 10, 2011 at 3:27
  • 2
    @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
    Commented Sep 10, 2011 at 3:30
  • @Maple - Thanks. I'm blown away because I thought flowcharts were not relevant anymore. I feel like an ostrich ;-) Commented Sep 10, 2011 at 3:48

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.


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.


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.


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.

  • 1
    A lot of people consider analogies between hardware and software to be not necessarily relevant. Design-Code-Test cycles in software are much quicker in software. So-called agile methods would write a test first then write code to pass the test.<br/>15K is pretty small so might be embedded software, that might be "very planned" to ensure it meets its spec.<br/>The Space Shuttle software was written using the techniques you advocate. Commented Oct 13, 2016 at 11:00
  • Also Flow Charts are not necessarily the tool of choice for software design! Commented Oct 13, 2016 at 11:05

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