The Code Integrity folks have developed a lot of best practices on deploying static analysis and have compiled many of them in a solid whitepaper. They include a Top 10 list of what they call “The Well Traveled Path to Success”. Below is their (somewhat paraphrased in spots) list.

1. Determine who cares. Who has a vested interest that bugs actually get fixed. How much do they care?

2. Get an expert to tune the solution for your codebase. Static analysis tuning will maximize defect finding while minimizing false positives.
3. If possible, pilot with a small group to gain early successes.
4. Appoint the proper roles, particularly management sponsor, administrator, defect triagers, fixers and verifiers.
5. Set up the proper process, incentives and consequences. Integrate the SCA tool into your environment. Automate and simplify as much as possible.
6. Get a team to handpick good, high-priority defects for the team rather than have them sift through potential false positives.
7. Set up a central resource website that includes simplified documentation, policies, procedures, roles, reports, etc.
8. Set up various reports like the daily dashboard, top ten list and the “wall of shame”. Make it public. Do a little bit of marketing.
9. Train and mentor the team providing guidance, support and discipline. Either in-person or static analysis e-learning courses work.
10. Determine success criteria and measure it. Provide status updates often, work on a source code analysis ROI model that works for your organization.

I agree with the general thrust of most of these, but some might be overkill depending on the size of your deployment. My other quibble is that many of the recommendations presume a centralized defect triage model where you’d have a central group of code reviewers sifting though bug reports.

That’s a common deployment model, but we’re seeing more people choose to just provide the tool to their developers via desktop static analysis. With the possible exception of your backlog, this will eliminate (or greatly reduce) the need for a central code review team that stares at bugs all day long. Regardless, they’re all good considerations to at least, well… consider.

With the launch of the Klocwork Developer Network, we’re making a deliberate and concerted effort to make many of these kinds of deployment resources freely available to our customers. I’ve included links where appropriate.

In my last post, I took us back in time to an era of bad fashion, questionable music, legendary television shows, and source code analysis tools that were made specifically for software developers. It was the 1970s. In this post, I fast forward to just after the turn of the century to discuss the next evolution of static analysis tools.

The Early 21^st Century

Not long after we first viewed hairy-footed Hobbits on the silver screen, and the sham that was affectionately known as Y2K, a new generation of source code analysis tools emerged to cure the errors of the first-generation tools.

These new tools looked beyond the syntactical analysis of previous tools, and instead provided inter-procedural and data-flow analysis. Low hanging fruit was definitely not the target for these tools.

These new techniques were serious–finding complex defects that could impact code quality and security, and they did that while ensuring that the “noise” (i.e. false positive rate) was greatly reduced compared to the first-generation tools. In addition to local defects, they were now identifying resource management issues, security vulnerabilities, concurrency issues, and so on. These were serious defects that,  if left undetected and unfixed, had the potential for massive problems to the code stream.

In order to perform this much deeper analysis, a fundamental change in the analysis techniques had to occur. These engines needed an unfiltered view of the entire code stream, and so they became tightly integrated with the integration build process.

Umm, Houston, we have a problem. If the analysis takes place at integration build time, then that means the analysis is no longer being initiated by the developers. Source code analysis tools became centralized and moved into a more downstream process such as part of a code audit function.

Developers were now being told they created bugs well after they actually checked in the code. They had already moved onto something entirely different, so now bringing them these day-old, or week-old defects was certainly not the most productive use of their time. It is well documented that the earlier you find defects in your code, the more cost effective it is to fix them, so you can clearly see the problems with these second-generation tools.

If only there was a way to bring these second-generation analysis capabilities to the developer desktop. More about that in my next entry.

I came to the practice of procrastination late in life. I was always one of those annoying people who arrived for appointments early, handed in assignments early, went to bed early.

Becoming a full-time working parent drove me to the dark side.

Now I’m routinely late — late for exercise classes, late going to bed, late getting the kids to daycare.

My forgetfulness factor has increased about 26-fold too. I’ve always been a list-maker, but now I have a few sayings that my husband is sick of: If it’s not in my calendar, it’s not getting done. If it’s not on the grocery list, it’s not going to show up in the fridge.

My work equivalent: If it’s not in XPlanner, it’s not getting done.

However, I’ve also discovered that adding tasks to XPlanner is a necessary but not sufficient condition for something getting done. Ever so occasionally, I’ll realize that a task in my slightly overlong list of tasks for the iteration should have been done… yesterday.

In my pre-kid years (which incidentally and unfortunately coincided with the days of larger doc teams), that just didn’t happen. I had sufficient brain space to accommodate what needed to be done.

My colleague Patti and I decided to elevate this practice of procrastination in agile documentation by giving it a name:

DOCRAGINATION.

Fortunately, in my latest slip into docragination, I got away with it: I wasn’t the only reason for another software build.

As I get older, I’m growing more certain that procrastination in general is not always a bad thing. There’s something to be said for waiting, listening, processing — even sleeping on it — instead of rushing in and finishing.

Patti just reminded me of another of my annoying sayings: What doesn’t get documented today won’t have to be revised later.

Our marketing people here at Klocwork like to see me racking up frequent flyer miles and expending CO2 at roadshows, conferences and tradeshows. Whenever I’m out speaking, I always like to gauge audience familiarity with Static Code Analysis.

I’m happy to say that SCA knowledge has definitely increased over the years, but it is still not up to levels enjoyed by unit testing or integration testing.

What I plan to do over the next three weeks is to provide you with a history lesson on how Static Code Analysis has evolved over the past few decades (yes, it has been around that long!). The three different eras I will be addressing are The Early Years, The Early 21^st Century, and  The Present Day.

The Early Years

As I mentioned earlier, Static Code Analysis has actually been around since the time of bell bottoms, disco music, and Space Invaders (check out the Space Invaders link)–yes, the good ole 1970s. Who out there has heard of Lint (and no, I’m not talking about the fluff coming from your old bell bottoms pockets)?

Lint was one of these first-generation SCA tools introduced in the late 70s. These tools targeted low hanging fruit in C code, such as missing or extra semi-colons, missing curlicues, potentially dangerous implicit casts, and so on.

These tools were closely integrated with the compile and link process, and so this seemed like the best time to show its errors and warnings, while the developer was actually “in process” and fixing problems found by the compiler. Since these tools delivered its warnings at compile time, it quickly became a tool that was adopted and owned by the developers themselves.

Life was good. Well, until the bugs that were being found were deemed to be relatively trivial or completely erroneous (the dreaded false positive). The problem was that these tools were only able to see one file at a time, but for accurate static analysis there is a strong need to know everything that’s going on within the entire stream.

Without that vision of the entire stream, no matter how sophisticated the analysis tools are, they will make incorrect assumptions most of the time. Because of these inaccuracies, these first-generation tools never gained the widespread acceptance of software developers.

Next up will be a look at static analysis tools during a time when “Whassssuuuupp” became a household term.

I’m sure this topic has been discussed a million times, but hey, here we go again.  A recent question came up on whether people liked their experience of Eclipse vs. Visual Studio.  Of course this brought up the advantages of one versus the other.  But is that really a fair comparison? It really depends.  What type of application are you building — a native Windows application?  Surely going with Visual Studio makes sense. But if the goal is cross-platform, then you might look at Eclipse.

Glad to see people are thinking about IDEs, but what really intrigues me about this conversation of one IDE versus another is that someone always has to add their two cents about the ancient text editors of the world.   Something like “real programmers use vi”.  Hold the phone.  Are we talking about the same text editor that requires you to memorize a gazillion key bindings?

I don’t get this.  I understand legacy use, as vi was the only available built-in text editor at the time and still is the only choice of hackers today.  But times have changed.  Anyone I’ve talked to who is using vi (or other known text editors like emacs) always seems very proud of it.  Maybe knowing how to use such a complex tool provides some self-worth.  I just don’t know.  Seems like it would be the same as me bragging about my portable Walkman or the 8-track player in my car.

Don’t the features of Visual Studio or Eclipse make you faster?  With a click of a button you can refactor your code.  With simple auto-completion the IDE eliminates simple typing (or even mistakes).  Plus with built-in tools for static analysis, test generation, etc., what are you waiting for?

So you vi/vim/emacs coders out there — tell me why on earth you are sticking with it. What makes you a better programmer using vi/vim or emacs?

A while ago I talked about memory overflows.  Now in this latest instalment, as we look at more interesting bugs, I’ve come across a new example.  Here is a situation described by a customer as “stack smashing”, which occurs when you copy a string of unknown length into a fixed buffer size.

#include <stdio.h>;

void foo(char * v) {
    char buffer[10];
    if(v != NULL)
   {
            memcpy(buffer, v,strlen(v));
    }
}

int main (int argc, char ** argv)
{
    foo(argv[1]);
    foo("the longest string you can find");
    return 0;
}

Just like the memory overflow post this is another form of a buffer overflow.  So there you have it, just more terminology to describe bad things in your code.  Gwyn promises to give a follow up to these posts with some details on how this general area (stack corruption, tainted sources, etc.) can be exploited.  Can’t wait to see that.