With our latest product release, we have ventured into the world of Apple. Yup, our product is now officially supported on the Mac.

I think I can safely say that this was not something on our roadmap a few years ago, but we recognized the trends, and now have this offering for our customers. With this support, it was determined that we needed a few more Macs in the organization, the Product Management team included. Now, I’m not sure I stepped forward, or everyone else stepped back (except me), but I ended up being the PM Mac guinea pig.

I have been using PCs since, well for a long time, so this was definitely going to be a learning experience. Let’s say that Google and I became very good friends the first couple of weeks with my shiny new Mac.

In my travels, I stumbled across this article that lists the top 30 mistakes made by new Mac users. Even though this article is a little old, it is amazing how many still apply. Here are a few that I have already qualified for:

15. Installing a program every time they want to run it because they think the installer is the program.

16. Where’s “the internet”? (looking for the Windows Internet Explorer “e” icon)

19. Looking in vain for an uninstaller app, because they don’t realize that uninstalling an application on Mac is as easy as dragging the program icon into the trash.

23. Saving everything to the desktop or somewhere on the hard drive other than their home folder

These are just a few of my favorites, and I’m sure I’ll fall into a few others. Someone once told me that if you need to do something on a Mac, pretend you don’t know anything about computers, and think to yourself what the easiest way might be to accomplish that task. Chances are that is how it has been implemented on the Mac (see #30 in this list). Anyone run into any other goodies that aren’t listed here?

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?

As we have posted in the past, refactoring is a very useful technology to help developers become more productive.  I wanted to take a deeper look at how certain refactorings such as “Extract Function/Method” and “Introduce Variable” can be further enhanced with clone detection.

For the focus of this post I will concentrate just on Extract Function/Method.  Say I create some code that I know I will use frequently.  It would make more sense to create a reusable function/method.  Of course I can add a function to my file then pass the proper parameters and function call, or I can click the extract function refactoring which does this automatically for me.

void dosomething (int a, int b)
{
...
   int c = a + b;
   printf("result= %i ",c);
...
}

Now if I select the two lines and run extract function, it will ask me for a name of the function, I’ll call it “add” and we end up with this:

void add (int a, int b)
{
   int c = a + b;
   printf("result= %i ",c);
}

void dosomething (int a, int b)
{
   add(a, b);
}

Same idea for Introduce variable.  Except it works with an expression and replaces it with a variable name of your choice.

So obviously extract function and introduce variable has value,  anything you can do to make the development process more automated can only make you more productive.  But let’s take a look at how we can improve on this and show where you can really take advantage of the power of refactoring.  In most cases you are working with existing code with plenty of duplication.  This is where clone detection comes into place.  Essentially clone detection is the process of finding the same pattern you just highlighted with special attention to code semantics.  This means you now get immediate notification that there are other areas of duplication, even if variable names might be different, and replace with a click of a button.

Taking the simple extract method function, let’s say we have similar code many lines later.

void dosomething(int a, int b)
{
   ...
   int c = a + b;
   printf("result= %i ",c);
   ...
   int d = a + b;
   printf("result= %i ",d);
   ...
}

Now if we run extract method, you get notified about each clone and the choice to replace.

void add(int a, int b)
{
   int c = a + b;
   printf("result= %i ",c);
}

void dosomething(int a, int b)
{
   ...
   add(a, b);
   ...
   add(a, b);
   ...
}

This is a file level refactoring so clone detection can even apply to multiple functions in the same file!   So hopefully with this you will have a new found love for what refactoring can do you.

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…

Today I wanted to talk about new kinds of benefits you can get from Refactoring.  Everyone knows that refactoring is the process of simplifying and clarifying code without changing the program’s behavior.  The benefits include making the developer more productive by providing tools to automatically clean up the code.  Some of you may be aware of the common refactoring such as “Rename” to rename a variable, parameter or function in your code. Or Extract Function to create a function call and body based on some selected code.

These are great and provide important value but imagine now being able to get additional benefits of reduced compile times and reduced system size in addition to the increased maintainability and reduction of complexity.  All this with a “Optimize Headers” refactoring.

For those who write Java code know of a similar refactoring called “Optimize imports”.  The optimize headers refactoring is for C/C++ code to optimize your include directives.  Specifically it is looking for extra includes and missing transitive issues.  For extra includes you need to analyze the system build structure for that file and identify if any identifiers from the included file are used.  If not then simply remove.  That will reduce your build time, system size and clean up your include structure.

Missing transitive include issue is something that consists of 3 or more files.  For example file A includes B, then B includes C.  But if file A is not using anything from B then you should remove that include and replace it with C (because file A uses identifiers from C).

I’ve added a video that shows how this is done with Eclipse.  So if you thought refactoring is just about code reuse and maintainability think again.

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.

I recently read a book by Peter Ritchie called “Refactoring with Microsoft Visual Studio 2010” and thought I would give my review.

Great book to really help you get started with Refactoring.  Ritchie first goes into an introduction of refactoring and some of the tools available in Visual Studio 2010.  He then provides techniques to help you identify code that might need to be refactored along with examples and step by step procedures to refactor the code.

The focus of this book is not necessarily with Visual Studio 2010, as many of the refactoring examples he goes through do not even have a solution with Visual Studio, but more with a focus on C# code.  When I first ordered this book it wasn’t entirely clear to me that C# was the only language of focus.  That was a little bit disappointing for me because at Klocwork our focus is on refactoring for C/C++.  I guess I’m not surprised as not too many tools are providing a refactoring solution for C/C++ developers.  But with that said even though all examples are C#, what it really helps you understand is where and when to refactor and that is language independent.

I think Ritchie really describes the question of “why refactor” brilliantly.  The point of refactoring vs. rewriting is to fix something that’s not broken.  But as Ritchie states, he is a believer in if it ain’t broken, don’t fix it, but unless your code base defies all reality, it is likely that your code is constantly evolving and getting more complex.  Hence the need to refactor.

Another important point made by Ritchie is that refactoring falls into the developer’s hands.  It is not a task that keeps building up until you identify numerous backlog’s of refactoring.  It is something you need to do daily, as needed.

Overall I enjoyed the detail and examples provided and recommend it to any.  I hope to talk a little more on how Ritchie relates metrics to refactoring in another post.

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.