Does anyone actualy use flowcharts for nuts and bolts code anymore?

Question

When in school it was often a requirement to flowchart the little programs that we wrote line for line.

Those flow charts tended, due to the size of the pictures, to be very large and were often tedious to draw.

It was always to such detail that you were essentially writing code anyway.

I use flowchart/UML style techniques to develop higher level things but when it gets down to actual loops and what not it seems like overkill.

I will often pseudo-code more detailed algorithms but still not to the super fine grained point.

Is this just one of those things where in school things were so tiny there would be nothing else to 'Flow-Chart' so they had use do the minutia?

Answer 1

Flowcharts, no -- Sequence diagrams, yes. I try to keep them at a very high-level to communicate the idea to someone quickly. I do not try to get every detail in. I might supplement with another diagram to show an edge case, if it seems important.

It's great for communication as a sketch -- I think it's not right for a specification (but would be a good intro to a detailed section)

Answer 2

Yeah, I agree. The point was to get you to understand flow charts, not to imply that you should use them for line-by-line code coverage.

I don't know why you'd even waste time with pseudo-code except for demonstration, honestly, unless it's some really low-level programming.

Answer 3

Flow charts for the ifs and whiles of real code, never (in 30 years) found useful.

As a discussion aid for elicitng requirements ... so when we're here, what could happen? ... how would you decide ... what would you do if it's > 95% ... Can be helpful. A certain kin d of user finds such diagrams on the whiteboard easy to talk about.

Answer 4

I don't find great detail in a flowchart to be very helpful. I use UML-style techniques on a sheet of paper. Use a whiteboard in a group setting. Mid-level class diagrams and sequence diagrams can be extremely helpful to organize your ideas and communicate your design intentions.

Answer 5

Sometimes on a whiteboard to describe a process, but never in actual design or documentation. I'd describe them more as "flowchart-like" since I'm not always particular about the shapes.

Answer 6

To be absolutely honest, I am extremely glad I was required to accompany any assignment with flowcharts. They made me think structurally, something I was lacking (and, perhaps, still lacking to a certain extent).

So don't be quick to jump on a "I'm off to play the grand piano" bandwagon, flowcharts really do work.

Not once did I find myself in a bit of a bind in non-trivial logic. After laying out the logic in the flowchart form on a sheet of paper (takes a couple of minutes), it all inevitably becomes clear to me.

Answer 7

I don't use them myself. But a coworker who only programs every once in a while does. It's a very handy way for him to remember the nuts-and-bolts of that program he wrote a year ago. He doesn't do much programming, so it's not worth it for him to learn sequence diagrams and things like that.

It's also the type of diagram that other pple that hardly ever program will be able to read easily. Which in his position is a plus.

Answer 8

We have an in-house application that has some fairly complex workflow in it. A flowchart forms a big part of the spec of this part of the system. So yes, Flowcharts are a useful tool for spec'ing a system. They are also normally understood by non-technical people which is useful if they are part of a user requirements. No, I would not normally use them at a very low level, nor would I expect part of a system to only be spec'ed or documented by flowcharts.

Answer 9

TDD is a good option for nuts and bolts code, if you are so inclined, and it comes with a lot of other benefits.

Answer 10

We have a large organically grown application that has very little documentation, so using flow charts to document components within the application has proven very usefull to the business side of the operation, as even they don't understand how everything fits together.

They aren't at line by line level, but do cover all branches of business logic with the subsequent processing and outputs (although not following strict flow chart rules - some blocks describe multiple processes).