tags:

views:

193

answers:

8

I heard (and think) that modern programmers hardly use flow charts. If you structure your code well you'll have small functions, isolated functionality objects, and simplicity of each code chunks (file/class/function). I also heard talking about flow charts as "spaghetti programming". I personally think that flow charts were (and still are) overrated, and that professors shouldn't spend much time on them. What's your opinion?

+3  A: 

I use the UML all the time. Activity Diagrams replace classic ANSI-standard flowcharts.

S.Lott
+1: UML's definitely a useful tool in the thought process behind software development (for me at least).
Jon Cage
A: 

I agree, professors spend way too much time on them. I believe my professors spent 10x more class time explaining UML diagrams than they did explaining multithreading. Something is clearly wrong there in my opinion.

Still, flow charts, and more importantly standardized flow charts have their place. Especially in larger outfits where dozens of people are working on the same project.

Spencer Ruport
+1  A: 

I'd say that depends on what you're using them for. Flowcharts can be used as a high-level tool to communicate concepts of your application.

If you use them to display the overall control structure of your entire application then flowcharts can be useful.

If they're only used to have a graphical expression of every statement in your code then you can just as well look into your code.

Benedikt Eger
+3  A: 

In some industries, like automation, it is still pretty usefully to know your flow charts.

Most of the non-software technical employers are used to flow chart and do not know any UML. So it is a lot easier to communicate the problem/solution with flow charts then with UML diagrams. I use flowcharts in the help files (for the user) of my programs.

TimW
+1  A: 

Yes 'flow charts' are important. If you are building an application, whether in a team or solo, you more often than not are doing it for a client. To understand what your requirements are, you have to both be speaking the same language. Your client isn't going to understand anything particularly technical, but they understand the business process that you are building into the app - and they get flow charts too. If you don't get the business process right, and capture it into your requirements, the thing you end up building will most likely be unfit for purpose.

It is just as much about communication with your client and project team as it is useful for helping you structure your code, datamodel etc.

edr
+2  A: 

I've found flowcharts very useful.

However I sat through a 3 hr exam once when I had to design an entire system using flowcharts. It wasn't pretty.

FriendL
A: 

I always found flow charts (and UML, and DFDs) to be very useful when doing the initial design of a system. They help to ensure that you don't forget anything, and that your basic assumptions are valid. I'm not sure why anyone would think they were "overrated", unless they were being pushed as the only documentation a system needs. I find diagrams to be much more useful than the "structured English" that they tried to push to replace them. Especially with modern design tools that permit you to drill down into a design, flow charts are a very useful design communication tool. They're good for explaining things to non-programmers, as well. I often find that people understand technical explanations better if I draw a diagram as I explain, instead of having them try to build some arcane mental structure.

TMN
A: 

In some courses, flow charts are used to help people learn how to think about processes in a structured way. Some people have a tough time clearly thinking out processes, and flowcharts help. In my mind, flow charts are a tool to help you think better; they don't necessarily have to server as a blue print for code. In the course you mentioned, it may well be that the professor is just using flow charts as a tool for getting people to exercise the gray matter in between their ears--I'd find value in this.

Jim