The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Getting the Fishies Out: Flowcharting After Coding

I know some developers chart out their programs on paper as flowcharts before programming, to organize their programs' structures, decide on subroutines, etc.

Some of my *existing* code is a bit of a mess: redundant code, code that probably-does-something-so-I-can't-delete-it-even-though-I-have-no-idea-what-that-something-is. I was thinking, "Hey, I can make a flowchart of what my program is *supposed* to do and then compare my actual code to that. And then throw out what's not supposed to be there, re-organize my subroutines and so on."

Does anyone here do this? Any thoughts?
Ari Berdy Send private email
Thursday, January 05, 2006
I would do it the other way around, flowchart what you see, not what you believe.  Once you have completed the flowchart, you can easily see what's superfluous and/or can be refactored.

If you decide to do nothing, the flowchart is still invaluable when fixing bugs or adding new features.
Anonymous Coward
Thursday, January 05, 2006
I'm *not* saying that you shouldn't create a flowchart before you start programming--I'm all for that. I'm just saying that it could be extremely beneficial to do so after programming, even if you didn't do so before.
Ari Berdy Send private email
Thursday, January 05, 2006
There are a few flowchart tools out there that will generate flowcharts from your code, such as this one:

I haven't tried any of them, so the above link is just an example, not an endorsement.
Nick Hebb Send private email
Thursday, January 05, 2006
I typically find that flowcharts are way, way too low level to give reasonable information on anything above the method level.
Chris Tavares Send private email
Thursday, January 05, 2006
Historically (see Fred Brooks, The Mythical Man Month) it has been found that Designing with Flow Charts does put you at too low a level -- you can be more productive using pseudocode.

However, flow-charting a routine (after its written) has proven to be one of the easiest ways to understand what it is doing.  And reveal various problems with the design, if they exist.

So, flow chart for design == bad, flow chart for understanding == good.

Personally, I find "Understand for C++" to be extremely useful for analyzing existing code -- not to the flow-chart level, but down to the module call tree it is excellent.
Thursday, January 05, 2006
I've done a post code flowcharting on some nasty bits of workflow / integration / conversion / branching code and kept on file to:

a) refresh MY brain months later when someone wants a change or has reported and issue

b) to help other coders figure out what the heck is going on in this rats nest (a good deal of pre-existing code ... not making excuses, mind you, but ... ) and

c) to help analysts and support folks figure out if the reported behavior is "as expected" without haveing to come to me ....
Thursday, January 05, 2006
Thanks, everyone, for the input! Thanks, Nick, that looks like a nice product, but a drop steep right now.

I currently *do* use pseudocode when designing a particularly complex subroutine or just when I'm having trouble concentrating and find it very, very helpful. After writing the structure in pseudocode, the subroutine , algorithm, or whatever looks a lot less intimidating and can more easily be actually coded, piece-by-piece.

Another thing I've done and found very helpful is putting to paper what I want the *end result* to be, either internally (e.g. what data I want where in an array), or externally (e.g. what I want a text box to display). I can then more easily figure out what needs to be done, "Well, to get "Bob" into Employees(42) I'd need to..."
Ari Berdy Send private email
Friday, January 06, 2006
I found that flowcharting only works well when it is utilized in the early stages of design and coding. With this software, it can definitely reduce the original time to generate one manually, but there are still details that I incorporate that make reading a flowchart very simple or specific to customer needs.
Chris Matson
Tuesday, January 10, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz