I’m a visual person – I always need a picture. As a consultant, many times I’m given a thumb drive full of code and asked to make modifications. When you are on a project with me, you’ll grow weary of hearing me say “Can you draw it?” Something magical happens for me when I see a flow or see an idea.
One of the most confusing projects I ever worked on required completely re-writing a job that had more than 100,000 lines of code and had grown out of control over a 5 year period. I’ve come to see this situation as an industry hazard. For SAS Global Forum 2011 I wrote a paper called Plate of Spaghetti Anyone? about learning someone’s else code. I created a flowchart for the code before I started but it was impossible to read. It was so impossible, we finally started taking requirements from the code and tossed most of the code in the Unix trash can.
For the remake, I created many flowcharts with my good friend MS Visio. It helped the managers understand what was going to happen. The person who came behind me most likely thought the process was confusing but received more documentation than I did about what the code was designed to do and how the flow worked. It was a good learning experience for me as well. Now the first thing I do is start creating flowcharts when I’m handed code or even requirements documents.
Really when you think about it, flowcharts are just another example of data visualization. You are creating a drawing from words to show how the data flows through the program and quickly communicate the data transformation.
Here’s what I learned from drawing and reading a gazillion flowcharts for SAS programs.
It’s Not Always 1:1 Relationship with Code
It’s useless to map SAS programs in a flowchart step by step. Unless the program has macro code in it, any logic statements are usually within a data step or perhaps a PROC SQL statement. When I have tried to do it in the past, I realized that the diagram usually looked like the following one and rarely explained anything other than it took a lot of steps to get where it was going.
The above example really could be any one of 10,000 SAS programs. All it really shows is the actual steps the programmer used but it doesn’t really help you understand why the dataset was created. You really just know it was taken from a data source, changed in some way, sorted and given to an information map. You could have guessed that much before you looked at the flowchart! In this example, the logic is all occurring in the data step. This is why programs that map the steps are useless for understanding the code.
Now consider what happens when we actually plot the purpose or the logic of the same program. We can see where the 3 steps are used but now we understand that we are determining if the customer orders are on time by business unit. It outputs the results to a table ready for an information map – this is a simple example because an information map could have complete these steps. [You can create info maps from code – did you know that?]
Flowcharts that Make You Groan Like Broken-down Machinery
Here’s an example of a flowchart that breaks all the rules of communicating a process quickly and with ease. I did find this on the Web but it’s not important who did it or what it’s really about – you can learn from the example.
Where does it start and when does it end?
Use indicators that show where the process starts and ends. Users need to understand what causes the process to start and when it ends. Remember the person reading the chart doesn’t have any idea how it works so they don’t know where the user or data enters the process. I start at the upper left corner for no reason other than that’s how most people read text on a page.
It’s helpful if you use the same shapes everyone else does – like a process is a box, a decision is a diamond – you get the idea. Check Wikipedia for more flowcharting basics.
Check your logic!
Study this flow chart – notice that the same steps are there twice and it’s based on if the child comes to the appointment. Why not have the person review the records and then determine if the child is present? It would only have to be there once. If the child shows up 95% of the time – do the chart from that perspective. Think of your SAS program the same way, what is the main logic path. You want to show how you handle exceptions but typically your program is about handling what is right. When the chart wraps around itself the main path is not clear. This is a smaller chart so there are probably less consequences, but complicated logic could make this really confusing. Try to avoid having your logic wrap around the page – use more pages instead. Remember you are trying to communicate clearly not save a PDF page.
Have your decision points always go the same way. Its confusing when the Yes is sometimes going down and sometimes going to the side. Change the question to make the logic flow the same way. In this chart, only one Yes actually goes down so the reader can be tricked. Many flowchart professionals say the “Yes” or “True” always goes down – I say just be consistent.
Flowcharts You Love Like Your Momma’s Cookin’
Ok – it’s my flowchart – of course we love it! It’s the flow for my macro that check the batch log and sends an email based on what happened. Here’s how I might have done the flowchart for the code. Notice that you never see a SAS word like data step, proc sql, and so on.
Notice that the logic inside Step A is a little more complicated so I expanded that into a second chart. This is an example of how to handle a larger process when you have multiple paths that need explanation.
Never miss a BI Notes post!
Click here for free subscription. Once you subscribe you'll be asked to confirm your subscription through your email account. You email address is kept private and you can unsubscribe anytime.