After six years of post-secondary education, my first day of the real world had finally come.   As I approached the doors to Klocwork, I realized it was time to put all my years of education to the test.

Straight out of high school, I had little idea of what career path I should take. Four years of university passed and I graduated with a B.A. in English, but still, I didn’t feel prepared. Another two years of college in media-related studies and, ready or not, it was time to make the leap into the working world.

My first day could be described in exactly two words: a blur. Between getting set up at my desk and meetings with my superiors, it was easy to feel overwhelmed. Nevertheless, after I got past the initial nerves of starting a new job, I felt ready for whatever was to come my way.

As it was put in my very first meeting at the company, I would be given “a taste of everything”. A taste was exactly what I had needed to get myself started and get some experience under my belt.

Fast forward almost two months and the experience has been nothing short of a rollercoaster.

One of my most rewarding and yet most challenging experiences since I started here has been a project which consisted of redesigning part of the documentation wiki. One of my colleagues, Patti, has been in process of designing a new landing page, and I had been asked to carry her design over to the wiki. While the task might seem simple, it has been challenging.

When I first glanced at the page, it didn’t think there would be many issues. I’m not afraid to admit that I may have made a poor assumption.

One revision after another, I faced one obstacle after another. Problems ranged from something as simple as getting the correct spacing to more complex issues dealing with specific browsers. The end of the week was near and I felt as if I was getting nowhere.

I let myself walk away from it for the weekend and came in the following week with a refreshed mindset. While it was quickly becoming evident this particular design would not work, there was still light at the end of the tunnel. With some guidance from the documentation team, we quickly got back on track.

Now with the page’s design nearing completion with approval from the key players, it’s something I certainly feel proud of. It’s a prime example of how much I’ve learned in the short time I have been with Klocwork.

While I know work may not always be fun (a few repetitive tasks come to mind), at the end of the day, I think it is projects like this that make it all worthwhile.

In my next post, I’ll share some more of my experiences working with the support, documentation and training teams.

If you’ve ever gone through the process of porting an application, you know the pain.  Porting can be difficult if you’re not vigilant from the outset.  There are tons of written guidelines and best practices for specific platforms or architectures, such as those going to 64 bit for Windows apps or Intel architecture and Mac OS.

In the past, we have talked about Endian issues, which are very specific to porting from different architectures (big-endian vs little-endian).  This time I want to take you through some general porting issues to show you how you can now use static analysis tools to help you through this process.

A very common gotcha are situations in which an expression is cast to a type of potentially different size.  Code written for a particular architecture’s data model can face significant challenges in porting when the new architecture imposes a new data model. For example, when porting between 32 bit and 64 bit data models, the new data model typically leaves ‘int’ at 32 bits, but uses ‘long’ as a 64 bit value, breaking any assumed equality in data type size that worked under the 32 bit data model.  Using static analysis tools can help you find this automatically.  In the example below all casts will throw an error:

void bad(){
 unsigned char uc = 0;
 unsigned short us = 0;
 unsigned int ui = 0;
 unsigned long long ull = 0;
 long l=0;

 l = (long)ull; //porting issue
 uc = (unsigned char)l; //porting issue
 us = (unsigned short)l; //porting issue
 ui = (unsigned int)l; //porting issue
}

Another gotcha is using bit fields within a structure.  When you define a data structure using bit fields, you are relying on the endian representation of a particular compiler. Moving to a different compiler can modify this layout, resulting in problems when that data structure is projected onto a byte buffer.  Again static analysis tools can be used to identify where the bit field definition exists and NOT properly covered by a big-endian or little-endian macro.  For example flag this:

struct mystruct{
   unsigned short x : 4;
   unsigned short y : 5;
   unsigned short z : 7;
} test;

But don’t flag the same thing with conditional compilation:

#ifdef BIG_ENDIAN
struct mystruct{
   unsigned short x : 4;
   unsigned short y : 5;
   unsigned short z : 7;
} test;
...

There are tons of other gotchas as well, such as using a custom byte swap macro without checking endianness, an incompatible type is used with a network macro such as ‘ntohl’, compiler-dependent option is used, macro describing a builtin numeric type is used, and many more.

Using static analysis tools not only detects porting issues, but provides metrics and reporting capabilities that allow you to prioritize and identify the scope of work involved.  For example, Top 10 porting issues (see the diagram above) helps you identify the bulk of the issues that need to be addressed.  Or you can use the component diagram report to identify specific components of your software code base you may have to concentrate on going forward.

Nice blog post from Walter Bright over at Dr. Dobbs on the Patterns of Bugs. He ties together bug patterns, recommended process changes, and the resulting productivity payoff from making these improvements. He recommends a bunch of process changes, including static analysis, code reviews, and coding standards, then goes on to review examples of different bug patterns. A few can be detected with static analysis (coding mistakes as written) but many are errors with the code as intended (something static analysis doesn’t check… that’s what testing is for). His main recommendation seems to be that bugs can often be pattern based, so once a bug is identified, take steps to remove that pattern from your code through process or tool changes.

Once the pattern is identified, then look for changes in process that will permanently eliminate that bug. Eliminate enough of the bug patterns, and you should enjoy a substantial increase in productivity.

His experience is that, over time this kind of systematic approach to fixing bugs makes developers better.

I’ve noticed in my decades of writing programs that I just don’t make the kinds of mistakes I used to. Apparently I’ve unconsciously evolved coping strategies to avoid them. Identifying and building such strategies into the process means everyone can benefit from that experience.

We certainly see that in the area of static analysis bug detection; lots of customers report that their developers make fewer mistakes, defect injection rates go down, and overall productivity is improved.

Yesterday we did our second Medical Devices software seminar, this time in snowy and cold Minneapolis. Say what you will about the weather, but this city is built for winter…it has various overhead ‘tunnels’ called ‘skyways‘ connecting what seemed to be the entire downtown core, so you rarely ever need to go outside.

Anyways, our seminar drew the interest of over 75% of registrants, mostly software engineers and QA, so really another great turnout. The format was the same as our Boston event, with the same players from SterlingTech, Klocwork (duh) and Vector Software. There really didn’t seem to be too much separating this group from the Boston group with the exception being around the development methodologies being used. The Boston group all appeared to be using (or moving to) and Agile methodology, whereas this group was not using Agile at all. For the life of me I cannot explain this. I would have thought if Medical device organizations in one part of the country were primarily using Agile, perhaps it was becoming the norm for that market segment…but based on this sample, now I just don’t know. If anyone can share their observations on this, I would love to hear from you.

What comes first—the process or the tool?

Yes.

Any tool worth its salt should integrate into existing processes and tools.

What’s interesting and informative is seeing the similarities and differences in how the same tool is applied in different organizations, across continents and oceans.

The emphasis on quality unites everyone, but the level to which agile is adopted is what makes static analysis markets different.

No one knows this more than Mark Grice, Klocwork Director and Manager of the International Reseller/Partner Network, and Steve Howard, head of Partner Support in Europe.

Trying to talk to these guys at the same time is a challenge. Mark’s work takes him all over Asia, but I managed to pinpoint him in Japan; Steve spends most of his time traveling across Europe, but was at his home base in England—for a time, anyway.

Same difference

The European and Asian markets are all singing from the same song book when it comes to coding standards.

“MISRA is very appealing here in Europe, particularly on the developer desktop,” Steve says.

“There’s a strong focus on quality here,” Mark says about his Asian market. While MISRA is “somewhat appealing,” Mark says he gets asked about Embedded System development exemplar Reference Series (ESxR) quite a lot. It’s a coding standard similar to MISRA in that it’s aimed at embedded system development, but its adoption is more Japan-centric. For more information, see ESxR at Information-technology Promotion Agency, Japan (IPA).

Steve explains  that the ability to extend checkers to suit the needs of specific organizations is of keen interest to customers in his bailiwick.
“Sometimes organizations want to enforce their own naming conventions or code constructions, and the extensibility tools provide a very quick and effective way to accomplish that,” he says.

Difference

The developer desktop illustrates the great agile divide.

“I’d say Europe is a little bit behind North America in its adoption of agile, but there’s still the same requirement for developer productivity and speed,” Steve says.

For that reason, he sees more opportunity to penetrate the European market with a static code analysis tool for the developer desktop. The growing interest in agile in Europe gives him an increasingly receptive audience.

Japan is a bit different on this score from the rest of Asia.

Quality is seen as the purview of testing teams, and not development. That means that there’s a huge focus on quality at the end of the development life cycle, rather than the beginning, Mark explains.

Desktop source code analysis tools are a harder sell in Japan, but that may change as agile processes trickle in.

And there you have it, a quick peek at a couple of our markets.

Well no, far from it, but there has been an interesting post on this and other discussions from the browser makers themselves.  Namely Firefox has removed the RSS feed from the toolbar in 4.0.  This has sparked much conversation to bring that back.

The main reason for this is that it simply is not used, therefore having it so prominent is unnecessary.  Furthermore all sites already provide this capability on their pages, so why include one on the browser too?  There are some interesting counters to this and I suggest you have a read.

This got me thinking as well, since the code review product in Klocwork Insight Pro already has that RSS feed icon.  So all is good right?  Well the post also brings up the fact that most don’t know what this symbol means.  Do you know?  If you do know, do you use it?