Go Down

Topic: Tip for newbies: flowchart your ideas (Read 4684 times) previous topic - next topic


Once in a while I remember the right way to do something.  ;)  This evening I was trying to figure out how to get my sketch to go through some steps and I remembered one of my favorite tools: the flowchart.

For those of you who don't know what a flowchart is, it's simply a diagram of all the things (or a subset) your program does, and how the execution of the code "flows".  It includes decision points, states, process flows and such.  Entire courses are taught on flowcharting, but you don't have to have anything fancy to get your ideas out on paper.

The key to flowcharting is to put all the details down in the chart, with arrows and lines that show where to go next and why.  Then you don't have to think about how to solve problems while you're writing your code.  You only have to think about the code itself and writing in your comments and stuff.  Much easier when you're still learning how to just write code.

You can draw it on paper or use a program for it.  I use the drawing program in Open Office http://www.openoffice.org/ and it works well.  And you should break up your ideas into sections and do flowcharts for each.  Include points where one flowchart leads into another.

Here's a couple examples:

In starting this thread, I'm hoping to draw out some knowledge from other folks on the forum.  So if you have some flowcharting expertise to share with the n00bs, please reply.

And if you're interested, feel free to post questions about flowcharting.  I can help get you started.



I have found that making flow charts helps organize my ideas into something usable.

I like how yours are color coded and neat, unlike mine ;D!


If you ever want the ultimate in flow charting, check out Six Sigma.

Actually, Six Sigma goes waaaay beyond flowcharting; its a methodology that encompasses a vast amount of knowledge on understanding processes, process flow, and how and why errors accumulate in processes, and how to measure for these errors in order to correct them effectively and efficiently.

Flowcharting (known in Six Sigma as "process mapping"), when done properly, can do much more than map out how something works; it can quickly tell you, visually, whether your process is correct and efficient.

Your first step is to define your problem; you must do this in a concise, logical, and complete (to the best of your knowledge) manner. Every detail of the process to address the problem shouldn't be written down at this stage, but the general idea should be there.

Write it down on paper; think about it, does it seem complete? Does it feel correct?

Once you have done that, work from that description to generate your first process mapping iteration. Use boxes for the processes within the overall process, diamonds for decision/branching, circles for start and end - parallelograms can be used to represent data in and out; be sure to use arrowheads at the end of lines connecting each item to show the direction of flow (never put two arrowheads on the end of the same line; use two separate lines with individual single arrowheads).

At this stage, you should only have a minimum of boxes and branches, because the problem was so generally (but accurately) defined. If you have way more than needed (and this can't be defined; it depends on the problem domain and the skill of the person or group involved in creating the process map - you get better as you practice), or if things are defined incorrectly in some manner, you will be able to see it on the flowchart. A sure sign of a problem is if you have lines all over the place or crossing each other too many times; it is a visual version of "spaghetti code". Indeed, if you flowcharted such a piece of code, you would instantly see the real visualization of the process; it isn't pretty!

Once you have this first iteration concise and clean, look at each box on the diagram. Can they individually be broken down into their own processes? Most likely, they can, if you think about it carefully and logically. Take those areas, and process map them (in the same general manner to the best of your ability and knowledge as you can). You will either want to fuse this detail of the map within the same structure as the first iteration, or you will want to note in the process boxes on that iteration a note for a the detail (ie; see "flowchart_1b"); many programs that allow you to flowchart provide a method whereby you can link from the process box to the flowchart which represents it.

After process mapping, perform the same check again on the map: Is it too complicated? Are there lines crossing? Does it look messy?

Once again, you'll generally be able to spot problems visually. Correct them (if you can) and move on. Sometimes, these problem areas might actually be caused by missing a step, or not thinking the problem domain for that area of the overall problem completely through.

Continue this iterative approach to the problem in order to study the entire domain in detail; the level you ultimately want to try to strive for is something akin to understanding the process to  take apart a brick until you reduce it to atoms. This degree of  attention to detail isn't always practical or possible, but always try to strive for it.

If you process map a problem domain effectively (especially if it is a process involving human interaction and effort; processing mapping the problem of bug tracking is an interesting area), you will quickly find areas of the problem where people honestly don't know (and don't generally think about) how the process worked, until you ask them and discuss it with them. In many cases, the problem or part of the problem is solved in a "soft" manner; which generally involves a social aspect or something (ie, calling and discussing an issue with somebody) outside hard inputs and outputs - even so, they should be properly process mapped; they are a part of the process.

That leads to the final piece; one that leads more into the meat of Six Sigma: Every process has inputs, and outputs. Know these items for every process in your problem domain. Know and understand how the outputs of one process flows into the inputs of the next. Once you know them, you can then apply numbers to them, as well as devise a process scoring system.

This scoring system (which are almost always customized; though I think there is a Sig Sigma Patterns book for some common problem domains and such) ultimately allows you to see how well a process is working, and how changes to one or more inputs of a system affect the other parts (via propagation and otherwise).

This is just a high-level overview, one in which I probably missed something or got something else wrong; I never studied Six Sigma in any depth, I just worked for a membership organization here in the Phoenix, AZ area as a web developer for their website (which was an amazing project in and of itself, actually). I will gladly defer to anyone's deeper understanding of this topic. It is a very complex system of systems and methodologies, as I noted previously.

Hope this helps someone!  :)

if you lay out your problem efficiently, starting with a general overview
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.


Feb 14, 2010, 12:13 pm Last Edit: Feb 14, 2010, 12:14 pm by srylul Reason: 1
I am "all in" to know what to do before actually doing it!.
Workflowing is a good old way to sucess.
Currently I am trying to use RTH, Requirements and Testing Hub.
Not as graphic as flowcharts, but helps me to do a better job when other programmers/testers works in my project.
But tell us about Six Sigma: Is there any good open source tools for using it? Looks like many adopted it, wich is a good point of using it.


Wouldn't it be a better idea to use flowcharts directly when programming ?? check out YENKA (google it)


But tell us about Six Sigma: Is there any good open source tools for using it? Looks like many adopted it, wich is a good point of using it.

I am not personally aware of any open source tools; 6S is really a methodology that encompasses quite a lot of areas, flowcharting being one of them.

Since 6S is focused on reducing errors in processes and increasing output, it is very management and higher-level oriented; most tools that are marketed toward 6S professionals (of which, I am not one; I only worked briefly for a business that acted as a "membership society" for the 6S community - http://www.isssp.com/) tend to reflect this, and their cost trends toward the upper end of the scale...

That doesn't mean such tools don't exist - or couldn't be developed. Really, much of what we did at ISSSP didn't involve software - flowcharting and such was typically done in round-table discussions on whiteboards and large flip-charts. This facilitated a quick exchange of ideas and thoughts on flows and how to best capture them. If something was wrong, it was easy to see in the flow, and could be updated rapidly. We found that once we could settle on a flow, we would then capture it with Visio (perhaps with extra notes and documentation). We could then represent that entire flow as a simple "sub-process" box in a larger flow, and continue with capturing the rest in future meetings.

Ultimately, it worked well, but was probably waaay overkill for anything like you would do on an Arduino - but could be used for larger/more complex processes, of which the Arduino might only be a small part of.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.


Wouldn't it be a better idea to use flowcharts directly when programming ??

Sure, just like it is a great idea to architect a house as you build it...

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.


Flowcharting, how quaint!

I love hearing electronic engineers talk about programming ;)

Actually for the few dozen lines of code you can squeeze into an Arduino, its fine. Minimal quantities of classes, and no multiple threads of execution to worry about (apart from the occasional interrupt).

Its a useful way of expressing thoughts, other useful ways that 'real' software engineers use are: state diagrams, sequence diagrams and use cases. Have a look at UML for lots of other nice thinking tools.

Can I feel the flames flickering around my feet?
I write books about Arduino and Electronics: http://simonmonk.org


Can I feel the flames flickering around my feet?

they make a spray for that you know

Coding Badly

...other useful ways that '[glow]un[/glow]real' software engineers use are: imagining objects as living entities traveling about in a silicon world talking with each other and occasionally get into fist fights.



Sep 14, 2010, 10:13 pm Last Edit: Sep 14, 2010, 10:15 pm by whiskey Reason: 1
flowchart meet life, life meet flowchart

wish me luck... [smiley=beer.gif]


wish me luck...

More importantly: have fun!   ;)


Sometimes I use postits to denote each step in my process. This might be helpful when you deal with very abstract problems.

Microsoft Visio is a great tool in my opinion, although I still prefer to do the early flowcharting (and other mindmapping) with physical material.

@Coding Badly: it's even better when the fistfight stops, and the flyswatter gets its turn to dominate. Bugs away!


Have a look at UML for lots of other nice thinking tools.

I was going to say the same thing, too bad the are no good open source tools for that either.  The open source netbeans and eclipse plugins for it are dire.


hi! i am new here. is there some introduction section? I have been searching for it.

Go Up