Okay, the reason is, it appears most companies want programmers that are at least FAMILIAR with flowcharting.

The only thing I know FOR SURE about flowcharting is that the rectangle is a process and the diamond is a decision.

Now, I've always felt that flowcharting is mostly just a waste of time and paper space. I wonder what your views are?

1. It's supposed to be a language-independent way of presenting an algorithm :sweat: . Personally, I prefer something else: Pseudo-code. It's still language independent (mostly, anyway), and since most languages follow statements one after another in a sequence, pseudo-code for one language is very much adaptable to another, I feel. And pseudo-code is one-dimensional, similar to how code is ACTUALLY produced, not two-dimensional. Worse, all those drawings in flowcharting have their own individual meanings and 'syntaxes'. It's like learning yet ANOTHER language, and worse, one that the computer cannot possibly understand.
2. Waste of time drawing. You can't SERIOUSLY tell me to open up Visio just to let me visualize an algorithm, can you? I'd prefer to put algorithm-related notes in a text file, or at the end of the source code after END start. That way I just open up QEditor or Notepad.
3. Can any of you imagine a FLOWCHART for something like... A-star pathfinding?? If I were to see one, I'd probably run screaming away.
Posted on 2004-06-21 06:23:41 by AmkG
I don't flow chart, per se. However, when I am architecting an object model (for a C# application) I will create a UML chart for the interactions and for the objects themselves. But for little else. I have an amazing ability to produce well-rounded and easily maintainable code without any kind of design up front except for intense thoughts but I have learned, when creating true object oriented applications it greatly helps to have it on paper and I've worked out so many kinks in a design by doing so that I think it has its place. On the other hand, I find it very time consuming but it all but makes up for it because if I spend time working it out in UML it takes me about 1/3 the amount of time to actually implement it.

I can't see myself actually flowcharting an algorithm or a workflow unless there is something necessary to visualize (like an architecture) but never for an algorithm (I really don't write too many of them in my line of work and when I do, I use psuedocode).

Posted on 2004-06-21 10:00:59 by _Shawn
Hmm. Well, perhaps I'd agree with using charts for OOP modelling, to help visualize the relationships themselves (and separate the areas of responsibility...) although I haven't done really BIG oop designs anyway. Certainly it would seem to help, now that you point it out - if there's something wrong with the way your code makes the data relate to each other, then it can be seen by glancing at the data flowchart. But my main beef is that darned flowcharting of code flow. It seems to me that flowcharting the data structures to know just what types need to refer to what other types would be useful, but code? Somehow I think code flowcharting makes you want to think of the code in only one way, and may therefore be a HINDRANCE in debugging rather than a help.
Posted on 2004-06-22 03:50:58 by AmkG
Well I learned flowcharting in college (yes Im that old), and i used in programing fortran and 6800 machine language, today I don't use is much
except in the early stages, to clarify relationships between modules, files and somesuch, almost all my programing today is in Win plataform, in C and assembler.

Now, some people is visual, (like myself), a image told more that a thousand word, and some not, if you feel flowcharting helps you, use it,
now if your employer *wants* you to learn it, well you had to,

and yes flowcharting Is a Language (the only visual language)

Saludos desde Mexico
Posted on 2004-09-02 14:36:57 by Carlos
I use it when i want to optimize complicated algorithms
however i draw it mainly on paper... and redraw and draw again.

I do not use it very offten...

Like most things in capitalistic world UML/Flowchard/architecture requiremnts and stuff are just nice lies to get the money going arround...
you have to understand that, and live with it...
Not to fight it and say that it is useless...

Carlos is right ...
IF the man pays you money then he has the right to ask that you do BEHAVE as he wants you to... an not as you like. (same as in prostitution but it is called "a JOB")
The only thing that matters is how well you can do it :D

Obviousely it is not useless for the people that are using it...as it helps them lie themselfes and survive in such a world :D

Posted on 2004-09-03 11:44:15 by BogdanOntanu
It is nice to have a reference for where you are (or should be) on your project. Just make sure not to over or under do it. Too little focus and you might get side-tracked, too much focus and you bump into the inefficiencies of micro-management.
Posted on 2004-10-03 10:44:34 by SpooK
LOL, so far in the job offer I accepted I haven't been asked to do a flowchart (I just explain the step-by-step procedure and my immediate superior starts writing a basic flowchart, which I try to keep my eyes off of because, well, I think flowcharts really look weird.) Besides it's one heck of a lot easier for me to document code by explaining the logic of it in an essay-like paragraph rather than via a flowchart - because I can also tack on the "why I thought this approach is better" and "why doing this particularly weird sequence of events works", which I believe are not evident in flowcharts. I suppose the more graphical of other people would find it hard to follow, but I'm a literature type of guy, I prefer to read and understand stuff that way. The only time I take the effort of building ascii charts is to show DATA structure relationships, particularly since we're programming on a LISP variant (where data structures can be particularly convuluted - LOL and I tend to make lists that end up referring to a list that refers to the original list, wahahaha).

Oh and yeah - LISP rocks. Self-modifying code, here I come!
Posted on 2004-10-21 08:30:00 by AmkG
When I started programming, flowcharts were almost the only design tools we had. There was an obscure language called PDL (program design language), which we would now recognize as pseudocode. Structured code came later, and it encouraged pseudocode. Warnier-Orr diagrams came after structured code as alternate (noncharting) design tools.

As many programmers opted to produce flowcharts after completing a project, it is far more common as a documentation tool rather than a design tool. I have encountered them in documents for "how to configure/program" a programmable device, and "how to process USB with this device".

It might be noted that in the above mentioned documents, the subjects are documented several ways. There is a text document that explains the what-happens, how-tos, whys, and wherefores. The flowcharts are basically one form of summarizing the text document. Tables and lists of features are other forms of summary.

Like many programmers, I prefer designing with pseudocode, and relational graphs. However, I find that flowcharts as a summary to a document, can be useful.
Posted on 2004-10-21 16:08:48 by tenkey
My boss at work makes me flow chart even the simplest things. Once he asked me to flow chart the database structure. Then he analyzes my algorithm, and starts criticizing me. I hate my job.

Flow charting is useful, but most of the times it is possible to recursively breakdown a task into smaller components. You would have the first hierarchy in your mind, lay the foundations for that, and then break down each smaller task down to even smaller ones.
Posted on 2004-10-21 16:46:00 by comrade
I have a strange dance I do around the code:

First the big outline - high-level, doesn't say much about internal relationships. This usually becomes the outline for the documentation, too. It is my view of the user and how they use the functionality of the software.

Starting at the top of the outline, I begin coding with the awareness of all the features needed. The overall awareness helps me keep the design open enough without getting too bloaty, or losing scope of the problem.

The process scales as some features require their own outline to explain the functionality.
Posted on 2004-10-21 17:05:01 by bitRAKE
Carlos is right ...
IF the man pays you money then he has the right to ask that you do BEHAVE as he wants you to... an not as you like. (same as in prostitution but it is called "a JOB")
The only thing that matters is how well you can do it :D
I like the metaphor, but think maybe your pointers are nested too deeply. Every "JOB" is a relationship. Sure they might tell you how they like it, but they have hired you based on your expert skills. The greatest of which is communication. The secret to information theory is that he (Shannon) was trying to describe communication dynamics - information is just the medium, communication is the process - we need both for anything to happen.
Posted on 2004-10-21 17:23:38 by bitRAKE
almost like bitRAKE, I first define the highest level structure of the code in text:
1) startup screen, load graphics into engine
2) load last savestate, go to current level
3) get sys msgs, get keys
4) process game
5) draw game
6) load next level if necessary
7) unload graphics, release screen
8 ) save state,exit

then, I add detail:

1.1) create backbuffer
1.2) load dynamic sprites
1.3) load static sprites
4.1) get msg queue
4.2) move player, bind to level
4.3) move enemies, bind to level and do physics
4.3) process weapons
5.1) draw level
5.2) draw enemies
5.3) draw player, depending on action taken
5.4) draw weapons
5.5) draw effects
x1) load sounds, startup sound playback
x2) load songs
x3) render sounds selected
x4) stop sound playback, unload sounds

and so on. It's best to decide in the beginning what you want in the software, and what you can do, what compromises have to be made. Pinpoint the wanted result, then you can add details. I never use flowcharts since it'll be hard to add the details later - have to redraw and rearrange stuff. Also I add notes about random nice ideas to insert (later decide how).
I make the OOP stuff in separate projects first - test and upgrade thoroughly, then usage of objects is done almost like with temporary vars - for me there's no difference after all.
Posted on 2004-10-21 17:50:36 by Ultrano
IMHO that style should be every programmer's style: Figure out the top-level first, split the project into ever-smaller problems (which you recursively split, which means building a tree structure), then start building everything. Although I tend to go right down to the bottom level leaves (just so that I have something to point to and say, "well, Boss, I've finished this part and we can use its partial functionality and I think it'll work about 99.9% fine" lol I never say 100% fine - that's the halting problem), and build upwards, but always with an awareness of how the uppermost level was designed to be (with inevitable modifications, of course, based on 1. things difficult to do in the language, and hence representing a design flaw in the original top-level, and 2. new things the boss wants added).

I think my main objection against flowcharting is, really, the fact that it CONSTRAINS you to a very specific approach to a problem; that is, it doesn't give that much room to add a few new things. There's a lot of erasing and redrawing (or at least, dragging them around).

LOL bitrake, that's not a strange dance, it's called "The REAL Way of Designing Programs" (joke!!)
Posted on 2004-10-22 08:46:36 by AmkG
BogdanOntanu, maybe I just prefer more skilled prostitutes. :-D
Posted on 2004-10-22 10:47:56 by bitRAKE
BogdanOntanu, maybe I just prefer more skilled prostitutes. :-D


Not knowing *shit* about it (yes, sad to say, I'm 21 and still a virgin), I'd say I'd appreciate a skilled prostitute rather than someone who'll just follow what I say (because I wouldn't know what to order, anyway.). Given that most of the other guys here are electronics engineers with only the most basic knowledge of programming, I guess I fall in the "skilled prostitute" list, LOL.
Posted on 2004-10-23 04:29:42 by AmkG
Of course flowcharts are useful lol, in my SMS emulator, it helped me design the SN76489 PSG emulator and the VDP emulator.
Posted on 2004-10-26 22:38:14 by x86asm
I agree,

in school, they teached us first FlowCharting before anything else.
flowcharting is a must to know in order to break up complex tasks into pieces.
Posted on 2004-10-27 03:56:22 by wizzra
I don't do "proper" flowcharting, but I often find it usefull to do some stuff
on paper before coding it. Especially when it's "hard" stuff with lots of jmp's
up and down..
Posted on 2005-04-27 07:26:04 by bubach
A "soon" of flowcharting is UML, I have readed that in some way UML is flowcharting, but UML have more strong base (aka mathematic or some like that????), then I supose that is a lot of flowcharting there, also there are design patterns :) that can be showed with them. In the same text is argumentated that if you dont know well the design with UML you will terminate doing flowcharting ;) (sorry cant find such article again then no reference...).
Posted on 2005-04-27 10:12:40 by rea
So far, I haven't had a use for flowcharting.

As it happens, my most natural design flow is simply to implement anything.  ANYTHING AT ALL.  Something simple from already existing bits of code.  I then tie them together and implement something with a higher-level function.  Then I tie THEM together.  Then I tie THEM together until I have some tool that does something really useful.  Lots of things I've made didn't have much of an overall design (well okay, I probably have some kind of background task doing the overall design so that my foreground task handles little details, wahahaha).

It helps bootstrapping a lot, too.  I write a higher-level function using lower-level functions.  Sometimes those little simple packages just don't cut the performance requirements, so once I get the higher-level function running I replace them.  But in the meantime I've got a version running (sub-optimal true, but still working), and I'm relatively sure that my higher-level logic is probably correct.  Somehow, just trying to figure out if a piece of code works IN THEORY doesn't sit well with me, I want to see it actually running.  Oh well.  LISP does that to you I think (imagine, compiling while you enter code!).
Posted on 2005-05-08 12:36:09 by AmkG