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.

The beauty of flowcharts - duh

So call me Forrest Gump, but as I am designing a new application I decided to load up Visio and design a majority of the application using flow charts.

I have discovered what a wealth of insight you get into the way the program will work and also how you can break it up into reusable modules.

If you were like me and designing on paper and not doing the "design" up front but coding while designing I would tell you to give flowcharts a chance.  Albeit, as you start coding you will have changes, but not as much as if you coded on the fly.

Anyone else care to share their design methods?

Yours Truly,
Forrest Gump (only not as smart)
Forrest Gump
Tuesday, December 19, 2006
Hey, whatever works man. I'm not that visual of a guy, they don't do it for me. I just find the design while coding, then write the design documentation afterwards works better for me.

I worked for a guy once who could not understand a thing unless you drew a picture for him. He was basically an Informatica programmer (:=).

That job didn't last long...
Steve Hirsch Send private email
Tuesday, December 19, 2006
I like the flowchart approach, but really it's no secret that people think and learn differently.

With respect to this forum, the better lesson is probably to allow as many different techniques as possible in the workplace. If one employee asks for a whiteboard, give him one. If another employee prefers a iterative prototyping approach, let him. And if you have someone who wants neat ordered lists, well, see if you can find a way to automatically generate them instead of rejecting him out of hand.
Tuesday, December 19, 2006
You may want to check out Windows Workflow Foundation. It gives the best of both worlds :)
Masiosare Send private email
Tuesday, December 19, 2006
While I'm from the generation that relexively looks down on flowcharting, I have used a modified flow chart (which includes annotations for data flow to/from files and databases and 'hooked' sections of code) to very good effect. In general, I only flow chart at a high level and only as a documentation/instructional tool, not for up-front design.
Jeff Dutky Send private email
Tuesday, December 19, 2006
I always prefer to draw things first.  It's easier to explain and harder to misunderstand what's going on when you have a picture and if blocks showing the flows.  Also, when it comes time for testing, you can easily point at the various paths which matter.
KC Send private email
Tuesday, December 19, 2006
I make a flowchart automation add-in for Excel. It's geared primarily toward business users who are documenting and/or analyzing their business processes.

Even though I have some programmers as customers, I have to admit I rarely flowchart code myself. When I do it's usually after it's been written. I primarily use them to analyze and simplify hairy sections of code.

I don't really like use case diagrams, so what I use flowcharts for is to create walkthroughs before I develop the UI.
Nick Hebb Send private email
Tuesday, December 19, 2006
Generally speaking, if the technique allows you to make good decisions upfront that actually save you time later, keep it ;)
Yin-So Chen Send private email
Tuesday, December 19, 2006
I dislike flowcharts intensely.  I went so far as to compose a speech "The Evils of Flowcharting".

The result of using a notational tool should be correct (or why bother), concise (or it wastes time), and amenable to change (or it will have to be redone).

Flowcharts fail on all three.  All loop structures end up looking the same, the boxes take up a lot of space, and changing one thing on a flowchart mean redraw time.

That stated, YMMV.  If you are getting good value out of them, more power to you.

I prefer p-code.


Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, December 19, 2006
Once upon a time (1978) IBM mandated that all their software HAD to be designed using a flow-chart template.  Different symbols for GOSUB, IF-THEN, Sequence, etc.

People analyzing that approach (one example is Fred Brooks in the Mythical Man-Month (he worked on the IBM System-360)) found that pseudo-code provided a superior design environment, was less verbose, took less time, and provided better long-term documentation of the design.

Around this time (1978 still) Tom DeMarco and Yourdon develped the "Structured Analysis" methodology, using Data Flow Diagrams.  These used "bubbles" to indicate large pieces of functionality, and used pseudo-code to flesh out what actually occurred inside each bubble.

The insights at the time were that a classic Flowchart is an excellent way to understand an algorithm, but a very bad way to design one.  And that a "higher-level" graphical standard was definitely needed.

These days, the UML standard fills these roles, more or less.  I find Agile Modeling (Scott Ambler) describes a very nice UML subset you can use for design.  And the "Activity Diagram" of UML is basically a Flowchart, so in that context apparently they're still ok.
Wednesday, December 20, 2006
One of the problems with graphics (to me at least) is that when you start putting real life business logic into pictures, the accurate diagrams that result are as hard to read as circuit diagrams.
Steve Hirsch Send private email
Wednesday, December 20, 2006
...this is why I think digrams must not be accurate. They just have to give a general picture, in order to understand some business process. That's all.

diagrams are no spec to be given input as implementation
Johncharles Send private email
Thursday, December 21, 2006
Looking over the comments I maybe should have said it has made the user interaction flow easy to understand.  I agree that making an algorithm with flowcharts would not work well (I p-code would do good) but if I want to know how an app will handle user input or the choices users can make, etc.  I have found it real valuable.
Forrest Gump
Thursday, December 21, 2006
I've found that Flowcharting can be good for the real high level, when you're first starting to organize what data structures to do what.

But it gets tedious for me to create further reasons to have yet another app running at the same time. I use SmartDraw myself, and it gets tedious when I forgot where I typed up a general draft algorithm of how I was going to do something.

Sometimes I type just genral steps in a regualr text file and call it psuedo.txt, but then sometimes if I have Smartdraw open because I had already been doing major high level flowcharting, I'll crate a new document and start typing in a minor algorithm, but I'll forget that I did this part in smartdraw, and later I'll look for this small draft outline in a text file.

I think the goal, for me anyway, is to get some kind of flowcharting tool up on my wall in the living room, but find a particular charting product that is easy to take back down quickly if I find someone new to date and I invite her over. It just doesn't look too suave.

Or just stay with one g/f and 1 month into the rel'p, when she's already over that decision line and decides to keep me, I can put the flowcharting thing on the wall and keep it there. 
This way, it keeps the flowcharing separate from everything else and I have less apps to alt tab between.
Friday, December 22, 2006
>So call me Forrest Gump, but as I am designing a new >application I decided to load up Visio and design a majority >of the application using flow charts.

Hmmmmm, were you involved in this one?

looks beautiful doesn't it :D
Stevo Send private email
Friday, December 29, 2006
I agree with the general consensus that flowcharts are cumbersome and inflexible.

I've chanced, however, upon a fantastic methodology for mapping my ideas, though many of you may hate the very thought of it ... Microsoft Word!  Particularly the Outline View.

Though obviously not intended for the purpose, outline view allows you to build up a structured tree for your processes using pseudo code.  More detailed processes and loops are added by 'demoting' to the next level or moving to body text.  Numbered and bulleted lists also obviously lend to the development.

I've found this a brilliant tool for visualisation and would recommend that anyone try it.

Tuesday, January 02, 2007

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

Other recent topics Other recent topics
Powered by FogBugz