>>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
>
>I'd recommend Yourdon/DeMarco Structured Systems Design, if you have time but, as you've said, and others would sympathise (myself included), one rarely gets this luxury in the real world. If you're doing this really from scratch, including interviewing users and ascertaining each process, etc. - learning from grass roots, I'd go for it.
>
>Very interesting book and very amusingly written.

Actually I'm (supposed to be) using that one day-to-day, and it really is based on solid ground, except in the few bits where it's obsolete or where it talks about big-iron code to maintain dictionaries, which is useless today.

The good part is from the requirement gathering to the data flow diagrams. The rest, specially the metadata it proposes etc seems superfluous nowadays - dbc itself seems to be a better data dictionary than that.

The nice side of this is that you can split your work into manageable slices; you can isolate the parts which can work before other parts are finished, so you get something that can be tested as you go. And you also get to tell your boss that "sorry, but can't do that now, that feature is not in the section that's in the works now" :)