When I was going to college I used to dread having to do a flowchart before I wrote a program. I did not understand why I had to write something down that I thought I had all figured out in my head. I thought that every single one of those shapes were just an excuse to make me work extra. Flowcharts have really made a difference on how I program.

I have worked with several people that did not go to school for programming but just picked it up while working for a company. Some of them have been pretty good programmers, but others have had a real issue with logic. Flowcharts help you map out logic and they are an important tool when trying to improve any existing process.

I worked as a Process Analyst, and while the title at first was just that I did get to work improving some processes that were already implemented in the company. Some of them were closely related to software, some were just processes that mapped how the company did business. Every meeting that I had with a team that wanted to improve one of their process started with me drawing out a flowchart of their current process. It was amazing how much of the process was not clear to people at different levels of the organization, or how some people simply did not understand the flow of the process. We were able to not only improve the processes but also find huge flaws on the flow by simply mapping it.

I think that making a flowchart of what you are going to program is a very good idea if it is a process that you have never worked with or you are not completely sure on the business logic. Many times when I have been stuck working through some logic, drawing a flowchart has help me figure out where the error in my logic is.

When you inherit code from someone else, it can be a nightmare to understand the way the thought. You might be the person that thinks in positives while the person before you think in negatives. Also there are programmers that love to over complicate simple tasks by either writing long functions or over nesting decisions. Don`t be too affraid at this code because you are going to have to work with it eventually. The simplest way to figure things out is to write a simple flow chart that will map the process. You do not have to map the whole program just the parts that are complicated or causing you problems.

Programming languages aim to simplify the way you write code. They complete your code, let you overload operators and even assign the result of a comparison like do we have any records of that type. For example,

if RecordCount > 0 then
Button.Visible = True
Button.Visible = False

can be written in some languages simply as

Button.Visible = (RecordCount > 0)

When I encounter a piece of code that does not have the if then else statement written out, I understand what it means but it is harder to visualize in my head. The example above is pretty straight forward but think about how complex a comparison can become or what property it could be affecting. Drawing out the flow chart with all of the decisions makes it easier to visualize all of the options that are available and helps you determine the true flow of the program.

If you are ever stuck with a piece of logic and one of your programs or websites is not doing what it is supposed to be doing try drawing a flowchart and trust me, it will help with debugging.

One comment on “Flowcharts

  1. Does this place a limitation on the kind of programming language you will end using? What if the process is recursive?
    Oh, I see now!

Leave a Reply

Your email address will not be published. Required fields are marked *