They use diamond shapes as decision nodes - if false the flow is to an exit ot anothor modulem if true the flow continues down to the next process. There are other symbols. The rectangle is where the files, field, variable and buffer decriptions might go. There is a "parallelogram" symbol that process are defined in. Processes can also be pointed to with the circular "page" symbol or the "homeplate" symble that designates another sction of the flow chart where a modular process can be discretely defined (using, of course) the same flow chart symbols.

There is also a circular "Q" shape that indicates a tape backup and others, like a "barrel" that indicates an archive or disk drive.

A typical newbie flowchart project usually asks to define the steps in starting the car. The scene is usually set with "you" standing by the car with a set of keys. It may look something like:

(Start)
   |
[Objects: Keys, Car]
   |
[Put Keys in hand]
   |
<Is Door Locked>---  True -- [Unlock Door] - Go to /Open Door/
   |
 False
   |
[Open Door]
   |
[Sit in Driver's Seat]
   |
[Place Key In Ignition Switch]
   |
[Turn Key in Ignition Switch]
   |
<Does Key Turn?> --- false --- goto (Check next Key)
   |
[Start Car]
   |
(Finished)

But when you do a real one - like for a payroll program - you end up describing the income tax schedule, the social security tax schedules, insurance schedules, the input file buffers (employee and time clock), output files buffers (trial balance, timesheets and pay checks) archive buffers (in the US, for example, there is a maximum liability amount for what we pay into social security, so each time a payroll is "run", we would have to look at the archive to assure the employee is not "overpaying". In most cases the input files would updated and saved - an archive process.

I don't think I could have gotten the detailed kinds of projects I am fortunate to get unless three or four things had happened:
1) Learning ho to do big flow charts (in my time we hand did them with a stencil on the back of wide (18" ~ .45 M:-) green bar paper. The big projects took weeks and one consumed about 25 sheets!
2) A stint (in the early PC days) in retail computer sales as software support (in those days, computer stores sold a variety of accounting solutions - some open source) and my job was to install, support and modify them.
3)I had to almost give away my time to get prospects to take the risk of allowing me to design and develop big integrated sytems. My first big project (in dBase II) took 8 months (phase 1) - I made 1200$.
4)I started with no frills tools like dBase II and BASICA (no grids unless I coded something to look like a grid!(. The only way to solve the problem was extreme structural and top down disciplines. I could not hide an ineffective or sluggish solution behind an overly embelished GUI - 80x24 was all we had to work with then - but I wrote some great stuff then - and some of it is still being used now.




>What ARE flowcharts, by the way? I think in the Australian Aborigines' Legends of the "Dream Time People" they were mentioned, but that was eons ago! Nowadays, surely, structure diagrams, Data flow diags, etc.? :-)
>
>>It's been suggested to reduce the number of bugs in our product that developers should write pseudocode and flowcharts. I did this in high school and some in college but never in a real programming job. Does anyone know if this reduces bugs or this is something that we should have been doing all along?
>>
>>Thanks