NOTE: I'll be Busy at SAS Global Forum! #sasgf13

I was very pleased to be invited to present a paper at this year's SAS Global Forum in San Francisco in April/May. To then have my contributed paper accepted too was icing on the cake. I don't yet know the dates and times where my two papers will be on the agenda, but it looks like I'll be busy this year.

Firstly, I was honoured to be invited to present "Visual Techniques for Problem Solving and Debugging" in the Reporting and Information Visualisation stream.

Abstract: No matter how well we plan, issues and bugs inevitably occur. Some are easily solved, but others are far more difficult and complex. This paper presents a range of largely visual techniques for understanding, investigating, solving, and monitoring your most difficult problems. Whether you have an intractable SAS coding bug or a repeatedly failing SAS server, this paper offers practical advice and concrete steps to get you to the bottom of the problem. Tools and techniques discussed in this paper include Ishikawa (fishbone) diagrams, sequence diagrams, tabular matrices, and mind maps.

And I had already submitted "Automated Testing of Your SAS Code and Collation of Results (Using Hash Tables)" into the Applications Development stream. It was subsequently accepted.

Abstract: Testing is an undeniably important part of the development process, but its multiple phases and approaches can be under-valued. I describe some of the principles I apply to the testing phases of my projects and then show some useful macros that I have developed to aid the re-use of tests and to collate their results automatically. Tests should be used time and again for regression testing. The collation of the results hinges on the use of hash tables, and the paper gives detail on the coding techniques employed. The small macro suite can be used for testing of SAS code written in a variety of tools including SAS Enterprise Guide, SAS Data Integration Studio, and the traditional SAS Display Manager Environment.

So, if you're attending SAS Global Forum this year, please stop by one or both of my papers, and be sure to say "hi"!

End-To-End Debugging with Six Sigma DMAIC

I've mentioned my use of Six Sigma techniques for debugging a couple of times before (5 Whys and Ishikawa diagrams) but a mention of  the Six Sigma approach to end-to-end problem resolution (and process improvement) is long-overdue.

Known as DMAIC (pronounced Duh-May-Ick), it's an abbreviation for Define, Measure, Analyse, Improve, and Control. Used in combination, the five steps in the DMAIC process can be used to identify and resolve your most complex issues. As part of the Six Sigma approach, DMAIC can be used to improve existing programs and applications (pro-actively fixing them before they break!).

The five steps lead a team logically through the process by defining the problem clearly, implementing solutions linked to root causes, and taking steps to ensure the solutions remain in place. You can try skipping some of the steps, but in my experience they each contribute a valuable part of the lasting solution. The basics of each step are:

DEFINE - First of all, make sure you have a clear and precise definition of the issue. This might include a list of symptoms, plus some information about the negative impact on users and/or the system. Make sure you understand priorities and objectives. All-in-all, this is an exercise in pulling together what the team already knows, and making sure that each member of the team is heading off to solve the same issue

MEASURE - Use the measurement phase to gather additional information about the issue and the impact of the issue. The aim is to gather as much information as is practical, for the purpose of exposing the root cause or causes of the issue. It may be appropriate to capture temporary/intermediate files or network traffic, or to look for patterns in the surrounding activity in the system. Remember that this is a data capture phase, you're not trying to solve the issue at this point

ANALYSE - In the analysis phase, we want to pinpoint and verify root causes in line with our priorities and objectives. Always be prepared to distrust the evidence or the means by which it was collected. Be careful to avoid "analysis paralysis", i.e. wasting time by reviewing data that isn't moving the investigation forward. Remember that the aim is to identify the root cause (or causes), not to define one or more solutions

IMPROVE - This phase identifies solutions, prioritises and selects them. It may be appropriate to implement a pilot of one or two solutions prior to finalising your decision and implementing the definitive solution. Your choice of solution may be influenced by impact analysis that shows the full knock-on effect of implementing each potential solution. Be sure to gain proper confirmation of success from appropriate stakeholders before implementing the definitive solution

CONTROL - Often overlooked, the control phase is post implementation of the fix or improvement. Use the control phase to make sure that lessons were learned and that the problem doesn't re-occur (nor problems of a similar nature). Add additional test steps to your regression testing suite and put additional control & validation steps in your application. If it's not practical to stop all potential re-occurrences  give thought to how the issue could have picked-up sooner and dealt with more quickly

The five steps seem like common sense, but in the heat of a high priority, complex issue it is easy to forget the some of these basics. I find it helps me a great deal to have the five steps at the back of my mind as my team and I investigate issues. I mentally tick-off each phase and makes sure that we've got all the information we need to proceed to the next step.

I hope you don't get any complex issues, but if you do (we all do, right?) then you will find DMAIC to be a useful guide.

NOTE: More on Ishikawa

I recently mentioned the use of Ishikawa diagrams for assistance with problem solving. I have frequently found them to be of value. However, what I had never realised, until my friend Chris Brooks pointed it out, is that there's a PROC ISHIKAWA in SAS! It's part of SAS/QC (for Quality Control of processes), so that's my excuse; I've never used any PROCs from QC.

I recommend the creation of Ishikawa diagrams on paper (as part of a team process, using a white board or something similar). However, it can be useful to create an electronic copy after the event, and PROC ISHIKAWA may be the ideal tool for that purpose if you're licensed for SAS/QC.

PROC ISHIKAWA provides an interactive environment in which you can:

• add and delete arrows with a mouse. You can also swap, copy, and so forth
• highlight special problems or critical paths with line styles and colour 
• display additional data for each of the arrows in a popup notepad 
• display portions of the diagram in separate windows for increasing or isolating detail. You can also divide sections of the diagram into separate Ishikawa diagrams
• merge multiple Ishikawa diagrams into a single, master diagram 
• display any number of arrows and up to ten levels of detail 
• foliate and defoliate diagrams dynamically 
• save diagrams for future editing 
• save diagrams in graphics catalogs or export them to host clipboards or graphics files 
• customise graphical features such as fonts, arrow types, and box styles

Who knew?!

Thanks for the tip, Chris. Recognition at last ;)

Debugging With Six Sigma Ishikawa

Back in September 2009 (that seems so long ago!) I wrote an article on problem solving using the 5 Whys technique. Some correspondents suggested that 5 Whys was a trivial/obvious technique, but they were missing the point somewhat - sometimes we overlook the obvious and need reminding of it, and sometimes the simplest techniques can provide the most valuable results.

That said, no one technique is guaranteed to work in all circumstances, so I thought I'd offer another technique that I use quite frequently: Ishikawa Diagrams, another part of the Six Sigma tool kit. They're sometimes known as cause-and-effect diagrams or herringbone diagrams. Again, they appear simplistic; and once again, I say beware of dismissing the simple and obvious! As with 5 Whys, the interaction between the people using the technique is perhaps the heart of the process, but the process guides and facilitates the discussion and discovery of information. Like 5 Whys, Ishikawa diagrams will help you to get to the root cause of your issue.

To use an Ishikawa diagram:

A) Determine a clear, brief description of the issue. Write it at the head of the fish bone skeleton, on the end of the spine

B) Decide the major categories for causes and create the ribs of the skeleton, writing one category at the end of each rib bone. These vary depending upon the industry and the situation in which the Ishikawa diagram will be used. I generally use a variation of the 6 Ms (used in manufacturing industries):

M	Description	Recommendation for SAS
Machine	Equipment / Technology	Hardware or software
Method	Process	Process
Material	Includes Raw Material, Consumables and Information	Data
Man Power	Physical work / Mind Power (brain work)	People
Measurement	Inspection	Inspection
Mother Nature	Environment	Environment (physical or logical)

C) Now challenge the assembled group to contribute possible causes under each of the major categories. There are many ways to do this, such as by brainstorming or by asking each person to contribute one suggestion for each major category. Place each suggestion alongside the associated rib. As with mind-mapping, you might want to divide and sub-divide your suggestions. Remember, at this stage we're looking for potential causes, not solutions

D) Now review the diagram. Remove any suggestions which clearly don't apply to the specific issue at-hand, and try to garner further suggestions for categories where there are fewer suggestions. To drive down to the root cause, it may be appropriate to adopt a 5 Why approach for each suggestion

E) Discuss the diagram and agree the causes that you all think are the most likely to be at the root of the issue. It's okay to rely on experience and instincts at this point

F) Finally, develop plans to confirm that the potential causes are the actual cause. It is important to concentrate on proving the root cause before taking action to resolve the issue

Ishikawa diagrams are a great way to engage all participants and get a balanced list of ideas. They provide structure for any review session, and they encourage participants to push beyond symptoms to uncover potential root causes. However, you'll get the best results if you have a precise problem definition at the start of the review session.

If you look carefully, you can find tools for drawing nice, neat Ishikawa diagrams but, in my opinion, you can't beat getting a group of people armed with marker pens and sat around a whiteboard or drawing board. The human interaction is an important part of the process.

First documented by Kaoru Ishikawa in the late 1960s, Ishikawa diagrams are a firm part of many sets of practices including Six Sigma and ITIL. Highly recommended.

Windows 7 Problem Steps Recorder

I was recently introduced to the Windows 7 Problem Steps Recorder (PSR). Wow, it's a well-hidden nugget of gold in Windows! Have you ever had the task of recording the steps you took in Windows? Perhaps to describe a problem, or maybe to create some user guide documentation, or perhaps to record your activities for audit purposes. Regulated industries such as pharmaceuticals demand that evidence of test execution be collected.

The PSR is a great tool for quickly documenting a series of steps that you take on your PC. Screenshots are automatically captured by the recorder (showing keystrokes and screen clicks) and comments can optionally be added to provide a more detailed description of what is happening. Once the recording is finished, the screenshots and comments are saved to a zip file.

To start the Problem Step Recorder, click the Start menu, then type Problem in the search field; you will see Problem Step Recorder in the results list. Click the Start Record button. It's pretty simple to use, but if you need an overview you can refer to the PSR video on Microsoft Technet; for further help, check the How Do I Use PSR article on the Microsoft web site.

NOTE: What program is running? aka Who am I? (SAUSAG Tips)

Having mentioned SAUSAG recently, it's worth highlighting the tips at http://sausag.sasusers.net/tips.htm.

Three of my favourites are:

1. What Program is Running?! - It can be useful for your SAS program to know its own name and location
2. PUT it _ALL_ out to the Log - in style - Here's an easy way to make that PUT _ALL_ a lot more readable
3. No more macro variable litter - Using macro variables extensively can get messy, and start to chew up memory. Since V8.2 CALL SYMDEL has enabled macro variables to be deleted

NOTE: The DATA Step Debugger

While the IT world moves from hand-typed code to visually-created, drag-and-drop code, beneath the covers there usually lurks machine-generated code that we can all recognise. And, while we await the nirvana of a visual-coding tool that offers all the power and flexibility of hand-cranked code (don't hold your breath!) we still need to create what SAS DI Studio calls User-Written Code Nodes. In other words, as I said in my recent DI Studio in V9.2 post, DI Studio is a great tool and it becomes greater with every new release, but we're still some years away from that day when we don't need to write any code ourselves.

In the meantime, we need to continue writing code, testing code, and debugging code. A key tool for use when debugging DATA steps is the DATA step debugger (DSD). I mentioned it in my 2001 paper "Debugging Made Easy Easier". I recommended that SAS programmers be on intimate terms with the DSD! At the time, my suggestion was to read Dave Riba's paper from SUGI25 - “How to Use the Data Step Debugger”.

This week I noticed a more recent paper by Russ Lavery - "An Animated Guide: The SAS® Data Step Debugger" presented at SGF 2007. Russ offers a very accessible, easily understandable and well-illustrated guide to using the DSD. Highly recommended.

DSD helps you understand the detail of what SAS does (and when) within the DATA step - you feel like you can see inside the SAS's head. It's a real education!
 
DSD is almost exclusively an interactive tool, but it can be used in batch. Dave Riba tells you how in his aforementioned paper. However, I've never found a satisfactory use for it in practice.
 
I'm conscious that this post hasn't offered any new information, it's merely pointed you to a number of existing materials that were produced in past years. I'm happy to do that; I'm happy to avoid repeating good information that's held elsewhere (and avoid plagiarism and claiming the information as my own!!); I'm happy to provide a channel that makes SAS practitioners aware of this excellent material. I hope you agree that this, and other similar styled posts, have value. Share your thoughts with a comment...

[Yes, I know DI Studio is actually called DI Server these days, but spare me a thought - I've only just got used to calling it DI Studio rather than Warehouse Administrator]