Yesterday we kicked off our first Medical Devices specific seminar in Boston, with our friends from SterlingTech and Vector Software. The day was all about software development for medical devices and more specifically, about managing software risk to help ensure you are compliant with all of the FDA regulations specific to software code. We had a great turnout, with over 75% of registrants showing up for this session. A couple of observations I found interesting from this event:

• The medical devices community seems to be fairly tight-knit. Everyone at the event seemed to know everyone else, and there was definitely a strong support system in place among the companies in attendance.
• And secondly, there appears to be fairly high adoption of Agile practices, particularly Scrum (albeit somewhat modified), with these Medical device companies, and the healthcare industry in general for that matter. From everything I heard, this adoption curve shows no signs of slowing down.

If IEC 62304 is important to your organization, you might want to check out this half-day seminar. The next one will be in Minneapolis in January. I’ll be packing my woolies for that one!

After being a PC user for most of my life, I just can’t help but feel a little bit exposed without any kind of antivirus on my shiny new Mac. I mean, I’ve heard it ad nauseum that the Mac just isn’t as prone to attacks as PCs are, but I for one just find that hard to believe.

It is a computer that connects to the Internet after all; there has to be some level of risk there. According to this site, there are regular updates to address new Trojan horses, and other security violations and threats, so obviously Apple is taking this seriously.

Many industry ‘experts’ are starting to think that maybe antivirus on a Mac is (and will continue to be) more important moving forward. Some believe that a Mac is just inherently less susceptible to viruses, while others speculate that there may be other reasons behind it. Either way, the PC side of my brain has convinced me to at least investigate this a little more.

So, do you have an antivirus protection on your Mac?

Klocwork developer Russ Sherk sporting his mo'stache. It's hair today, gone tomorrow.

Time’s a precious resource, so the saying goes. Don’t waste it. That’s particularly true for developers, who live in the critical path lane.

And if there’s someone who knows a lot about time management, it’s Russ Sherk, an intermediate developer here at Klocwork, and the father of three young ‘uns. Russ works on our Klocwork Review and Klocwork Inspect products and handles licensing.

For Russ, these are lessons learned over his six-year tenure at Klocwork.

“These are things you need to think about or you won’t progress as a developer,” he says.

Here’s what to do if you want to waste time:

1. Code without a plan

It’s easy to get carried away with ideas about cool features, Russ says. This is how you burn through the days–by doing a lot of things that don’t need to be done.

The fix: Classic agile philosophy. “You have a story. Then break it up into a list of features that must be done. You take those features and you break them down into tasks taking less than a day, Russ explains. A task taking two to four hours is optimal. The team here uses XPlanner for project/story/task management. You can always augment with pieces of paper.”

2. Switch tasks constantly

Mental switching eats up a lot of time because you need to evaluate where you were before you switched gears, and then go through it again when you switch back.

The fix: Get to a completion point before switching (if you can).

3. Take the idealistic approach to bad or “delicate” code

Inheriting problem code makes debugging and feature work more difficult and error prone, Russ says.

“It’s tempting to want to fix it all–but that will always set you back.”

The fix: Fix what you touch to the best of your ability. Schedule larger-scale refactoring and reorganization work separately.

4. Build infrequently

This strategy goes beyond the individual developer.  There was a time here when there were only weekly builds (Egad! Say it ain’t so!). Even 15 minutes per build slows you down, Russ says. The push by development managers for frequent builds has paid dividends.

“Now, I can go through a build process in 2-4 minutes,” Russ says. That translates into 10 to 15 builds a day.

The fix: Frequent build cycles allow you to make your changes, verify them, and handle bugs quickly.

5. Optimize early and over-engineer

This is the dark side of planning. Over-planning and perfectionism can be paralyzing.

The better approach is to keep it simple, he says.

The fix: Plan the bare minimum to get your feature working. After the feature is in place, it’s time to optimize and refactor.

And there you have it. Surprisingly, World of Warcraft didn’t even make the list.

I don’t know why, but every time I go back to some simple shell scripting I can never remember the one liner for loop.  For those who know what I’m talking about, it is the one command you need over and over again when it comes to performing the same thing on a set of files.  I can never seem to remember the simple syntax and it always leaves me scratching my head.

So I thought I would ask a forum on shell scripting and  was promptly answered with:

for file in `ls`; do rm -rf $file; done

I don’t think they were very friendly.  Although they have the syntax correct, please don’t try this at home.  If you don’t know why, please turn off your computer.  In the end, a simple Google search brought me to this blog with all the details.

So in the end a simple command to create copies for all my .java files to .java.bak:

for i in `find . -name "*.java"`; do cp $i $i.bak; done

Don’t forget, those are executable quotes that you’re using for the find command.  Maybe there’s a better way to do this, but in the end I find the one liner for loop very handy…if only I can remember it.

On another note, I tried this with my Windows Cygwin installation and it doesn’t work.  Anyone with insights into that?

While I may not be the most active Twitter-er in the world, the one thing I have noticed is that there is an awful lot of activity around the term “code review” lately. Since code reviews have become a widely used practice, I thought I would share one of my experiences about code reviews with you, from a product manager perspective.

In my first Agile team, many years ago, it was tabled (in our retrospective meeting after a couple of Sprints) that code reviews should be added to our definition of “Done”.  Let’s just say my initial response was less than enthusiastic… but why was that?  Well, in my opinion (perhaps uneducated on this topic), doing code reviews seems to add more to the time it takes to finish stories, so that means less stories are getting done per iteration, which potentially means longer release times, or releases with less functionality than hoped for. This is not something a Product Manager is usually receptive to. After some debate, we put it to a vote where the “yays” defeated the “nays” by a fairly healthy margin (okay, it missed being unanimous by one vote).  So we updated our “Done” criteria and moved into our next Sprint.

Our next couple of sprints went off similar to our earlier sprints, I didn’t really notice any differences. We seemed to have about the same number of stories being started and completed, and I for one was mildly surprised that we were able to maintain the same velocity, even with the extra process of doing code reviews for each story. Curious, I decided to talk to one of the more senior developers about what was going on. He walked me over to our Scrum board and asked me if anything looked different. Nothing jumped out at me initially, until he pointed out that the number of ‘bug’ cards (the dreaded red cards) were significantly less than in those early iterations. He proceeded to tell me that the code reviews were playing a major role in this. Developers were finding things early and fixing them before passing the code onto the testers, leaving the testers to focus on testing the actual features …crazy, I know.

It really appeared as though the code reviews were producing better code, without actually slowing down the development process. My opinions of code reviews did a complete 180…now they were helping to contribute to better quality code that I could show our customers, without having to sacrifice anything in the way of release delays or velocity degradation. I had become a believer!

 I think I have something to Twitter about now…

Ok… bad pun but question still stands. We wanted to try and answer that question so we worked with the team at VDC Research to try and quantify some of these questions. You can download their full report on the multicore and multiprocessor landscape, but here’s one piece of data that I thought might be interesting. Basically, heterogeneous processor architectures are growing quickly and the number of projects using simple processor architectures is diminishing fast.

Data from VDC Research showing trend in multiprocessor development

Really, backs-up what we all instinctively know and understand but nice to see some empirical evidence to add to the mix of customer feedback, social media chatter, and articles we’ve been seeing on the topic. We also tried to collect a bunch of other resources on this topic in one spot with a previous endian blog post we published.

Of course, our focus is on the code analysis tooling available to address these issues. If you’re doing a port, the prospect of manually (or semi-manually) crawling through thousands of instances where you need to modify code to support a different endian format really sucks. Some automation would certainly be nice. Our CTO Gwyn Fisher will be talking in more detail on this topic next week. He has a presentation on improving software reliability in multicore and multiprocessor architectures. Check it out.

Part of my life has been spent in the manufacturing sector working with industrial automation devices, but the discovery of the Stuxnet virus is the first time I’ve ever heard of specifically virus targeting and even rootkitting a PLC (programmable logic controller) or  SCADA (supervisory control and data acquisition) network.

When working in industrial plants, we took the standard precautions with regard to Windows viruses and even started to add virus protection for Linux, but never did it occur to any of us that the industrial automation equipment might be at risk. Whenever the subject was even brought up, which was rare in itself, there were the standard arguments:

• Oh, it’s on a physically separate network (or VLAN configuration), only USB (thumb/flash) drives are allowed and they’re virus checked before use.
• Oh, it’s running a completely different processor/operating system/architecture – there’s no way it can be infected.

The consequences of infection are severe.   These devices run everything from our nuclear power plants to complex manufacturing assembly lines, aircraft controls (FADECs) and chemical refineries, just to name a few.  In its most basic of functions, industrial automation is used for two purposes: to keep humans safe and to produce products for less cost.  Interrupting either of these is going to kill someone or cost a company a large chunk of change.

So, what does this all mean?  It means that industrial automation and PLC vendors had better start hardening their solutions for security vulnerabilities and elevate the quality of their firmware and software components using security vulnerability tools such as Klocwork’s static analysis just as the general computing industry has done for the past 30 years.

For an in-depth analysis and timeline, refer to either Symantec’s whitepaper on their Stuxnet analysis or the work done by ESET on their version of Stuxnet.

It started with the iPod and slowly but systematically gained momentum.

A few years ago, I asked a developer-friend how he decides whether he’ll buy a dev tool or not. He responded somewhat tongue in cheek with, “I will download the tool, play with it and then decide if I would rather spend my money on the latest iPod or the dev tool.” Maybe this is a bit of an edge case, but it speaks to the thought process that goes into the individual developer’s personal workspace design.

For anyone who thinks it’s not all about the developer, think again!

We noticed a trend developing a couple of years ago in some of our largest accounts. A few very small teams in a handful of accounts asked us about our plans to support Mac. When we spoke to the central teams within those accounts about the priority of Mac OS X as a supported environment, it was initially downplayed as a requirement from a few “special project teams.” They reiterated that their corporate development environment continued to be Windows and/or Unix/Linux.

Think again. Like most wars developers decide to fight, they are winning this war as well.

Many of our major accounts now have, or are planning, a significant Mac presence in their development organizations. Apple may say they are not targeting the enterprise, but it is clear the enterprise is targeting Apple. Tim Cook, COO of Apple, made a comment to the analysts in July that 80% of the Fortune 100 are deploying the iPhone, and 50% of the Fortune 100 are testing or have begun deploying the iPad. I bet the same is happening with the Mac. From executives to developers to marketing personnel, the Mac is gaining momentum in the enterprise. For this trend to continue, there are some enterprise-friendly enhancements necessary for the Mac to be a true corporate citizen, but I have found tools like Parallels and VMWare serve as a viable backup plan when total Mac native mode doesn’t cut it.

As the old saying goes, “the proof is in the pudding.” In my opinion, no saying is more apropos, given the prior attitude many technically savvy people had towards Mac. They seemed to universally describe it as, well, a toy! Sure it does useful stuff, but any serious computer user will stick with Windows or Unix. Well, the times they are a-changin’ (since we’re on a cliché kick, I couldn’t resist some classic Bob Dylan).  Several developers I know who once spurned the Mac have quietly added the Mac to their day-to-day development activity. You can argue all you want about whether Mac has critical mass in the enterprise developer world. We are not. We are simply listening to our customers, and as a result we are launching Mac support this month.

Developer needs are constantly changing, but one constant always seems to be that developers quietly find a way to get what they want to do their job.

Deadlock: frog vs. snake
Photo: David Maitland / National Geographic

Continuing the discussion about the embedded community moving to muticore/hetrogeneous hardware from watch out here comes multicore, embedded software development teams have historically been shielded from mulitcore issues. This is due to the specialized functionality of many embedded application classes and the inherent serialized nature of the C language.^[1]

Muticore is an ambiguous term for software developers and one they don’t really use; software developers think in terms of threads/processes and concurrency, not how many cores or processors are available on the target. Concurrency is not a new topic either as Mark Smotherman captured in a history of multithreading, it has been a subject in computer science since its early beginnings in the 1950s.

What has changed is the rapidly increasing use of multicore technologies for embedded devices. One of the prominent software challenges that moving to multicore execution exposes is latent deadlocking bugs as true parallel execution comes into play, instead of a single core’s task scheduling/context switching techniques.

As an example, consider the following code snippet, which has been paraphrased from a deadlock discovered in a real-world open source multithreaded project.

Can you spot the deadlock?

lock_t lock1, lock2;
int refCount = 0;

void enter() {
   reserve_lock(lock1);
      if( refCount == 0 )
         reserve_lock(lock2);
       release_lock(lock1);
   refCount++;
}

void leave() {
   reserve_lock(lock1);
   refCount--;
   if( refCount == 0 )
      release_lock(lock2);
   release_lock(lock1);
}

To see the answer and understand the conditions that lead to the deadlock, download Klocwork’s whitepaper on Developing software for multicore.

A little about the picture in this post.  I found it when searching for pictures of deadlocks.  The photographer, David Maitland, titled his image “Deadlock” and describes it as a continuing struggle between a Morelet’s tree frog and cat-eyed snake. After three hours in the high-stakes cage match, Maitland said there was no clear winner.

VDC Research, “Next Generation Embedded Hardware Architectures: Driving Onset of Project Delays, Costs Overruns, and Software Development Challenges”, September 2010.

Endianness refers to the ordering of bytes into memory. As many of you are aware, computers do ordering differently. You can have the representation of Big-endian or Little-endian.

Essentially Big-endian stores data big-end first, meaning the first byte is the biggest and Little-endian stores data little-end first, meaning the first byte is smallest.

Because all machines are different and write data either as big or little-endian, a computer could read this data incorrectly.  If you are not prepared ahead of time for heterogeneous processor architectures, then you might be in for a world of hurt. This article describes the problem in detail and also provides solutions when you’re starting off.

But what if you’re not prepared?  This can be a costly and complicated problem when developing on large systems with multiple processors or during a porting effort.  You need to be able to verify the developers provide data interaction with the target processor in the proper endian format.  Here’s a good post that talks about this issue in more details, and references a bunch of good third party articles, some of which outline how source code analysis can help; the basic idea being that source code analysis can flag instances where data is being transmitted to or from the target without being transformed.

We’ve just introduced some capabilities in this area which are described in this white paper authored by our CTO Gwyn Fisher. Check it out and let us know what you think.