>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

Others have given great responses. One of my early projects graced me with an all expense paid 9 months at a professional center to just learn flow charting.

Any project [usually] gets an outline of some sorts. For small projects where we are familiar with the industry and the list integrations of the project revolve around a modular service, then a minimal approach would work.

In cases where we write integrated systems (AP/AR/OE/SO/PO/WO/GL) and/or servicing an integration for an industry that we have little or no experience with, a flow chart would be helpful (at least we can associate new terminologies with our "organic" understanding of software design and stucture).

One of the best uses of a flow charts (not the organizational charts) but detailed flow charts would be to estimate a budget and delivery schedule for those heavy projects. They also help isolate pieces of the project that need more attention. It is also a good practice to isolate the difficult areas first , decide on how it is to be handled and develop a proof of concept (write a test model to assure we can make it work) - and then begin the top-down coding to build it.

Big projects are only difficult when a localized process depends on the reliability (tolerances or bugs) of a particular control or concept. All the time invested in the project to that point can be like a rock around our necks. It is best to isolate those cases first - and solve - or at least come to an understanding that the design will work.

It's a lonely world when you are there. It even gets more frustrating when we ask for advice and we get product reccomendations rather than work arounds or fixes. But most of the stuff VFP and OCX offer will work just as expected - and we need to be confident that it can be solved, regardless of the reccomendations or them pesky forces of selfdoubt.