Category Archives: Process

Triage for Static Analysis issues

“This new tool looks great, but who is going to triage the results and open the bugs?”

Many engagements with a static analysis tool often start this way.  Sorting through the results to determine which are real, and which are false positives, is a task that someone has to do. That task takes time away from the other activities that person would have been doing anyway and often this perceived workload will kill the idea before it starts. There is another way.

Here is a quick tip to move past the question on who will triage the issues: Automate the triage process. Automatically assign the issues to the most likely person to fix it – the author of the code.

The static analysis tool will provide the defect type and some meta-data about the defect like a severity level. It will also provide the source path, filename, and line of code where the problem was found.

A good heuristic to use in automatically assigning the bugs is the last person to check in a change to that file.  In all likelihood, that person created the error.  In the teams where I’ve implemented this method, we generally see a 80-90% accuracy for the triage. That is 80-90% of the time, the static analysis tool flagged an issue caused with that check-in.

For the balance, we ask for the developers to investigate the issue anyway. I like to use the analogy of picking up trash while on a walk.  You didn’t leave that trash, someone else did. However, by picking it up, you leave the trail a little bit nicer for the next person.  Think about fixing legacy bugs like this. If you are working in that file, and you find a bug, go ahead and fix it.

Implementing this process does require a small bit of scripting. First, the script retrieves the list of new issues from your scan (daily, weekly, whatever frequency you run the scans). Then, for each new issue, lookup in the source control system the author that made the last check-in.  Next, create a record in the bug tracking system (or update the field in the defect record of your tool – if it has a tracker). Finally, send a notification to the author that they have a new assignment.

This assignment process has been successful for several teams, it might help you.  Give it a try.  Of course, track the success rate and make any needed adjustments.

Good luck.

Fail Safe Processes

My first job was working in the aerospace industry, working for McDonnell Douglas (which is now part of Boeing). One tenet drilled into me during my tenure building military aircraft was the concept of “fail safe“.  One example of a fail safe design is the control switch for the C-17 hydraulic pumps. The primary pump is directly connected to the engine, and is on by default. If the pilot wants to turn the pump off, he or she presses the button which applies power to the solenoid to disable the pump.  Since hydraulic pressure is required to fly the plane, turning the pump off is an unusual condition, so active power is necessary to disable it. If any of the components in the chain fail, the pump stays on, which is the safest condition for the aircraft.

One question that this experience leads me to ask, during a design review is “how is this design fail safe”.  But, this video reminded me of systems that are inherently in-stable and got me to thinking about fail safe processes.  Which processes at work would go out of control without personal intervention?

Continue reading