I love this quote by Carl Ek from  Code Integrity solutions:

There are 0010 0000 kinds of people in the world: Those that understand the difference between Big Endian and Little Endian, and those that do not.

Issues with Endianism and processor architecture ports are becoming more and more common these days as more desktop source code moves into different arenas.  Gone are the days when the 32-bit memory model or little-endian format dominate. Software changes are required to support the growth occurring not at the desktop, but in the server  and mobile platforms.

Mobile devices especially have opened a Pandora’s box of Endian and memory problems, with variety of processor architectures with ARM^[1] leading the way.  Add to this mix,  end-consumers are demanding desktop features like Adobe Flash or Office apps on mobile devices, many a stable codebase will fall apart when ported to either mobile or server.

For developers porting to different platforms, there are some significant challenges.  Just to list a few:

• CPU optimizations need to be reviewed
• inline assembly calls require rewriting or removal
• machine word (WORD) allocations may require refactoring
• any binary data exchanged over the network stacks require verification

None of these are  new, they’re just not a common skillset for most developers.

Source code analysis can be a boon in two ways. Firstly, in the planning phase by helping you determine the breadth of the effort,  and secondly by identifying any existing  issues, particularly of the memory allocation and Endian varieties.

For more in depth information, there are two recent articles available from Dr. Dobbs:

• Porting to 64-bit Platforms by Irving Rabin
• Detecting Endian Issues with Static Analysis Tools by Carl Ek

^[1] Note: Some ARM processors support both big and little Endian formats.

Mark Grice in a more peaceful moment.

The last time I spoke to the Klocwork Director and Manager of the International Reseller/Partner Network, he outlined 7 habits of highly ineffective Source Code Analysis (SCA) tool selection.

Among those terrible habits, he described an SCA tool-selection process that involved endless feature comparisons and massive checklists of irrelevant requirements.

His head almost exploded, but on this day our SCA guru was calmer.  Clearly, he’s been using relaxation techniques or drinking some of the good stuff, like acai juice.

According to Grice, successful SCA tool adoption involves three key steps:

1. Involve your developers in the process.
   “Developers understand what their requirements are,” Grice says. “And that means your selection criteria will be more realistic and achievable, and it will focus on what’s relevant to the organization’s software and environment. Developers are also best equipped to assess the SCA results.”
2. Limit your selection to market-leading tools with the functionality relevant to your software needs.
   “For example, if MISRA compliance is something you care about, then make that part of your selection criteria,” he says.
3. Have a game plan with a path and a defined end. Work toward a goal that’s realistic—spend enough time, but not forever, finding the tool (or tools) you need.
   “Have a good idea of what will constitute success, and be prepared to make a decision and move on,” Grice says. “Avoid paralysis analysis—unless your goal is to just waste time and money and contribute nothing to improving your software.”

That’s it for today. Grice is off to yoga class (um, or a pub). Stayed tuned for the next post in this series–How smart companies adopt SCA tools.

As the topic suggests, this kind of argument has been around for some time.  Most developers can recognize the need for tools but once you start breaking the developer’s day-to -day workflow you might as well flush that tool down the drain.

What developers need is a tool that seamlessly integrates with their development environment and their workflow, so they can meet their quality goals without taking a big productivity hit.

It’s one thing to provide plug-in tools for the more popular IDEs like Visual Studio and Eclipse, but it’s an added bonus when defect detection is a seamless part of the edit cycle. No buttons to click, just continuous analysis and issue highlighting while you work.

Let’s take the analogy to the spell checker.  Initially, you had to click a button to spell check your document. That has obviously changed dramatically. Now we see any mistakes we make as we type them (and can even fix them automatically).

That’s what we were thinking when we introduced continuous analysis in our plug-in tools and our source viewer for command-line tools, Klocwork Desktop.

Here’s the spell checker equivalent for source code analysis:

The above screenshot is from our Visual Studio plug-in.

When you open or save a file, the analysis runs in the background. A bug marker in the left gutter and a squiggly line, in the true spirit of the spell checker, clearly marks the detected issue.

Find ‘em and fix’em while you work.

Mark Grice is a pretty unflappable guy, but when you ask him a question about barriers to successful adoption of Source Code Analysis (SCA) technology, he starts to splutter.

A while back, I talked about how I keep running into organizations that seem to go out of their way to make developers’ lives hell.  I’ve run into several examples where developers had to switch between different environments just to write and compile code.  That’s as productive as watching paint dry and as much fun as rearranging the deck chairs on the Titanic.

For teams that want to run source code analysis in these types of environments (or any kind of dev tooling, frankly)  it’s very difficult for vendors to support.  I did my usual PM grumbling about these environments but since that post exactly 1 year ago I’ve come to realize that these environments are a reality and we need to figure out a way to support them.  Maybe it’s not productive but organizations are making it work.  I’m sure they would even argue that they have made it productive (good luck to them).  It’s for this reason that Klocwork has given in and instead of pointing our finger and making fun (I swear I never did), we’ve decided that it’s in our best interest to make sure we provide these customers with the capability to run static analysis.

A couple of releases ago, Klocwork introduced a new tool called Klocwork Desktop that provides Klocwork command line users with the same graphical capabilities that one would get from Visual Studio or Eclipse.  This tool was great for users who never used an IDE.  With Klocwork’s 9.1 release we have extended Klocwork Desktop’s reach by providing a remote capability that’s designed to support the type of environments described above.  Using Klocwork Desktop in remote mode allows users to view their source and detected-issue information when Klocwork Desktop does not have direct access to source files or defects, yet still get the benefits of finding and fixing your defects before you check-in your code.

One really cool feature that is part of this is the “you’ve got mail” notification.  At first, I have to admit this is something that worried me.  If I had to label one thing as a productivity drain it was those annoying alerts you get of new email coming in.  Of course right in the middle of doing something important you get distracted by a new email with plans for the next party (or in my case hearing about the kids latest poop explosion).  The first thing I always do is turn it off.  But in the case of finding bugs while coding, it only makes sense to give you these notifications in a heartbeat.  So you can actually be writing code on some machine in Jakarta and automatically your machine in San Jose is alerting you of bugs.  Pretty neat stuff.

In a previous post I discussed the process where we practice dogfooding.  This is the process of using Klocwork on Klocwork (KonK).  We started this program several years back with the hopes that we would learn some valuable lessons about usability, performance and anything else that would give us an edge.  The truth is that KonK has consistently allowed us to test our design assumptions early by allowing our own developers to use Klocwork as part of their development.

One of the unexpected results was inadvertently uncovering data that further validated for us the importance of bugs found by a static analysis tool. We correlated testing-found issues and KonK (static analysis) issues assigned to each developer. The result as this graph shows (note: graph is using a logarithmic scale and is a few years old), is there was a very high relationship between the two. Those familiar with bugs found by static analysis tools know that they are often quite different in nature from a bug found by testing where you’re testing requirements, yet developers with a high count of testing-found issues also had a high KonK count. In some cases they pointed to the same problem, in others an indication of the overall bad to the bone problems in some of the new components.

Since we already eat our own dogfood, we’re already believers in the use of static analysis, but this kind of data is a great example of the benefit of finding issues early using static analysis

Dogfooding?  Is this the process of making sure Rover is well fed?  Maybe it’s a movement of people eating dog food?  Or maybe Rover IS the dinner (cue animal activists).  No, dogfooding is coined from the saying “Eating one’s own dog food”.

So what on earth am I talking about.  Well first I’m breaking a golden rule here when it comes to blogging which is talking about your company (I don’t know how I’ll sleep tonight).  Klocwork does eat its own dog food.  We call this KonK – Klocwork on Klocwork.

So why is this important?  Ultimately we make a software product that we sell to other companies that make software.  So who better to experience first hand what we are designing.  By using KonK and updating it frequently it gives us immediate feedback on usability and scalability (our code base is quite large).  Plus being in the business of bug detection it helps us sort out the value of the quality of those bugs.  As the product manager I’m not using it day to day like the developers, so they are the ones that bring any kind of deficiencies to the design front and center.  Hopefully I can talk a little about the benefits and conclusions we have made by using KonK in a later post.

One thing that has helped me with dogfooding is requirements capture.  Being in product management obviously the clear objective is to work closely with customers to define requirements and your product direction.  Those requirements don’t necessarily paint the picture as much as you would expect or hope.  Now that I can play with the intended design on our own code base it paints a clear picture of what may be missing or what may just be plain ugly.

Our partners at Code Integrity have a good blog that touches on many of the benefits and barriers to static analysis within a development organization. They have an interesting post on “False false positives” – a great phrase that captures one of the key challenges in developer adoption of the technology.

While increased sophistication means that static analysis tools can catch more problems with a higher degree of accuracy, the burden increases on the reviewer of the results to interpret them correctly. If you were grep’ing through some code for something you can quickly review (and dismiss) many of the results because you understand what your “analysis” is doing. With static source code analysis, this is much less apparent.

We see many engineers look at a complex bug report and not take the necessary time to understand the problem and fix it. This is mostly because they don’t understand what the static analysis tool is doing and how deep it is analyzing the code. The result is a real bug being marked as a false positive – or a “false false positive” if you will. These bugs then disappear off the queue never to be seen again – a lost opportunity.

One of their key recommendations to overcoming this barrier is using training and joint review of results to educate developers on why the tool is flagging a potential error, what the mitigation options are, etc. Code Integrity has a bunch of deployment and training services to help customers with these types of deployment hurdles.

In our experience, all developers need is one ‘aha’ moment where the tool finds a nasty, subtle bug that would be hard to find using any other method. Once that happens, the developer is a convert. I would also say the burden isn’t just on training, but the tool vendors as well. We all have to continue making the usability of the tool such that developers should be able to instantly recognize why the tool is flagging the error and give the developer all the info they need to recognize the bug and take the appropriate action.

In my previous blog post, we talked about the value of compiler warnings and reasons to have source code analysis. Now, I’d like to get into the value of coding standards and touch on how you can fit this altogether.

Coding standards are a set of rules or guidelines usually created as part of an industry. The goal is simple, provide guidelines, so you can create better code and increase your code quality. Probably the most common coding standard I run into is called MISRA C. This is a standard created for C code in 1998 and revised in 2004. A new standard from MISRA was released in 2008 for C++ code. MISRA was developed for the Motor Industry but has since been adopted by many other industries. Other coding standards such as Joint Strike Fighter are focused on other industries, such as the aerospace world.  And there are more generic types of guidelines, such as the Power of 10, which contains more high level practices.

Either way, these standards cover everything from simply “thou shall comment code” to more specific coding no-no’s. So, how do you apply these to your process?

The advantage of these coding standards is that compliance is something you can quickly scan for using source code analysis. Any source code analysis tool worth its salt incorporates these standards into their issue checkers.

Implementing a solution for developers is key to this process. After developers check to ensure there are no compiler errors (or warnings!) they can run another process (or integrate into your existing process) using source code analysis techniques to find infractions with various coding standards in the code.

Remember that compiler warnings can be very helpful, so use them. Don’t be surprised when your source code analysis vendor asks if you are using your compiler warnings on your next checker feature request. Once you have cleaned up your compiler warnings and you want to take the next step to improve code quality, there are many good coding standards that will bring up the quality of your code. Use source code analysis tools to help you automate this process and you will guarantee a better report card.

Just wrapped up a successful 2 day Embedded System Engineering conference in Stuttgart, Germany. This “all-German” show had just shy of 600 attendees, as well as about 60 individuals (representing the 20 or so companies exhibiting), so this was considered very good by the show organizers (who by the way did a fantastic job… the food here, for example, was as good as I’ve ever seen for such an event). The Klocwork booth was shared with our good friends at Emenda, and we had a choice spot that allowed a good flow of people. We had an interesting mix at our booth as well… a Scotsman who now lives in Germany and speaks flawless German (albeit with a hint of a wee Scottish accent), an Englishman who had numerous stories that kept us entertained during the quiet times, and myself, the jetlagged Canadian.

As I mentioned earlier, this show is advertised as the only German-language conference around… and it was. So other than saying “hello”, “goodbye”, “thank you”, or “another beer please“, my German is, uhm, lacking. However, not a problem here; the Germans all speak very good English… which was a good thing since my presentation was in English. I had over 40 attendees at my session about how Source Code Analysis fits into Agile development environments, and it went very well. A number of attendees came to our booth after the talk to pick up our White Paper onstatic analysis and agile, and to get a demo of our latest release.

My two-week stint of planes, trains and automobiles continues tomorrow when I head up to Berlin for the weekend to see some good friends (and a football game in the Olympic Stadium), then it is back home on Monday. It has been a great couple of weeks in Europe, but I am looking forward to being back on good ole EST.