16

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?

Bill the Lizard
  • 8,408
  • 9
  • 41
  • 92
Michael Riley - AKA Gunny
  • 4,928
  • 3
  • 29
  • 44

8 Answers8

20

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

Demian Brecht
  • 17,555
  • 1
  • 47
  • 81
12

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

Community
  • 1
Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • 5
    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 03:24
  • @kevin cline: thanks - oddly enough i spelled it right to start with, then trusted the spellchecker when it complained! – Steven A. Lowe Sep 10 '11 at 03:42
  • @maple_shaft: superceded is a very precise word, and is the correct word. You and your clients want to ride horses, have at it; I prefer cars. Action Diagrams (for example) are equally expressive and arguably simpler for end-users to comprehend. They also take up less space on the whiteboard – Steven A. Lowe Sep 10 '11 at 03:42
  • 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. – kevin cline Sep 10 '11 at 03:50
  • @kevin cline: the 25+ figure was referencing the OP's post, not the actual timeline; I suspect the IBM study was done in the late 1960s, but am not certain – Steven A. Lowe Sep 10 '11 at 03:56
  • @Steven, You edited your answer stating the potential convenience when communicating to customers so I removed the downvote. It seems flowcharts are a laughably obsolete concept, especially it seems amongst ivory tower architects and CMU big shots. I was taught with them and perhaps they are a bad concept to use amongst programmers. I wish I had the time to draw more descriptive UML diagrams, fewer things in life are more beautiful. – maple_shaft Sep 10 '11 at 04:19
  • @kevin, As a Pittsburgh native I have worked with a few CMU grads and they all seem to be big on EMACS. That must be a common thing at that school? – maple_shaft Sep 10 '11 at 04:22
  • @maple_shaft: thanks, but actually kevin edited my answer to correct a typo; the convenience/communication line was in there all along. Perhaps I should have drawn a flowchart (or StateChart) instead of using inconvenient English pseudocode ;-) – Steven A. Lowe Sep 10 '11 at 04:50
  • You yell louder than I do ;) I could have also mentioned that what I usually end up diagramming out isn't necessarily a *classical* flow chart, but most likely a hybrid of different types depending on what I'm charting out (algo, user flow, etc). In 10 years of developing, I have yet to encounter a single person who remembers all of the identifiers when charting something out on a whiteboard. – Demian Brecht Sep 10 '11 at 07:26
  • 5
    @Demian: boxes and arrows are really all you need ;-) – Steven A. Lowe Sep 10 '11 at 15:39
  • @Steven: Absolutely :) – Demian Brecht Sep 10 '11 at 15:56
  • @maple_shaft: It's great to hear that Emacs is still popular at CMU. It became popular in the 1970's, and I imagine that the newer students use it because other students recommend it. CMU is pretty selective, so learning EMACS would be no problem for most Tartans. Once learned, nothing else comes close. Famous authors agree: http://www.emacswiki.org/emacs/NealStephenson – kevin cline Sep 10 '11 at 17:50
  • What was wrong with supersede? [Supercede](http://www.merriam-webster.com/dictionary/supercede) seems to be the one which is considered wrong, including my spelling check here. – Steven Jeuris Sep 10 '11 at 18:57
  • @kevin, Emacs was something I couldn't pick up in an hour, but you know somebody is good with it when they make it look easy. I have a lot of respect for CMU grads, I learned more just sitting in architecture and design meetings with them than I learned in 4 years of university. – maple_shaft Sep 10 '11 at 19:20
  • 1
    @Steven Low and Steven Jeuris: sorry, you are both 100% correct. "Supersede" is the usual spelling. – kevin cline Sep 10 '11 at 23:11
  • I like this answer, but I'd love to see an accurate source. I looked for it shortly but didn't find anything. – Steven Jeuris Sep 11 '11 at 02:55
  • 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! – Steven A. Lowe Sep 11 '11 at 04:06
  • @StevenA.Lowe I can't find much info on Action Diagrams. Do they have another name I can search for? – Stijn May 22 '13 at 07:07
  • 1
    @Stijn: https://www.google.com/search?q=action+diagram+james+martin – Steven A. Lowe May 22 '13 at 19:30
7

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.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
6

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.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 4
    +1 For Flowcharts recognizable by users and BA's. What tool flowcharting tool do you use? – Michael Riley - AKA Gunny Sep 10 '11 at 03: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 Sep 10 '11 at 03: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 03: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 Sep 10 '11 at 03: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 03:48
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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
2

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.

NoChance
  • 12,412
  • 1
  • 22
  • 39
2

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.

Nick Keighley
  • 754
  • 4
  • 7
-1

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.

mobileHman
  • 11
  • 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.
    15K is pretty small so might be embedded software, that might be "very planned" to ensure it meets its spec.
    The Space Shuttle software was written using the techniques you advocate.     – Nick Keighley Oct 13 '16 at 11:00
  • Also Flow Charts are not necessarily the tool of choice for software design! – Nick Keighley Oct 13 '16 at 11:05